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 4cGSHM1KhVz30Vk for ; Tue, 02 Sep 2025 14:07:27 +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) (Client CN "mail01.haj.ipfire.org", Issuer "R13" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4cGSHH5KStz2xFx for ; Tue, 02 Sep 2025 14:07: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 4cGSHH19t7z29; Tue, 02 Sep 2025 14:07:23 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1756822043; 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=iXSqp3qwgewJH6tKRU6bacnGtOyGg5iEypncGFLEqQE=; b=WQLVulbqMfhwJfdngj5nhmUsepokfVJ3PCU9zigXYfKOH1PyQsPY+0Ls9cTEcTipVmezuB NUGhTOKTqyYl6SBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1756822043; 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=iXSqp3qwgewJH6tKRU6bacnGtOyGg5iEypncGFLEqQE=; b=BlPky0c1SbUpfIuFCxzQFbacZsV2OXOwM2MPU7uv3pzUPkemjDYpphIBPFpaKH9sEdDrnZ /1kdTHBKZECQUtuTq4eJXdaTdZWdg83S4C7KuRL7W2m4QtwjL43iFfOy7KIQdbPvs4xwGp mY4ED2NHDLfhlFOAZvLr8szQ9eawuwJBCaX4GwcwwDI49aRXycQmUN726RJlLjakOXu5of FUGnWSBw5kiK1EfZw4e5+gpaQwP+uDBCYU20ALugFZGo+CHnlwOVSg95UCWpmPTnLo4Z/a wABA/NxLdYQoseuMwE/0sfz1JDKaR3WxYg61hj0RnxSBPIOXpShvwUj7+qiMQA== 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: Date: Tue, 2 Sep 2025 15:07:22 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <22EBB124-EF62-46E2-A930-C8C7C6DCC6C0@ipfire.org> References: <63886579-ceeb-44a6-b24c-0bb72632a0b5@ipfire.org> <2347C9DE-BFB2-4C0A-8715-4E501FAE70DF@ipfire.org> <7caee11c-7569-4ab4-bef1-4978433ad481@ipfire.org> To: Adolf Belka 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 > 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! -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 >=20 >=20