From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <development+bounces-143-archive=lists.ipfire.org@lists.ipfire.org> Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZM3PK29hYz331h for <archive@lists.ipfire.org>; Mon, 24 Mar 2025 19:43:01 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZM3PF4zYTz2xQd for <development@lists.ipfire.org>; Mon, 24 Mar 2025 19:42:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZM3PD57xFz3W; Mon, 24 Mar 2025 19:42:56 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742845376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jKzKtaWC4UNwky9WJ0lL70jasCyfv6PDbBO85DJVJ7U=; b=G+scxyvaZ2s9VCOwIhPe1MnerFzjKff7Z38LJG1nv33Yb17G3b38W4u73O2la7Bl2gPN8j WIR2xVFicfE+QyCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742845376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jKzKtaWC4UNwky9WJ0lL70jasCyfv6PDbBO85DJVJ7U=; b=iozy1OcFG7YDX6WaKsgZHJ0Ux1XeDOQuKdz8I62YE4w8UlFfQo1TgRw9XGecS41lo2q3RZ 22STNPESH0L0HUteRPI3Tev4w2JHem7IBEQxQ3ZXsTAdCoJaInwmlSdY1SDM3lPUmHSsAS 52uL3oeXMfNALL1yRNXCWhHXwFTB6S6mvkM7vIIdr96eKRpHubdLKZmsNBRcWmACN1MTdR vYAvhgl/cwQVF/YDemw/i8fz5JbR9RkX8l9Ewe0mxbfFQPwD476zuQqkEJ+qnNZoyU2v92 fEMgf24VKoMzZBHqi31rzzp+rEcb3IpJH5PlvWSUmziP++euzDSW9i7OR5bYYA== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: <development.lists.ipfire.org> List-Subscribe: <https://lists.ipfire.org/>, <mailto:development+subscribe@lists.ipfire.org?subject=subscribe> List-Unsubscribe: <https://lists.ipfire.org/>, <mailto:development+unsubscribe@lists.ipfire.org?subject=unsubscribe> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development+help@lists.ipfire.org?subject=help> Sender: <development@lists.ipfire.org> Mail-Followup-To: <development@lists.ipfire.org> Mime-Version: 1.0 Subject: Re: IPFire 2.29 - Core Update 193 is available for testing From: Michael Tremer <michael.tremer@ipfire.org> In-Reply-To: <34c5ad94-5612-4f71-8015-f2284a0ddd84@ipfire.org> Date: Mon, 24 Mar 2025 19:42:56 +0000 Cc: "IPFire: Development-List" <development@lists.ipfire.org> Content-Transfer-Encoding: quoted-printable Message-Id: <BCB11D70-385A-47EC-9720-01951F9ABF7A@ipfire.org> References: <174238111584.1720815.10275774082881760962.ipfire@ipfire.org> <f781d67a-e07a-4916-a39a-0ef2190d38c9@ipfire.org> <BBC1F242-E564-447C-B219-367B2A6B41F0@ipfire.org> <2c4d9fcd-6cde-4bcd-a65d-815d7d283dc4@ipfire.org> <D848285E-C769-4672-BAFF-7251110342B9@ipfire.org> <ca7e20de-0b5a-4591-a899-a6aa970dcbca@ipfire.org> <A22C58E5-49C4-4E37-859E-00644735E12C@ipfire.org> <3e968633-0ecb-4912-b9b8-d4f75953d8e0@ipfire.org> <34c5ad94-5612-4f71-8015-f2284a0ddd84@ipfire.org> To: Adolf Belka <adolf.belka@ipfire.org> 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: >=20 > Hi Michael, >=20 > 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, >>>=20 >>> 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. >>>=20 >>> If you didn=E2=80=99t 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. >=20 > 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. >=20 > 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. >=20 > Deleted the local and remote identity values and saved it and now = these lines are again not in the config file. >=20 > So it looks like the default value is used automatically by the NM = strongswan plugin in its code and cannot be left blank. >=20 > 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. >=20 > 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. >=20 > Regards, >=20 > Adolf. >=20 >> Adolf. >>>=20 >>> -Michael >>>=20 >>>> On 24 Mar 2025, at 13:25, Adolf Belka <adolf.belka@ipfire.org> = wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> On 23/03/2025 13:09, Michael Tremer wrote: >>>>> Hello, >>>>>> On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I have tested my fix for bug13737 and found that it works fine = when a new ipsec x509 root/host certificate set is created. >>>>=20 >>>> What I hadn't tested was checking if an existing working ipsec cert = connection still worked after doing the renew of the host cert. >>>>=20 >>>> I just did that test and the connection fails to connect. >>>>=20 >>>> 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:- >>>>=20 >>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity = cert "C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local" >>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] using certificate = "C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local" >>>> Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] using trusted ca = certificate "C=3DNL, L=3DHague, O=3DIPFire, CN=3DIPFire CA, = E=3Droot@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=3DNL, O=3DIPFire, CN=3Dipfire.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=3DNL, O=3DIPFire, CN=3Dipfire.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) ] >>>>=20 >>>> 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. >>>>=20 >>>> The 'laptop ipsec cert to ipfire 2' mentioned is the Network = Manager strongswan plugin config. >>>>=20 >>>> 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. >>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I will put a patch together and submit it for merging and = testing. >>>>> Yes please, that makes sense to me, too. >>>>=20 >>>> 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. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>>=20 >>>>>> 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: >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> I then created a new ipsec cert connection and tested that out = and it worked but it did not use the post quantum cipher. >>>>>>>>=20 >>>>>>>> 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=E2=80=99t have to worry about any = decreased throughput because of more complex cryptography. >>>>>>>> My laptop and IPFire negotiated a cipher and that connection = then worked. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> I raised a bug on this a while back. >>>>>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=3D13808 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> I have assigned that ipsec bug to myself and it will be = something I will have a go at sometime soon. >>>>>>> I don=E2=80=99t 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>> =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C = =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C = =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C >>>>>>>>> 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=3Demail&utm_source=3Dblog-announcement> >>>>>>>>> The IPFire Project, c/o Lightning Wire Labs GmbH, = Gerhardstra=C3=9Fe 8, 45711 Datteln, Germany >>>>>>>>> Unsubscribe <https://www.ipfire.org/unsubscribe>