From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4cQTjV5BJwz32PH for ; Mon, 15 Sep 2025 15:39:26 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (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 "R13" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4cQTjR277gz2xLw for ; Mon, 15 Sep 2025 15:39:23 +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 4cQTjQ16mHz5n; Mon, 15 Sep 2025 15:39:22 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1757950762; 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=yoXUFhPV/vMciMHk4ejoW8ptGH5gbNdUzpEiyxw/uZw=; b=r4yuJt8FWkkCaziFCCB4P7+dQx4ffFqaxQj2NRo7UH4ihFx/tKYmt3IrMQgOKd756aSU30 Eldg+4E5MYoujkBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1757950762; 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=yoXUFhPV/vMciMHk4ejoW8ptGH5gbNdUzpEiyxw/uZw=; b=YxSEsqsr6NqFe82hHWvx7WFExABuQz6Uxj13N0M3L3dejze2yPb4Sz3zyiMAn7tIkPi9+O lmR3qOfrl7hYlUWw7OVROjJhKGFn/Wb6hjfCDg7ZJtUUPZVNDH0c+L0XNDoj7qqK59sBvD SAA+VUQ0kCm2SL8dymt0c/vj+BDUbXZ/+Axhch/agfu352yefQxsCjn1/SyvC6LFks/6N3 VbQrsFitOYrMxejgmb3EFcmqDON9LpiclyEU+DEPWp4HGZO3a3MnpM97C+k9Vw4ZXC49oR /W/o1Zc3oLE2Jv0GnvArP3QWNotrbwuz2ts8CXIFNA+dLmysRV+z05oCXIPqCg== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Testing out CU198 with OpenVPN-2.7_alpha3 From: Michael Tremer In-Reply-To: <5a6a55ea-3d41-4739-ae56-f2b3983ef1c3@ipfire.org> Date: Mon, 15 Sep 2025 16:39:21 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <86859378-6E6F-40A6-AD42-7A3203673A2F@ipfire.org> References: <63886579-ceeb-44a6-b24c-0bb72632a0b5@ipfire.org> <2347C9DE-BFB2-4C0A-8715-4E501FAE70DF@ipfire.org> <7caee11c-7569-4ab4-bef1-4978433ad481@ipfire.org> <22EBB124-EF62-46E2-A930-C8C7C6DCC6C0@ipfire.org> <5a6a55ea-3d41-4739-ae56-f2b3983ef1c3@ipfire.org> To: Adolf Belka Hello, Superb! > On 3 Sep 2025, at 18:49, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 02/09/2025 16:07, Michael Tremer wrote: >> Hello Adolf, >>> On 2 Sep 2025, at 11:34, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 28/08/2025 10:46, Michael Tremer wrote: >>>> Hello Adolf, >>>> This is great. >>>> I would suggest to create a Git branch somewhere and push those = changes right now. That way, we will only have to merge them later and = not even think about what changes we need and why. >>>=20 >>> Will do so. >=20 > The changes are located at > = https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dshortlog;= h=3Drefs/heads/openvpn-2.7_alpha3 >=20 > This includes the sorting out of the status extraction information and = the removal of the deprecated persist-key option. >=20 > Removing this worked fine for the server and rw clients. The = server.conf and the rw client .ovpn files all no longer have the = persist-key option. as they are all created anew when a backup is = restored or an update carried out. >=20 > However for the n2n connections, these are stored as already created = .conf files and therefore keep the persist-key entry and therefore get = the warning about the deprecated option. >=20 > When we do the update of openvpn-2.7 we will need to add in a patch to = remove the persist-key from existing n2n connections. > The same for the backup. I will create an update top the backup.pl = file to do this and add it to the above openvpn-2.7 branch. >=20 >>>=20 >>> I found in the deprecated options section of OpenVPN a comment that = says >>>=20 >>> WARNING: This migration approach will not work after the release of = OpenVPN v2.7. As of that release, BF-CBC, CAST or RC2 ciphers will not = be accepted any more. >>>=20 >>> This is in the section on migrating away from deprecated ciphers. >>>=20 >>> However there is also the statement in removal of insecure ciphers >>>=20 >>> For now we will not officially remove them and focus on educating = users. Maybe at some point the SSL libraries will start dropping them. >>>=20 >>> I tested out running openvpn with BF-CBC in the = ciphers-data-fallback and got the following message in the openvpn-2.7 = logs >>>=20 >>> WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit = (64 bit). This allows attacks like SWEET32. Mitigate by using a = --cipher with a larger block size (e.g. AES-256-CBC). Support for these = insecure ciphers will be removed in OpenVPN 2.7. >>>=20 >>> I also then manually changed the server.conf file to have = data-ciphers also set to BF-CBC and then restarted openvpn-rw and the = same above message is shown but openvpn-rw is running. >>>=20 >>> So the insecure ciphers will still be accepted but there will be a = warning in the logs. >> This should not *really* bother us because we should soon have all = servers supporting NCP. That way, all clients which also support NCP = will automatically migrate away from the statically configured ciphers = (no matter what it is). If people are using clients that are still not = supporting NCP (pre 2.4), those will break when they are removing = support for these ciphers on the server side. However, even 2.5 is = already EOL, so nobody should be on OpenVPN <=3D 2.3. >>> On the compression front, I found the following statement in the = openvpn-2.7 changes >>>=20 >>> -------------- >>> Remove support for compression on send >>>=20 >>> We can't disable compression support on receive because >>> that would break too many configurations out there. But >>> we can remove the support for compressing outgoing traffic, >>> it was disabled by default anyway. >>>=20 >>> Makes "--allow-compression yes" an alias for >>> "--allow-compression asym" and removes all resulting dead code. >>> -------------- >>>=20 >>> So the compress outgoing was disabled by default anyway but in 2.7 = the code will no longer exist in openvpn >>>=20 >>> I don't believe this changes how we are using the compress migrate = option but I thought I would flag it up for you to see. >>>=20 >>> Interesting that they are saying now that they can't as standard = disable compression support on receive due to so many user configs using = it. >> The configuration might still include =E2=80=9Ccompress=E2=80=9D, but = actually, OpenVPN won=E2=80=99t really compress any data any more. The = =E2=80=9Ccompress migrate=E2=80=9D option might sometimes add a special = header which was formerly required when compression was enabled, but it = won=E2=80=99t compress the payload any more. Currently, our server is = configured to accept compressed packets (if the client really insists), = but it will never send a compressed packed as that would make the stream = vulnerable to the voracle attack. >> So this should not really affect us. In fact it is a good thing = because we can rely on clients >=3D 2.7 never to send any compressed = data either which would be a security benefit. >> So, all green lights from me on the 2.7 front for now! >=20 > I think so also. 2.7 will be much easier than the move from 2.5 to 2.6 I suppose we had a large backlog and are now shipping all sorts of = changes in one go=E2=80=A6 -Michael > I will also do a test and update of the openvpn-2.7 branch when the = beta and rc versions are released. >=20 > Regards, >=20 > Adolf. >=20 >> -Michael >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>=20 >>>> Best, >>>> -Michael >>>>> On 27 Aug 2025, at 17:58, Adolf Belka = wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> On 27/08/2025 15:24, Adolf Belka wrote: >>>>>> Hi Michael, >>>>>> On 18/08/2025 13:47, Michael Tremer wrote: >>>>>>> Hello Adolf, >>>>>>>=20 >>>>>>> This is really valuable work because we might have to start = transitioning OpenVPN changes a lot sooner than the final release is = coming out because of all this bad, static configuration stuff on both = sides of the connection. >>>>>>>=20 >>>>>>> But this actually proves the opposite. The =E2=80=94-persist-key = option can be easily dropped then. We use it everywhere and it will then = become the default. Very good. >>>>>>>=20 >>>>>>> Regarding the status, there have been many changes over the = years and it usually should be easy to fix it. Normally more information = is being added and we just need to account for it. Hopefully that is a 5 = minute job. >>>>>> Based on your input I had a look at the differences in the status = log from 2.6 and 2.7 >>>>>> With 2.6 the Real Address is IP:PORT >>>>>> With 2.7 it is UDP4:IP:PORT >>>>>> So that definitely looks like it should be easy to fix. >>>>>=20 >>>>> I have tested out some changes and have been able to get the = OpenVPN Connection statistics and the Status display for each of the = connection lines to work again. >>>>>=20 >>>>> So when we come to upgrade to OpenVPN-2.7.x then I know what = changes will be needed. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> So with this information, I am very relaxed and hopeful that the = new 2.7 release will be an easy update for us and everyone using = OpenVPN. >>>>>> It does look like it should not be so stressful an update as we = have had from 2.5 to 2.6 >>>>>> Regards, >>>>>> Adolf. >>>>>>>=20 >>>>>>> Best, >>>>>>> -Michael >>>>>>>=20 >>>>>>>> On 17 Aug 2025, at 14:43, Adolf Belka = wrote: >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> I have built and done initial testing of CU198 with = OpenVPN-2.7_alpha3. Here is my initial feedback. >>>>>>>>=20 >>>>>>>> My N2N connection connected and I could ping between both ends. = The status on the OpenVPN WUI page showed as Connected. >>>>>>>>=20 >>>>>>>> Only item was that when rebooting the following message shows = up in the boot log when the N2N connection is started >>>>>>>>=20 >>>>>>>> DEPRECATED: --persist-key option ignored. Keys are now always = persisted across restarts. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I the tested out the old existing Android and Linux Laptop = client connections. >>>>>>>>=20 >>>>>>>> In both cases at the client ends they said they were connected. >>>>>>>>=20 >>>>>>>> On the Linux Laptop I could ping to a PC on the green network. = For both the Linux Laptop and Android phone I could access the WUI page = of the IPFire system. The logs showed that the clients were connected. >>>>>>>>=20 >>>>>>>> However in both cases the OpenVPN WUI page stayed showing the = RW connections as disconnected. Accessing the OpenVPN Connection = Statistics never showed any connection existing. >>>>>>>>=20 >>>>>>>> So the status methodology for the RW's does not seem to be = working with OpenVPN-2.7, even though the connections were successfully = connected and the standard openvpn logs show the rw clients as = connected. >>>>>>>>=20 >>>>>>>> I will have another go with new client connections and see if = that shows anything different with regard to the status. >>>>>>>>=20 >>>>>>>> Also need to remember this is the alpha3 release so there might = be bugs still and maybe that is what I am experiencing. >>>>>>>>=20 >>>>>>>> So RW connections get made but stay showing as disconnected = when they are actually connected. >>>>>>>> N2N connections show as connected and are connected. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> Adolf