public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: IPFire 2.29 - Core Update 193 is available for testing
Date: Thu, 20 Mar 2025 18:40:26 +0100	[thread overview]
Message-ID: <f781d67a-e07a-4916-a39a-0ef2190d38c9@ipfire.org> (raw)
In-Reply-To: <174238111584.1720815.10275774082881760962.ipfire@ipfire.org>

Hi All,

My first findings from CU193 Testing.

The IPBlocklist sources file and the backup.pl file with the changes related to removal of the ABUSECH blocklist, did not get into the filelist file and so that blocklist was not removed.

I tested out ipsec.
A working PSK and cert connection from CU192 were both tested out with CU193 Testing.
Both worked in CU192 and also worked without issues when IPFire was updated to CU193 Testing.

I then created a new ipsec cert connection and tested that out and it worked but it did not use the post quantum cipher.

Strongswan-6.0.0 is also on my laptop but I am using Network Manager with a Strongswan plugin and that might not yet be updated with the post quantum ciphers.

My laptop and IPFire negotiated a cipher and that connection then worked.

The other thing that might be getting in the way is that all the certs currently created in IPSec are legacy based ones,m even if the Root/Host certificate has been re-created to have the more secure version with openssl-3.x

I raised a bug on this a while back.
https://bugzilla.ipfire.org/show_bug.cgi?id=13808

This came about when we updated to OpenSSL-3.x. I added in the legacy options into the openssl commands in the ovpnmain.cgi page and did the same thing to the vpnmain.cgi page for IPSec.

Then in the ovpnmain.cgi page I added in the check if the root/host x509 set was legacy or not and then only used the legacy option if it was.

However, I never went back to the vpnmain.cgi page to update that to only use -legacy if the root/host x509 was legacy.
So currently all client certs are legacy, even if the root/host x509 is not.

I have assigned that ipsec bug to myself and it will be something I will have a go at sometime soon.

However, main thing, the change to strongswan-6.0.0 has not negatively impacted the ipsec operation. All existing connections, at least the ones I had, worked after the CU193 Testing update.

Regards,
Adolf.

On 19/03/2025 11:57, IPFire Project wrote:
> Hello Community! Only a few days after releasing the latest update, we are excited to begin testing the next one. It comes with support for Post-Quantum Cryptography in IPsec as well as a new toolchain and a lot of bug and security updates.
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
> 
> 
>   IPFire_
> 
> 
>   IPFire 2.29 - Core Update 193 is available for testing
> 
> Hello Community! Only a few days after releasing the latest update, we are excited to begin testing the next one. It comes with support for Post-Quantum Cryptography in IPsec as well as a new toolchain and a lot of bug and security updates.
> 
> Read The Full Post On Our Blog <https://www.ipfire.org/blog/ipfire-2-29-core-update-193-is-available-for-testing?utm_medium=email&utm_source=blog-announcement>
> 
> The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstraße 8, 45711 Datteln, Germany
> 
> Unsubscribe <https://www.ipfire.org/unsubscribe>
> 



       reply	other threads:[~2025-03-20 17:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <174238111584.1720815.10275774082881760962.ipfire@ipfire.org>
2025-03-20 17:40 ` Adolf Belka [this message]
2025-03-21 12:10   ` Michael Tremer
2025-03-22 17:22     ` Adolf Belka
2025-03-23 12:09       ` Michael Tremer
2025-03-24 13:25         ` Adolf Belka
2025-03-24 14:43           ` Michael Tremer
2025-03-24 16:39             ` Adolf Belka
2025-03-24 17:22               ` Adolf Belka
2025-03-24 19:42                 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f781d67a-e07a-4916-a39a-0ef2190d38c9@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox