Re: IPFire 2.29 - Core Update 193 is available for testing

Re: IPFire 2.29 - Core Update 193 is available for testing

[Adolf Belka]

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>
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Michael Tremer]

Hello Adolf,

> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> My first findings from CU193 Testing.

Thank you for 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.

Thank you. I pushed a commit for this.

> 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.

I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.

I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.

> 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.

I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...

> 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.

Great! I can confirm the same.

-Michael

> 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>
> 
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Adolf Belka]

Hi,

I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.

However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.

I will put a patch together and submit it for merging and testing.

Regards,

Adolf.


On 21/03/2025 13:10, Michael Tremer wrote:
> Hello Adolf,
> 
>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi All,
>>
>> My first findings from CU193 Testing.
> 
> Thank you for 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.
> 
> Thank you. I pushed a commit for this.
> 
>> 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.
> 
> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
> 
> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
> 
>> 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.
> 
> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
> 
>> 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.
> 
> Great! I can confirm the same.
> 
> -Michael
> 
>> 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>
>>
>>
> 
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Michael Tremer]

Hello,

> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi,
> 
> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.
> 
> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
> 
> I will put a patch together and submit it for merging and testing.

Yes please, that makes sense to me, too.

> 
> Regards,
> 
> Adolf.
> 
> 
> On 21/03/2025 13:10, Michael Tremer wrote:
>> Hello Adolf,
>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>> 
>>> Hi All,
>>> 
>>> My first findings from CU193 Testing.
>> Thank you for 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.
>> Thank you. I pushed a commit for this.
>>> 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.
>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>> 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.
>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>> 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.
>> Great! I can confirm the same.
>> -Michael
>>> 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>
>>> 
>>> 
> 
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Adolf Belka]

Hi Michael,

On 23/03/2025 13:09, Michael Tremer wrote:
> Hello,
> 
>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi,
>>
>> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.

What I hadn't tested was checking if an existing working ipsec cert connection still worked after doing the renew of the host cert.

I just did that test and the connection fails to connect.

Most of the connection elements are successful, such as the negotiation of the ciphers etc but right at the end it comes up with the message:-

Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity cert "C=NL, O=IPFire, CN=ipfire.domain.local"
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using certificate "C=NL, O=IPFire, CN=ipfire.domain.local"
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using trusted ca certificate "C=NL, L=Hague, O=IPFire, CN=IPFire CA, E=root@ipfire.domain.local"
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   reached self-signed root ca with a path length of 0
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate status of "C=NL, O=IPFire, CN=ipfire.domain.local"
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is not available
Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of 'C=NL, O=IPFire, CN=ipfire.domain.local' with RSA_EMSA_PKCS1_SHA2_384 successful
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check failed: certificate does not confirm identity 'ipfire.domain.local' (ID_FQDN)
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed
Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config found
Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

When the host cert renew is carried out is the intent that existing connections will still work or do I still have to recreate the client connections. The latter doesn't seem to be the intent otherwise I might just as well create a new Root/Host x509 set.

The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager strongswan plugin config.

Maybe the issue is with the strongswan Network Manager plugin that is doing some checking somewhere and finding a difference. Obviously the hostcert.pem has a different signature that before the renewal.

>>
>> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
>>
>> I will put a patch together and submit it for merging and testing.
> 
> Yes please, that makes sense to me, too.

I will still create the patch for the install.sh script to update the serial number to 02 for systems that have created the root/host x509 ipsec certificate set but the problem I have found above suggests that the ipsec renewal might not work in the expected way for all connection clients.

Regards,

Adolf.


> 
>>
>> Regards,
>>
>> Adolf.
>>
>>
>> On 21/03/2025 13:10, Michael Tremer wrote:
>>> Hello Adolf,
>>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> My first findings from CU193 Testing.
>>> Thank you for 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.
>>> Thank you. I pushed a commit for this.
>>>> 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.
>>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>>> 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.
>>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>>> 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.
>>> Great! I can confirm the same.
>>> -Michael
>>>> 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>
>>>>
>>>>
>>
>>
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Michael Tremer]

Hello,

If you have set the local/remote ID in the connection it has to be part of the certificate which does not happen automatically in IPFire.

If you didn’t set this, then NetworkManager was sending some sort of ID. Is there a way to remove it from there imported configuration?

-Michael

> On 24 Mar 2025, at 13:25, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 23/03/2025 13:09, Michael Tremer wrote:
>> Hello,
>>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.
> 
> What I hadn't tested was checking if an existing working ipsec cert connection still worked after doing the renew of the host cert.
> 
> I just did that test and the connection fails to connect.
> 
> Most of the connection elements are successful, such as the negotiation of the ciphers etc but right at the end it comes up with the message:-
> 
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity cert "C=NL, O=IPFire, CN=ipfire.domain.local"
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using certificate "C=NL, O=IPFire, CN=ipfire.domain.local"
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using trusted ca certificate "C=NL, L=Hague, O=IPFire, CN=IPFire CA, E=root@ipfire.domain.local"
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   reached self-signed root ca with a path length of 0
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate status of "C=NL, O=IPFire, CN=ipfire.domain.local"
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is not available
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of 'C=NL, O=IPFire, CN=ipfire.domain.local' with RSA_EMSA_PKCS1_SHA2_384 successful
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check failed: certificate does not confirm identity 'ipfire.domain.local' (ID_FQDN)
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config found
> Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
> 
> When the host cert renew is carried out is the intent that existing connections will still work or do I still have to recreate the client connections. The latter doesn't seem to be the intent otherwise I might just as well create a new Root/Host x509 set.
> 
> The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager strongswan plugin config.
> 
> Maybe the issue is with the strongswan Network Manager plugin that is doing some checking somewhere and finding a difference. Obviously the hostcert.pem has a different signature that before the renewal.
> 
>>> 
>>> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
>>> 
>>> I will put a patch together and submit it for merging and testing.
>> Yes please, that makes sense to me, too.
> 
> I will still create the patch for the install.sh script to update the serial number to 02 for systems that have created the root/host x509 ipsec certificate set but the problem I have found above suggests that the ipsec renewal might not work in the expected way for all connection clients.
> 
> Regards,
> 
> Adolf.
> 
> 
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> 
>>> On 21/03/2025 13:10, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> My first findings from CU193 Testing.
>>>> Thank you for 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.
>>>> Thank you. I pushed a commit for this.
>>>>> 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.
>>>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>>>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>>>> 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.
>>>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>>>> 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.
>>>> Great! I can confirm the same.
>>>> -Michael
>>>>> 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>
>>>>> 
>>>>> 
>>> 
>>> 
> 
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Adolf Belka]

Hi Michael,

Thanks for the feedback.

On 24/03/2025 15:43, Michael Tremer wrote:
> Hello,
> 
> If you have set the local/remote ID in the connection it has to be part of the certificate which does not happen automatically in IPFire.

I didn't set either the local or the remote id in the IPFire ipsec WUI setup.

> 
> If you didn’t set this, then NetworkManager was sending some sort of ID. Is there a way to remove it from there imported configuration?

In the Network Manager input I left the ID blank but it does say if it is not filled in then the default that Network Manager uses is the server address or the servers certificate subject DN.
It also says that custom values are explicitly sent to the server and enforced during authentication.

I cleared out the connections I had to start again, so I can't check if there is something explicitly defined in the NM config file, but I will start all over again, with a fresh connection, show it is working and see what is in the config file.

Adolf.

> 
> -Michael
> 
>> On 24 Mar 2025, at 13:25, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 23/03/2025 13:09, Michael Tremer wrote:
>>> Hello,
>>>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.
>>
>> What I hadn't tested was checking if an existing working ipsec cert connection still worked after doing the renew of the host cert.
>>
>> I just did that test and the connection fails to connect.
>>
>> Most of the connection elements are successful, such as the negotiation of the ciphers etc but right at the end it comes up with the message:-
>>
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity cert "C=NL, O=IPFire, CN=ipfire.domain.local"
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using certificate "C=NL, O=IPFire, CN=ipfire.domain.local"
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using trusted ca certificate "C=NL, L=Hague, O=IPFire, CN=IPFire CA, E=root@ipfire.domain.local"
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   reached self-signed root ca with a path length of 0
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate status of "C=NL, O=IPFire, CN=ipfire.domain.local"
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is not available
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of 'C=NL, O=IPFire, CN=ipfire.domain.local' with RSA_EMSA_PKCS1_SHA2_384 successful
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check failed: certificate does not confirm identity 'ipfire.domain.local' (ID_FQDN)
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config found
>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>
>> When the host cert renew is carried out is the intent that existing connections will still work or do I still have to recreate the client connections. The latter doesn't seem to be the intent otherwise I might just as well create a new Root/Host x509 set.
>>
>> The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager strongswan plugin config.
>>
>> Maybe the issue is with the strongswan Network Manager plugin that is doing some checking somewhere and finding a difference. Obviously the hostcert.pem has a different signature that before the renewal.
>>
>>>>
>>>> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
>>>>
>>>> I will put a patch together and submit it for merging and testing.
>>> Yes please, that makes sense to me, too.
>>
>> I will still create the patch for the install.sh script to update the serial number to 02 for systems that have created the root/host x509 ipsec certificate set but the problem I have found above suggests that the ipsec renewal might not work in the expected way for all connection clients.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>>
>>>> On 21/03/2025 13:10, Michael Tremer wrote:
>>>>> Hello Adolf,
>>>>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> My first findings from CU193 Testing.
>>>>> Thank you for 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.
>>>>> Thank you. I pushed a commit for this.
>>>>>> 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.
>>>>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>>>>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>>>>> 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.
>>>>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>>>>> 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.
>>>>> Great! I can confirm the same.
>>>>> -Michael
>>>>>> 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>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
> 
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Adolf Belka]

Hi Michael,

On 24/03/2025 17:39, Adolf Belka wrote:
> Hi Michael,
> 
> Thanks for the feedback.
> 
> On 24/03/2025 15:43, Michael Tremer wrote:
>> Hello,
>>
>> If you have set the local/remote ID in the connection it has to be part of the certificate which does not happen automatically in IPFire.
> 
> I didn't set either the local or the remote id in the IPFire ipsec WUI setup.
> 
>>
>> If you didn’t set this, then NetworkManager was sending some sort of ID. Is there a way to remove it from there imported configuration?
> 
> In the Network Manager input I left the ID blank but it does say if it is not filled in then the default that Network Manager uses is the server address or the servers certificate subject DN.
> It also says that custom values are explicitly sent to the server and enforced during authentication.
> 
> I cleared out the connections I had to start again, so I can't check if there is something explicitly defined in the NM config file, but I will start all over again, with a fresh connection, show it is working and see what is in the config file.

Okay, I created a new ipsec cert connection and got it working. I didn't put local or remote id into IPFire server or into the NM strongswan plugin.

I checked the config file and there was no entry for local-identity or remote-identity. I then entered a name for each into the NM strongswan plugin and saved it and now there are lines for the local-identity and remote-identity.

Deleted the local and remote identity values and saved it and now these lines are again not in the config file.

So it looks like the default value is used automatically by the NM strongswan plugin in its code and cannot be left blank.

I can't find any other ipsec client with a GUI to install on my laptop, so I suspect I am going to have to look at setting up a strongswan client on my laptop on the command line.

Anyway, looks like my problem is due to the NM strongswan plugin not allowing blank local and remote id's, they always have a value assigned, default ones if the entries are left blank.

Regards,

Adolf.

> 
> Adolf.
> 
>>
>> -Michael
>>
>>> On 24 Mar 2025, at 13:25, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> On 23/03/2025 13:09, Michael Tremer wrote:
>>>> Hello,
>>>>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.
>>>
>>> What I hadn't tested was checking if an existing working ipsec cert connection still worked after doing the renew of the host cert.
>>>
>>> I just did that test and the connection fails to connect.
>>>
>>> Most of the connection elements are successful, such as the negotiation of the ciphers etc but right at the end it comes up with the message:-
>>>
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity cert "C=NL, O=IPFire, CN=ipfire.domain.local"
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using certificate "C=NL, O=IPFire, CN=ipfire.domain.local"
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using trusted ca certificate "C=NL, L=Hague, O=IPFire, CN=IPFire CA, E=root@ipfire.domain.local"
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   reached self-signed root ca with a path length of 0
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate status of "C=NL, O=IPFire, CN=ipfire.domain.local"
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is not available
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of 'C=NL, O=IPFire, CN=ipfire.domain.local' with RSA_EMSA_PKCS1_SHA2_384 successful
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check failed: certificate does not confirm identity 'ipfire.domain.local' (ID_FQDN)
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config found
>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>>
>>> When the host cert renew is carried out is the intent that existing connections will still work or do I still have to recreate the client connections. The latter doesn't seem to be the intent otherwise I might just as well create a new Root/Host x509 set.
>>>
>>> The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager strongswan plugin config.
>>>
>>> Maybe the issue is with the strongswan Network Manager plugin that is doing some checking somewhere and finding a difference. Obviously the hostcert.pem has a different signature that before the renewal.
>>>
>>>>>
>>>>> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
>>>>>
>>>>> I will put a patch together and submit it for merging and testing.
>>>> Yes please, that makes sense to me, too.
>>>
>>> I will still create the patch for the install.sh script to update the serial number to 02 for systems that have created the root/host x509 ipsec certificate set but the problem I have found above suggests that the ipsec renewal might not work in the expected way for all connection clients.
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>>
>>>>>
>>>>> On 21/03/2025 13:10, Michael Tremer wrote:
>>>>>> Hello Adolf,
>>>>>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> My first findings from CU193 Testing.
>>>>>> Thank you for 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.
>>>>>> Thank you. I pushed a commit for this.
>>>>>>> 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.
>>>>>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>>>>>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>>>>>> 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.
>>>>>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>>>>>> 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.
>>>>>> Great! I can confirm the same.
>>>>>> -Michael
>>>>>>> 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>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
> 

Re: IPFire 2.29 - Core Update 193 is available for testing

[Michael Tremer]

Hello,

Today might not be the day for this, but I think this would be nice to be solved for good. Although IPsec is usually not the first thing that is being picked for NetworkManager, it should still work.

Best,
-Michael

> On 24 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 24/03/2025 17:39, Adolf Belka wrote:
>> Hi Michael,
>> Thanks for the feedback.
>> On 24/03/2025 15:43, Michael Tremer wrote:
>>> Hello,
>>> 
>>> If you have set the local/remote ID in the connection it has to be part of the certificate which does not happen automatically in IPFire.
>> I didn't set either the local or the remote id in the IPFire ipsec WUI setup.
>>> 
>>> If you didn’t set this, then NetworkManager was sending some sort of ID. Is there a way to remove it from there imported configuration?
>> In the Network Manager input I left the ID blank but it does say if it is not filled in then the default that Network Manager uses is the server address or the servers certificate subject DN.
>> It also says that custom values are explicitly sent to the server and enforced during authentication.
>> I cleared out the connections I had to start again, so I can't check if there is something explicitly defined in the NM config file, but I will start all over again, with a fresh connection, show it is working and see what is in the config file.
> 
> Okay, I created a new ipsec cert connection and got it working. I didn't put local or remote id into IPFire server or into the NM strongswan plugin.
> 
> I checked the config file and there was no entry for local-identity or remote-identity. I then entered a name for each into the NM strongswan plugin and saved it and now there are lines for the local-identity and remote-identity.
> 
> Deleted the local and remote identity values and saved it and now these lines are again not in the config file.
> 
> So it looks like the default value is used automatically by the NM strongswan plugin in its code and cannot be left blank.
> 
> I can't find any other ipsec client with a GUI to install on my laptop, so I suspect I am going to have to look at setting up a strongswan client on my laptop on the command line.
> 
> Anyway, looks like my problem is due to the NM strongswan plugin not allowing blank local and remote id's, they always have a value assigned, default ones if the entries are left blank.
> 
> Regards,
> 
> Adolf.
> 
>> Adolf.
>>> 
>>> -Michael
>>> 
>>>> On 24 Mar 2025, at 13:25, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> On 23/03/2025 13:09, Michael Tremer wrote:
>>>>> Hello,
>>>>>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have tested my fix for bug13737 and found that it works fine when a new ipsec x509 root/host certificate set is created.
>>>> 
>>>> What I hadn't tested was checking if an existing working ipsec cert connection still worked after doing the renew of the host cert.
>>>> 
>>>> I just did that test and the connection fails to connect.
>>>> 
>>>> Most of the connection elements are successful, such as the negotiation of the ciphers etc but right at the end it comes up with the message:-
>>>> 
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity cert "C=NL, O=IPFire, CN=ipfire.domain.local"
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using certificate "C=NL, O=IPFire, CN=ipfire.domain.local"
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   using trusted ca certificate "C=NL, L=Hague, O=IPFire, CN=IPFire CA, E=root@ipfire.domain.local"
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG]   reached self-signed root ca with a path length of 0
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate status of "C=NL, O=IPFire, CN=ipfire.domain.local"
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is not available
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of 'C=NL, O=IPFire, CN=ipfire.domain.local' with RSA_EMSA_PKCS1_SHA2_384 successful
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check failed: certificate does not confirm identity 'ipfire.domain.local' (ID_FQDN)
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config found
>>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>>> 
>>>> When the host cert renew is carried out is the intent that existing connections will still work or do I still have to recreate the client connections. The latter doesn't seem to be the intent otherwise I might just as well create a new Root/Host x509 set.
>>>> 
>>>> The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager strongswan plugin config.
>>>> 
>>>> Maybe the issue is with the strongswan Network Manager plugin that is doing some checking somewhere and finding a difference. Obviously the hostcert.pem has a different signature that before the renewal.
>>>> 
>>>>>> 
>>>>>> However it doesn't work for existing sets as they already have the serial file contents at 01. I forgot to add in some code for the update.sh file to update existing root/host certificates with serial file contents at 01 to 02.
>>>>>> 
>>>>>> I will put a patch together and submit it for merging and testing.
>>>>> Yes please, that makes sense to me, too.
>>>> 
>>>> I will still create the patch for the install.sh script to update the serial number to 02 for systems that have created the root/host x509 ipsec certificate set but the problem I have found above suggests that the ipsec renewal might not work in the expected way for all connection clients.
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.
>>>> 
>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Adolf.
>>>>>> 
>>>>>> 
>>>>>> On 21/03/2025 13:10, Michael Tremer wrote:
>>>>>>> Hello Adolf,
>>>>>>>> On 20 Mar 2025, at 17:40, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> My first findings from CU193 Testing.
>>>>>>> Thank you for 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.
>>>>>>> Thank you. I pushed a commit for this.
>>>>>>>> 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.
>>>>>>> I think this might be quite difficult to test on a client, because NetworkManager will also need to support this and I am not sure how fast they will be.
>>>>>>> I did however test this myself on a N2N connection and it works fine. Sadly there is no different feeling to those connections as it only affects the handshake. We don’t have to worry about any decreased throughput because of more complex cryptography.
>>>>>>>> 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.
>>>>>>> I don’t like that the entire X.509 situation is becoming more of a nightmare with every single day that is passing...
>>>>>>>> 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.
>>>>>>> Great! I can confirm the same.
>>>>>>> -Michael
>>>>>>>> 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>