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 4dgVv41ztfz32MW for ; Tue, 30 Dec 2025 11:18:08 +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 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dgVv053Ljz2xPc for ; Tue, 30 Dec 2025 11:18:04 +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 4dgVtv0tTMz2kD for ; Tue, 30 Dec 2025 11:17:59 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1767093479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vxEpThcVTFqASE0cxU+ceIQSqvSbISzFwRW0z8u1K6o=; b=YazzWWeOo6WScqfTU2wot0vsBks79s7n06k/85OD/ZV6QXM0+5mQ5l6qwYMJRbi0E6FZHd cMQvMEzjHDLJzfDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1767093479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vxEpThcVTFqASE0cxU+ceIQSqvSbISzFwRW0z8u1K6o=; b=fTVO0+4XxTS6QwQCvefjV7NFPCbC9UjyurVG9uiXAo5VOawY5UmbOaK7FU0ertj9oa7KgT hAAP36devFy50hWqt1bZvftB6JbdhmJsv4hL/9PBL+l36gstROT2NEFaPXezWbRnUTIJJZ 6XUzEjEulVCChMSrW3E+sUFQPAM6iOQNxcCfVv1lbZfy0UagMpZI05yi3B5pI61QnN1bEL SanCH0ISDi2HdTRfLHaU8ZPWcYTQsm7n+evAs1vDixsiZBNJvOo2d6aFbKJCISx0DpGzxJ fwTZin0F5spICMiVL8NXHUgNQhIJ/rr90F8Ww3KHvXT+9UcG2MialgIQ6246Qw== Message-ID: Subject: Re: openvpn-2.7_rc1 From: ummeegge To: development@lists.ipfire.org Date: Tue, 30 Dec 2025 12:17:58 +0100 In-Reply-To: References: <4247a605-6aac-4c9c-93c8-db236c2cb769@ipfire.org> <95de13b9655902ecd319bb998a94bdd8f10186b7.camel@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 Am Sonntag, dem 28.12.2025 um 12:18 +0000 schrieb Michael Tremer: > Hello Erik, >=20 > > On 23 Dec 2025, at 16:13, ummeegge wrote: > >=20 > > Hello Michael, > >=20 > > Am Dienstag, dem 23.12.2025 um 12:27 +0100 schrieb Michael Tremer: > > > Hello Erik, > > >=20 > > > Great that you are already testing OpenVPN 2.7. As we have > > > already > > > seen a couple of RCs, the release should be fairly close. We will > > > probably upgrade very quickly after the final version has been > > > released. > > >=20 > > > However, I believe that OpenVPN 2.6 should already be supporting > > > DCO, > > > however there is this message in the logs: > > >=20 > > > configure: WARNING: DCO cannot be enabled when using iproute2 > > > configure: WARNING: DCO support disabled > > >=20 > > > So you are right with your changes to the configure command. > > > Since we > > > won=E2=80=99t have to wait until 2.7 is release, would you be able to > > > submit > > > a patch so we can ship a DCO-enabled OpenVPN with the new kernel? > > i can, but the "DCO support disabled" will be persistent also with > > the > > new 6.18.1 Kernel > > ` > > Dec 23 15:56:02 ipfire-prime openvpnserver[17008]: Note: Kernel > > support > > for ovpn-dco missing, disabling data channel offload. > > Dec 23 15:56:02 ipfire-prime openvpnserver[17008]: OpenVPN 2.6.14 > > x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] > > [MH/PKTINFO] > > [AEAD] [DCO] > > Dec 23 15:56:02 ipfire-prime openvpnserver[17008]: library > > versions: > > OpenSSL 3.6.0 1 Oct 2025, LZO 2.10 > > Dec 23 15:56:02 ipfire-prime openvpnserver[17008]: DCO version: N/A > > ` > >=20 > > . To use DCO with versions < 2.7_rc4 , the old OpenVPN modul ovpn- > > dco > > https://github.com/OpenVPN/ovpn-dco=C2=A0needs to be used (seperate > > compilation, seperate package). Since Kernel 6.16 there is a in- > > tree > > `ovpn` modul https://github.com/OpenVPN/ovpn-net-next=C2=A0which will b= e > > shipped with the > > Kernel > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/= drivers/net/ovpn > >=20 > > . Arne has been published the 6.18.1 Kernel for testing which i > > have > > used for those tests. >=20 > I cannot see anything about the OpenVPN DCO module that is included > in the mainline kernel being incompatible with OpenVPN 2.6. Where did > you get this information from? You can find it in the release history of OpenVPN 2.7_rc4 release https://community.openvpn.net/ReleaseHistory#openvpn-27_rc4-released-17-dec= ember-2025 . The quote "Support for new upstream DCO Linux kernel module This release supports the new ovpn DCO Linux kernel module which will be available in future upstream Linux kernel releases."=20 or better/more explained in the README.dco https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#getting-starte= d-linux . The logs which i posted above does reflect that OpenVPN-2.6.x even with compiled `--enable-dco` option does not work with the kernels `ovpn` module, it works only with the old `ovpn-dco` which reaches in the old branch his EOL . According to the https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#limitations-by= -design limitations, have tested it with `--compress migrate` in server.conf and DCO works also with this option and a regular client.ovpn . >=20 > > ` > > # root @ ipfire-prime in ~ [16:46:58]=20 > > $ uname -a=20 > > Linux ipfire-prime.local 6.18.1-ipfire #1 SMP PREEMPT_DYNAMIC Mon > > Dec > > 15 10:07:30 GMT 2025 x86_64 GNU/Linux > >=20 > > # root @ ipfire-prime in ~ [16:47:31]=20 > > $ lsmod | grep ovpn > > ovpn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 98304=C2=A0 0 > > ip6_udp_tunnel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16384=C2= =A0 2 ovpn,wireguard > > udp_tunnel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 36864=C2=A0 2 ovpn,wireguard > >=20 > > ` > >=20 > > So we would need the new Kernel but also an OpenVPN >=3D 2.7_rc4 > > version > > which also uses the new modul > > https://community.openvpn.net/Downloads#openvpn-27_rc4-released-17-dece= mber-2025 > > . > >=20 > >=20 > > >=20 > > > > On 20 Dec 2025, at 19:05, ummeegge wrote: > > > >=20 > > > > Hello Adolf and all, > > > > wanted to deliver also some results to the 2.7 version of > > > > OpenVPN, > > > > which is currently on rc4 release. Meanwhile i use the rc4 > > > > candidate > > > > with the new Kernel 6.18.1 which Arne delivered for testing. > > > >=20 > > > > Have compiled rc4 with the following diff > > > > ` > > > > @@ -73,10 +73,10 @@ $(TARGET) : $(patsubst > > > > %,$(DIR_DL)/%,$(objects)) > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cd $(DIR_APP) && ./configure \ > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --prefix=3D/usr \ > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --sysconfdir=3D/var/ipfire/ovpn \ > > > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-iproute2 \ > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-plugins \ > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-plugin-auth-pam \ > > > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-plugin-down-root > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-plugin-down-root \ > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --enable-dco > > > >=20 > > > > ` and it uses the new ovpn Kernel modul out of the box if no > > > > CBC > > > > Cipher > > > > is in usage. Have set in the WUI `--data-cipher-fallback` to > > > > disabled > > > > and configured only GCM and ChaCha20 as Ciphers (if there is > > > > CBC > > > > somewhere included, DCO will disable itself at startup). > > > > So there was no more configuration needed to enable the "Data > > > > Channel > > > > Offload" . > > >=20 > > > These are some serious limitations, but in the current default > > > configuration our users should not walk into this. > > >=20 > > > Should we add a note to the CBC ciphers in the selection box that > > > choosing them would disable DCO? > > Good idea. > >=20 > > >=20 > > > > Made some rudimentary speedtests with speedtest.net with an > > > > Fedora > > > > 43 > > > > client via WLAN with this scenarios: > > > > 1) Direct and without OpenVPN to get a reference value of the > > > > line=20 > > > > 2) non-DCO OpenVPN 2.6 on client and server (without DCO) > > > > 3) Server-DCO OpenVPN-2.7_rc4 on IPFire (as Server) and with > > > > 2.6 > > > > (without DCO) on client side and > > > > 4) Full-DCO on both ends OpenVPN-2.7_rc4 with enabled DCO > > > >=20 > > > > which i wanted to provide here for you. > > > >=20 > > > > Download: > > > > =C2=A0 Direkt:=C2=A0=C2=A0=C2=A0=C2=A0 49.39 Mbps > > > > =C2=A0 non-DCO:=C2=A0=C2=A0=C2=A0 23.99 Mbps > > >=20 > > > This is an insane drop. Why would it drop so much when the > > > bottleneck > > > is clearly the WiFi and not OpenVPN? > > Haven=C2=B4t trust my eyes either :-) . > >=20 > > >=20 > > > > =C2=A0 Server-DCO: 44.63 Mbps > > > > =C2=A0 Full DCO:=C2=A0=C2=A0 47.84 Mbps > > > >=20 > > > > Upload: > > > > =C2=A0 Direkt:=C2=A0=C2=A0=C2=A0=C2=A0 20.93 Mbps > > > > =C2=A0 non-DCO:=C2=A0=C2=A0=C2=A0 19.66 Mbps > > > > =C2=A0 Server-DCO: 20.59 Mbps > > > > =C2=A0 Full DCO:=C2=A0=C2=A0 20.54 Mbps > > > >=20 > > > > Idle latency: > > > > =C2=A0 Direkt:=C2=A0=C2=A0=C2=A0=C2=A0 14 ms > > > > =C2=A0 non-DCO:=C2=A0=C2=A0=C2=A0 15 ms > > > > =C2=A0 Server-DCO: 16 ms > > > > =C2=A0 Full DCO:=C2=A0=C2=A0 15 ms > > > >=20 > > > > Download latency: > > > > =C2=A0 Direkt:=C2=A0=C2=A0=C2=A0=C2=A0 41 ms > > > > =C2=A0 non-DCO:=C2=A0=C2=A0=C2=A0 171 ms > > >=20 > > > The same goes here. This is a huge increase in latency which will > > > explain the large drop in throughput. > > >=20 > > > > =C2=A0 Server-DCO: 53 ms > > > > =C2=A0 Full DCO:=C2=A0=C2=A0 58 ms > > > >=20 > > > > Upload latency: > > > > =C2=A0 Direkt:=C2=A0=C2=A0=C2=A0=C2=A0 35 ms > > > > =C2=A0 non-DCO:=C2=A0=C2=A0=C2=A0 37 ms > > > > =C2=A0 Server-DCO: 36 ms > > > > =C2=A0 Full DCO:=C2=A0=C2=A0 35 ms > > > >=20 > > > > Was at first not sure if something went wrong and i e.g. > > > > bypassed > > > > accidentially the tunnel but mtr showed that all is OK. > > > >=20 > > > > I know that these results are not representative but i wanted > > > > nevertheless to let you know. May someone wants to give it also > > > > a > > > > try. > > > >=20 > > > > Also, a lot hass been changed to the better in 2.7 IMHO. > > >=20 > > > Like what? I think the major changes have been happening in 2.6 > > > and > > > 2.7 only requires minimal changes in the IPFire tooling to make > > > the > > > upgrade work. > > Yes, it is like that there is no need for tooling something up to > > get > > this upgrade up and working except the above mentioned (Kernel > > compile > > time options). Even the DCO part comes automatically also if the > > client > > does not support it, it will speed things up on IPFire itself. > > Another > > part which i recognized was the usage of ML-KEM-768 (PQC) and > > X25519 > > (Post Quantum Hybrid) which points a cipher negotiation also for > > the > > Control Channel out (switch from ffdhe to dh none --> ECDH) if the > > client supports this but this have happend already in 2.6.14 which > > i > > have overlooked a little at the first. > >=20 > > >=20 > > > All the best, > > > -Michael > >=20 > > What do you think how to proceed further ? May you know when the > > new > > Kernel 6.18.x comes for IPFire (runs great here :D ) ? Have > > currently > > not seen something about a release date for OpenVPN-2.7.0 but it is > > close. All the best to all and i wish you a happy Christmas :-) . >=20 > The plan is to merge this into next as soon as possible. Great news. Will keep an eye of the OpenVPN-2.7.0 release. Have seen two warnings in the logs. The first one is about the deprecation of `--persist-key` as an option since it is implemented in the code but Adolf made already a patch for this. The second one was because of `--redirect-gateway` which collides with `--redirect- private` . I think it has something to do with the global `--redirect- gateway` in server.conf and also, if it has been set, the `--redirect- gateway` in CCD but except the warning, nothing else has happened. If i=C2=B4 am back home i can dive into it a little deeper. >=20 > I don=E2=80=99t think that we have any blockers remaining except not havi= ng a > kernel for ARM. I haven=E2=80=99t heard from Arne for a little while now,= so > I assume this is a little bit more tricky than usual. >=20 > Best, > -Michael >=20 > > >=20 > > > >=20 > > > > Best, > > > >=20 > > > > Erik >=20 >=20