Hello, Superb!
> On 3 Sep 2025, at 18:49, Adolf Belka <[email protected]> wrote: > > Hi Michael, > > On 02/09/2025 16:07, Michael Tremer wrote: >> Hello Adolf, >>> On 2 Sep 2025, at 11:34, Adolf Belka <[email protected]> wrote: >>> >>> Hi Michael, >>> >>> 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. >>> >>> Will do so. > > The changes are located at > https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=shortlog;h=refs/heads/openvpn-2.7_alpha3 > > This includes the sorting out of the status extraction information and the > removal of the deprecated persist-key option. > > 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. > > 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. > > 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. > >>> >>> I found in the deprecated options section of OpenVPN a comment that says >>> >>> 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. >>> >>> This is in the section on migrating away from deprecated ciphers. >>> >>> However there is also the statement in removal of insecure ciphers >>> >>> For now we will not officially remove them and focus on educating users. >>> Maybe at some point the SSL libraries will start dropping them. >>> >>> I tested out running openvpn with BF-CBC in the ciphers-data-fallback and >>> got the following message in the openvpn-2.7 logs >>> >>> 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. >>> >>> 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. >>> >>> 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 <= 2.3. >>> On the compression front, I found the following statement in the >>> openvpn-2.7 changes >>> >>> -------------- >>> Remove support for compression on send >>> >>> 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. >>> >>> Makes "--allow-compression yes" an alias for >>> "--allow-compression asym" and removes all resulting dead code. >>> -------------- >>> >>> So the compress outgoing was disabled by default anyway but in 2.7 the code >>> will no longer exist in openvpn >>> >>> 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. >>> >>> 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 “compress”, but actually, OpenVPN >> won’t really compress any data any more. The “compress migrate” option might >> sometimes add a special header which was formerly required when compression >> was enabled, but it won’t 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 >= 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! > > 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… -Michael > I will also do a test and update of the openvpn-2.7 branch when the beta and > rc versions are released. > > Regards, > > Adolf. > >> -Michael >>> >>> Regards, >>> >>> Adolf. >>> >>> >>>> Best, >>>> -Michael >>>>> On 27 Aug 2025, at 17:58, Adolf Belka <[email protected]> wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> On 27/08/2025 15:24, Adolf Belka wrote: >>>>>> Hi Michael, >>>>>> On 18/08/2025 13:47, Michael Tremer wrote: >>>>>>> Hello Adolf, >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> But this actually proves the opposite. The —-persist-key option can be >>>>>>> easily dropped then. We use it everywhere and it will then become the >>>>>>> default. Very good. >>>>>>> >>>>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> So when we come to upgrade to OpenVPN-2.7.x then I know what changes will >>>>> be needed. >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Best, >>>>>>> -Michael >>>>>>> >>>>>>>> On 17 Aug 2025, at 14:43, Adolf Belka <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I have built and done initial testing of CU198 with >>>>>>>> OpenVPN-2.7_alpha3. Here is my initial feedback. >>>>>>>> >>>>>>>> My N2N connection connected and I could ping between both ends. The >>>>>>>> status on the OpenVPN WUI page showed as Connected. >>>>>>>> >>>>>>>> Only item was that when rebooting the following message shows up in >>>>>>>> the boot log when the N2N connection is started >>>>>>>> >>>>>>>> DEPRECATED: --persist-key option ignored. Keys are now always >>>>>>>> persisted across restarts. >>>>>>>> >>>>>>>> >>>>>>>> I the tested out the old existing Android and Linux Laptop client >>>>>>>> connections. >>>>>>>> >>>>>>>> In both cases at the client ends they said they were connected. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> I will have another go with new client connections and see if that >>>>>>>> shows anything different with regard to the status. >>>>>>>> >>>>>>>> Also need to remember this is the alpha3 release so there might be >>>>>>>> bugs still and maybe that is what I am experiencing. >>>>>>>> >>>>>>>> So RW connections get made but stay showing as disconnected when they >>>>>>>> are actually connected. >>>>>>>> N2N connections show as connected and are connected. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Adolf
