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 4fKP3W2dMKz32L8 for ; Mon, 23 Feb 2026 14:52:55 +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 "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fKP3R6Wwjz2xHP for ; Mon, 23 Feb 2026 14:52:51 +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 4fKP3Q4Dbrz32C; Mon, 23 Feb 2026 14:52:50 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771858371; 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=9WBkC9ZIjkutrCmZobhXRK0GURiRuv2hAF1dhP1qoJo=; b=3g4ksAtvsllL4UdVsvj63OKtWfzdoNCXyiEh4pDbk/HEzwH8ZLmR1d+SzgCz2juFoPxJ/H clzwpJcD6nenoxAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771858371; 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=9WBkC9ZIjkutrCmZobhXRK0GURiRuv2hAF1dhP1qoJo=; b=DFbR3nIb0l05ET/hm7iHrIeqzZxLVPjc9XKSxigUEoQRZuPQxNIkJkt9cfSoBvW7PoNHWG L8njGO2ga7/68AH4j0XJH9VkHHyQZQyEuedEV1GN+SNQz/8xkOwfUh3aSIVX5gD7vR9/Is HUaFtbwcdBhxm6vsiE0X6PUZdb9BbuBFHHlZ+VJx4qhFp4unlPz7Yn6qhhWSTcDdeymqjW LoETSeragasCrEGw9gsC+Bro58rvmsyPOPVnIZEvF4fdFBktsePN/pszBxrFEDc99nkjjS tQThxqWVao8M+hMC4lWWvHOuo14oOiuzjACuej8B3lvYP+cYyKggbUbAO7DbjQ== 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: <3556afcad312edbc2fec0f51202ba7ec832af1ce.camel@ipfire.org> Date: Mon, 23 Feb 2026 14:52:50 +0000 Cc: Adolf Belka , "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <09DCA30B-E8F0-4082-BC21-46A452BE26E0@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> To: ummeegge Hello Erik, > 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. 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=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. >> 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 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 =E2=80=9Cwe=E2=80=9D. Who else is = working on this? > 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". 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 =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). 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 >=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. >>>>>>=20 >>>>>=20 >>>=20 >>>=20