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 4fJCmk0cg7z33kD for ; Sat, 21 Feb 2026 16:51:02 +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 4fJCmf3L1yz2xKC for ; Sat, 21 Feb 2026 16:50:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fJCmd0f3NzF2; Sat, 21 Feb 2026 16:50:57 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771692657; 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=4I9Rq9TwNZVJZcs3l0s9Z+Uk7GMuySOiosXA0S2KUvM=; b=h0zvbtWxtcPola4JT4NH9memRzAIDkqdHIZmxHF9jgEogDwMsBmlf1KEDbyfek4reH7pBg ZyAZK/8o7FtbZVBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771692657; 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=4I9Rq9TwNZVJZcs3l0s9Z+Uk7GMuySOiosXA0S2KUvM=; b=fliaeT0ubthPgmNNgvR2qIkp/csoxrkRgeriWXMalNZ8Zc2HJBvN0vZqOf1EuRin7NvdHE CIiaMpvcaSFLpuX1uM/7lg4bgvwN81hZ++8xXFE7qZnzjIYvImEjpnbPgSQP8gXPhzOwT+ MJfTmZYIQmWigG2LwPXoAe8DgDl507wB3nb94VVS//n6Zd8vmrvrh436hZt9qNHi8Twwii 5IGMPZYFqtAiT5ZNr/PIOKEOaO0j+Dn6m+FBC01zteOI01FifBGwyKs6J2qAEPcFiiW1E4 mdDG+X+l5k1BG8Zg3ED486pdPYzJLKGvaZyFbx4okgPkj/YD8wMoE0QQ9Uckqw== Message-ID: <3556afcad312edbc2fec0f51202ba7ec832af1ce.camel@ipfire.org> Subject: Re: openvpn-2.7_rc1 From: ummeegge To: Michael Tremer , Adolf Belka Cc: "IPFire: Development-List" Date: Sat, 21 Feb 2026 17:50:52 +0100 In-Reply-To: <281A0C82-AF08-471A-AAD5-FC2A4FDA2985@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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Hi all, 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 o= f 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 > 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. 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. I've opened an issue in the OpenVPN project to discuss this problem and a possible solution: https://github.com/OpenVPN/openvpn/issues/987 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". 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 liv= e 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). >=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 som= e > > > > > 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=99= 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. > > > > >=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 glob= ally > > > > > 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