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 4fLgDK5FZmz2yBG for ; Wed, 25 Feb 2026 16:34:57 +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 "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fLgDG0dJBz2xHk for ; Wed, 25 Feb 2026 16:34:54 +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 4fLgDD6Gxtz1T3; Wed, 25 Feb 2026 16:34:52 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1772037293; 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=TUhw/ZSCj3LF32stCE5fXcu0MBjSTANMn+lfMBLLZBE=; b=PZJzXiNaveH6YiCP77W93rtzwnN2CAfFr3apBMwCcAXS9lnMxXu5x0VW1G5YyLcdKTnP31 mNKTPbsrwrNEwVDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1772037293; 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=TUhw/ZSCj3LF32stCE5fXcu0MBjSTANMn+lfMBLLZBE=; b=TqzHIrZaFRpjAPKK/oPL59p7S367WycqfvOo1AKjMSWFUFVXobdevw3ANOkJL0UKZU87ZR U4jxmCFGarzEm+tmAd8mQmiTJoiQj3zs5X1nZ+84EexmAYk4NeMgILH93O9wIPLlHPOb3F EVVk3wWqNE5jjCNILSrwa3OLMtYREUpEBFiyJOo9Lq/K0HaytUDTyeSy4PWFBE4bqNQD+R MeSqgsfjzDriu97qK0hgB343NbXa9c9g2fg5fDpsFio3W+KHwUayTfawc4aZeGXhpAYCU3 Gi4c7TZU+g2VqeW+04gCa1V7QRjBtKtCKCGU+ABfG/0El40mojGazPj1QBLmVw== 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: openvpn-2.7_rc1 From: Michael Tremer In-Reply-To: <09DCA30B-E8F0-4082-BC21-46A452BE26E0@ipfire.org> Date: Wed, 25 Feb 2026 16:34:51 +0000 Cc: Adolf Belka , "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <7A7871F9-75CC-4605-8337-BB7BFC61072F@ipfire.org> References: <4247a605-6aac-4c9c-93c8-db236c2cb769@ipfire.org> <414d5c1c72ceabb0f3051ba917bb45ff7de3f90f.camel@ipfire.org> <7b53160b-eb3a-4b1b-b068-94057bd680e1@ipfire.org> <1eccafd1bfb3b86c75dd7b3082fd204c3a70e38a.camel@ipfire.org> <8a117269-3a2f-4226-b6cc-39e5f7a9b529@ipfire.org> <281A0C82-AF08-471A-AAD5-FC2A4FDA2985@ipfire.org> <3556afcad312edbc2fec0f51202ba7ec832af1ce.camel@ipfire.org> <09DCA30B-E8F0-4082-BC21-46A452BE26E0@ipfire.org> To: ummeegge 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 = wrote: >=20 > Hello Erik, >=20 >> On 21 Feb 2026, at 16:50, ummeegge wrote: >>=20 >> Hi all, >>=20 >> Am Freitag, dem 20.02.2026 um 11:28 +0000 schrieb Michael Tremer: >>> Hello everyone, >>>=20 >>> OpenVPN 2.7 is out! Finally. >>>=20 >>> 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=E2=80=99t think many people have a lot of OpenVPN traffic on = weak >>> hardware so that this is an issue. >> i would disagree in this point =E2=80=94 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. >=20 > 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. >=20 > 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=E2=80=99t 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. >=20 >>> 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. >>>=20 >>> 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 =E2=80=9Cfeatures=E2=80=9D 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. >>=20 >> The root cause is the switch in topology: the old OpenVPN = documentation >> (based on topology net30) describes exactly our use case =E2=80=93 = group >> separation via IP ranges. With the move to topology subnet (required >> for DCO), this check has become stricter, triggering the error. >>=20 >> I've opened an issue in the OpenVPN project to discuss this problem = and >> a possible solution: https://github.com/OpenVPN/openvpn/issues/987 >=20 > You really need to use a lot less AI stuff. This report is unnecessary = long and really does not get to the point. >=20 > 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. >=20 > You are also referring to yourself as =E2=80=9Cwe=E2=80=9D. Who else = is working on this? >=20 >> The feedback came quickly: the topic is known, but it's not a quick = fix >> =E2=80=93 "it's more than a one-liner". >=20 > 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? >=20 >> 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 =E2=80=93 we just have = to live >> with the MULTI ERROR log message for now. >>=20 >> Anyone who wants to follow this closely or contribute is welcome to >> drop by the GitHub issue. >>=20 >> - 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). >=20 > 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. >=20 > I really wish that OpenVPN would not give us these pain points all of = the time. >=20 > -Michael >=20 >>=20 >>>=20 >>> -Michael >>>=20 >>>> On 19 Feb 2026, at 17:38, Adolf Belka >>>> wrote: >>>>=20 >>>> Hi Erik, >>>>=20 >>>> On 19/02/2026 18:25, ummeegge wrote: >>>>> Hello Adolf, >>>>> great so you know about :-) . >>>>> Have you recognized the redirect-gateway message too ? >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>> 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=C2=B4t digged >>>>> deeper) ? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>=20 >>>>> Best, >>>>> Erik >>>>> Am Donnerstag, dem 19.02.2026 um 17:04 +0100 schrieb Adolf Belka: >>>>>> Hi Erik, >>>>>>=20 >>>>>>=20 >>>>>> On 19/02/2026 16:03, ummeegge wrote: >>>>>>> Hi all, >>>>>>>=20 >>>>>>> since OpenVPN 2.7.0 was released last week, I=E2=80=99ve done = some >>>>>>> more >>>>>>> testing >>>>>>> with the new DCO flag. >>>>>>>=20 >>>>>>> ``` >>>>>>> @@ -73,10 +73,10 @@ $(TARGET) : $(patsubst >>>>>>> %,$(DIR_DL)/%,$(objects)) >>>>>>> cd $(DIR_APP) && ./configure \ >>>>>>> --prefix=3D/usr \ >>>>>>> --sysconfdir=3D/var/ipfire/ovpn \ >>>>>>> - --enable-iproute2 \ >>>>>>> --enable-plugins \ >>>>>>> --enable-plugin-auth-pam \ >>>>>>> - --enable-plugin-down-root >>>>>>> + --enable-plugin-down-root \ >>>>>>> + --enable-dco >>>>>>> ``` >>>>>>>=20 >>>>>>> I=E2=80=99ve found a couple of other issues: >>>>>>>=20 >>>>>>> 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=E2=80=99t be hard to = fix. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>>>=20 >>>>>>> With OpenVPN 2.7.0, a MULTI ERROR appears when creating a >>>>>>> client >>>>>>> with >>>>>>> =E2=80=9Credirect-gateway=E2=80=9D. Example message: >>>>>>>=20 >>>>>>> ``` >>>>>>> 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) >>>>>>> ``` >>>>>>>=20 >>>>>>> The connection still works fine, but the log entries don=E2=80=99t= >>>>>>> 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. >>>>>>>=20 >>>>>>> When creating a new client, enabling redirect-gateway (here >>>>>>> without >>>>>>> def1) now triggers this MULTI ERROR (=E2=80=9Cviolates tunnel >>>>>>> network/netmask >>>>>>> constraint=E2=80=9D). >>>>>>>=20 >>>>>>> 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 >>>>>>> =E2=80=94 >>>>>>> keeping >>>>>>> it available as a fallback. >>>>>>>=20 >>>>>>> =E2=86=92 Should `redirect-gateway def1` therefore be pushed = globally >>>>>>> for >>>>>>> all >>>>>>> clients? If not explicitly configured otherwise, it would >>>>>>> still >>>>>>> apply. >>>>>>>=20 >>>>>>> So far, DCO seems to makes his job. >>>>>>>=20 >>>>>>> Some smaller issues have been noticed, but I think these are >>>>>>> the >>>>>>> key >>>>>>> points so far. >>>>>>>=20 >>>>>>> Hope this mail isn=E2=80=99t **too long**, but I thought it = might be >>>>>>> useful >>>>>>> to >>>>>>> share. >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Erik >>>>>>>=20 >>>>>>> Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb Adolf >>>>>>> Belka: >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> Follow-on from my previous mails about testing openvpn- >>>>>>>> 2.7_alpha3. >>>>>>>>=20 >>>>>>>> Since then I have tested out openvpn-2.7_beta1 and today I >>>>>>>> tested >>>>>>>> out >>>>>>>> openvpn-2.7_rc1 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> So the rc1 version has performed as the previous alpha3 and >>>>>>>> beta1 >>>>>>>> versions. >>>>>>>>=20 >>>>>>>> I have merged the build branch into my ipfire repo >>>>>>>>=20 >>>>>>>> = https://git.ipfire.org/?p=3Dpeople/bonnietwin/ipfire-2.x.git;a=3Dshortlog;= h=3Drefs/heads/openvpn-2.7_rc1 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf.