Hello, I have created a page on our roadmap so that we can keep track of this:
https://www.ipfire.org/docs/roadmap/openvpn-27 Please let me know if something needs changing. Best, -Michael > On 23 Feb 2026, at 14:52, Michael Tremer <[email protected]> wrote: > > Hello Erik, > >> On 21 Feb 2026, at 16:50, ummeegge <[email protected]> wrote: >> >> Hi all, >> >> Am Freitag, dem 20.02.2026 um 11:28 +0000 schrieb Michael Tremer: >>> Hello everyone, >>> >>> OpenVPN 2.7 is out! Finally. >>> >>> However, I am not entirely sure when we should make the switch. We >>> would gain a couple of features like DCO, but so far not many people >>> have actually asked for them. Although it would improve bandwidth, I >>> don’t think many people have a lot of OpenVPN traffic on weak >>> hardware so that this is an issue. >> i would disagree in this point — DCO is a fundamental improvement of >> the data channel (fewer context switches, zero-copy, better kernel >> crypto integration) that benefits every setup with meaningful tunnel >> traffic, not just weak hardware. > > I am not saying that it is not improving things, but to be frank, if you want > throughput, you would have never chosen OpenVPN in the first place. People > have instead set up IPsec or in recent times WireGuard. > > DCO is extremely limited and we had to sacrifice some other features to make > it work in the future. That is very limiting to users and therefore I don’t > consider it a generally good solution. It is a patch that allows OpenVPN > users to keep up with alternatives that have been implemented in the kernel > space from the start. > >>> On the other hand, Adolf is right. Every OpenVPN upgrade is a huge >>> job. A lot of things are being changed and we only find out in the >>> middle of the testing phase. So what should we do? I suppose at some >>> point we have to make the switch. But until then I would not mind to >>> have at least a few of the teething issues resolved in a .1, or even >>> .2 release. >>> >>> Regarding the redirect-gateway problem, I cannot see anything in the >>> change log that touched this. This therefore proves my point from >>> above that there are a lot of hidden “features” to find. Erik, what >>> needs to be changed to make the message go away; what change of >>> behaviour would we see? >> - I've looked a bit deeper into the MULTI ERROR that appears when using >> ifconfig-push in CCD files. >> >> The root cause is the switch in topology: the old OpenVPN documentation >> (based on topology net30) describes exactly our use case – group >> separation via IP ranges. With the move to topology subnet (required >> for DCO), this check has become stricter, triggering the error. >> >> I've opened an issue in the OpenVPN project to discuss this problem and >> a possible solution: https://github.com/OpenVPN/openvpn/issues/987 > > You really need to use a lot less AI stuff. This report is unnecessary long > and really does not get to the point. > > You are proposing a breaking change which will never be rolled out unless all > clients have been upgraded to a version that implements your proposed > changes. We are talking about pushing routes. This is barely an advanced > feature for a VPN application. > > You are also referring to yourself as “we”. Who else is working on this? > >> The feedback came quickly: the topic is known, but it's not a quick fix >> – "it's more than a one-liner". > > How is this feedback? What will we do with it? Does this mean it will > eventually be fixed, but not yet? Does it mean that it is too much work and > will never be fixed whatsoever? > >> What does this mean for us? >> Until something changes here, our setup with the known workaround >> (additional push directives in the CCD) continues to work stably. The >> connection is established, DCO remains active – we just have to live >> with the MULTI ERROR log message for now. >> >> Anyone who wants to follow this closely or contribute is welcome to >> drop by the GitHub issue. >> >> - According to --redirect-gateway: The most flexible solution is to >> keep it in the client setup but may the `def1` extension might be an >> idea in there (please see above). > > So we now have to implement some hacks which are clearly not supported > upstream to be able to use DCO under rare circumstances? Those hacks could > break with any new release. The performance gain is negligible for average > users logging into work using RDP and SSH. > > I really wish that OpenVPN would not give us these pain points all of the > time. > > -Michael > >> >>> >>> -Michael >>> >>>> On 19 Feb 2026, at 17:38, Adolf Belka <[email protected]> >>>> wrote: >>>> >>>> Hi Erik, >>>> >>>> On 19/02/2026 18:25, ummeegge wrote: >>>>> Hello Adolf, >>>>> great so you know about :-) . >>>>> Have you recognized the redirect-gateway message too ? >>>> >>>> No. I tested the build with my existing client connections by >>>> installing 2.7 and restoring my backup and testing out the >>>> connections for roadwarrior and n2n. None of my connections had the >>>> redirect-gateway option selected. >>>> >>>> >>>>> Also, did you check the new script in libexec `dns-updown` ? It >>>>> seems >>>>> that this is a kind of new feature from 2.7.0 (haven´t digged >>>>> deeper) ? >>>> >>>> No. I was just checking that existing connections would still work >>>> with 2.7 on my thought that we would first move from 2.6 to 2.7 and >>>> then look at additional options like DCO etc as follow-up >>>> modifications. Of course we could also jump right in to them but >>>> then there would need to be more testing for both the major version >>>> change and the additional options, especially if those are globally >>>> applied and implemented ones. I am not familiar enough with those >>>> options to come to any conclusion on that. >>>> >>>> I was just thinking of making any changes in smaller steps that are >>>> easier to confirm as working. >>>> I don't fancy another change like we had to do from 2.5 running >>>> without negotiation to 2.6 with all its changes. >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>> >>>>> Best, >>>>> Erik >>>>> Am Donnerstag, dem 19.02.2026 um 17:04 +0100 schrieb Adolf Belka: >>>>>> Hi Erik, >>>>>> >>>>>> >>>>>> On 19/02/2026 16:03, ummeegge wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> since OpenVPN 2.7.0 was released last week, I’ve done some >>>>>>> more >>>>>>> testing >>>>>>> with the new DCO flag. >>>>>>> >>>>>>> ``` >>>>>>> @@ -73,10 +73,10 @@ $(TARGET) : $(patsubst >>>>>>> %,$(DIR_DL)/%,$(objects)) >>>>>>> cd $(DIR_APP) && ./configure \ >>>>>>> --prefix=/usr \ >>>>>>> --sysconfdir=/var/ipfire/ovpn \ >>>>>>> - --enable-iproute2 \ >>>>>>> --enable-plugins \ >>>>>>> --enable-plugin-auth-pam \ >>>>>>> - --enable-plugin-down-root >>>>>>> + --enable-plugin-down-root \ >>>>>>> + --enable-dco >>>>>>> ``` >>>>>>> >>>>>>> I’ve found a couple of other issues: >>>>>>> >>>>>>> There have been some changes in the management interface, and >>>>>>> a >>>>>>> protocol prefix is now included (e.g. udp4:). >>>>>>> As a result, the old regex patterns for >>>>>>> a) OpenVPN Connection Statistics and >>>>>>> b) Connection Status >>>>>>> no longer update or show data. This shouldn’t be hard to fix. >>>>>> >>>>>> I already have patch fixes for this from my testing of the >>>>>> alpha3, >>>>>> beta1 and rc1. If you go to my IPFire git repo (link at end of >>>>>> this >>>>>> mail) the patch is in that rc1 branch. There is also the >>>>>> removal of >>>>>> the deprecated persist-key which is now always enabled by >>>>>> default. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Adolf. >>>>>> >>>>>>> >>>>>>> With OpenVPN 2.7.0, a MULTI ERROR appears when creating a >>>>>>> client >>>>>>> with >>>>>>> “redirect-gateway”. Example message: >>>>>>> >>>>>>> ``` >>>>>>> Feb 19 13:34:36 ipfire-prime openvpnserver[7329]: >>>>>>> PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary >>>>>>> virtual >>>>>>> IP >>>>>>> for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) >>>>>>> violates >>>>>>> tunnel >>>>>>> network/netmask constraint (10.73.104.0/255.255.255.0) >>>>>>> ``` >>>>>>> >>>>>>> The connection still works fine, but the log entries don’t >>>>>>> look >>>>>>> good. >>>>>>> This happens because older setups used `redirect-gateway >>>>>>> def1` in >>>>>>> the >>>>>>> advanced options, and remnants of this are still present in >>>>>>> server.conf >>>>>>> (push "redirect-gateway def1"), even though the checkbox for >>>>>>> this >>>>>>> option has disappeared. >>>>>>> >>>>>>> When creating a new client, enabling redirect-gateway (here >>>>>>> without >>>>>>> def1) now triggers this MULTI ERROR (“violates tunnel >>>>>>> network/netmask >>>>>>> constraint”). >>>>>>> >>>>>>> Using redirect-gateway def1 might actually be the better and >>>>>>> more >>>>>>> modern approach, since it adds two more specific routes >>>>>>> (0.0.0.0/1 >>>>>>> and >>>>>>> 128.0.0.0/1) instead of replacing the original default route >>>>>>> — >>>>>>> keeping >>>>>>> it available as a fallback. >>>>>>> >>>>>>> → Should `redirect-gateway def1` therefore be pushed globally >>>>>>> for >>>>>>> all >>>>>>> clients? If not explicitly configured otherwise, it would >>>>>>> still >>>>>>> apply. >>>>>>> >>>>>>> So far, DCO seems to makes his job. >>>>>>> >>>>>>> Some smaller issues have been noticed, but I think these are >>>>>>> the >>>>>>> key >>>>>>> points so far. >>>>>>> >>>>>>> Hope this mail isn’t **too long**, but I thought it might be >>>>>>> useful >>>>>>> to >>>>>>> share. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Erik >>>>>>> >>>>>>> Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb Adolf >>>>>>> Belka: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Follow-on from my previous mails about testing openvpn- >>>>>>>> 2.7_alpha3. >>>>>>>> >>>>>>>> Since then I have tested out openvpn-2.7_beta1 and today I >>>>>>>> tested >>>>>>>> out >>>>>>>> openvpn-2.7_rc1 >>>>>>>> >>>>>>>> It built without any problems and I also tested it on my vm >>>>>>>> system >>>>>>>> and confirmed that my android phone and linux laptop road >>>>>>>> warriors >>>>>>>> worked without any problems. >>>>>>>> I also tested out the n2 connection with openvpn-2.7_rc1 at >>>>>>>> one >>>>>>>> end >>>>>>>> and openvpn-2.6.15 at the other end and it connected >>>>>>>> without any >>>>>>>> issues. >>>>>>>> >>>>>>>> So the rc1 version has performed as the previous alpha3 and >>>>>>>> beta1 >>>>>>>> versions. >>>>>>>> >>>>>>>> I have merged the build branch into my ipfire repo >>>>>>>> >>>>>>>> https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=shortlog;h=refs/heads/openvpn-2.7_rc1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Adolf.
