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 4dbKnk6rv7z2yBF for ; Tue, 23 Dec 2025 16:14:02 +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 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 4dbKng1pdnz2xPc for ; Tue, 23 Dec 2025 16:13:59 +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 4dbKnc3P7xz2kD for ; Tue, 23 Dec 2025 16:13:56 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1766506436; 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=ZdfxB+1412d9s8aFwxdyATIuec5Jq4IEAtQxNgg8b3Y=; b=qTQh9CjlVh3WV8IxXUItxNU9IE0jiJ01Lq/CIGH8GViOJ27G/uznP4+lfRG2+HYfthba3L NyBgPKmPQcovvKCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1766506436; 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=ZdfxB+1412d9s8aFwxdyATIuec5Jq4IEAtQxNgg8b3Y=; b=gVNROZBVwDmQ1qJZXkbEnR0V3pHPrOEPcdJfDzw5V3JFoivtHkqxYWHK7qNldbOxAAevcS UqnmLYuXwdfjI9bg9mXnoZ+G1xUDWotffSZGNMpvF8dZsomMPD+wIGVO2aTW/myoW2F8SE wKdJUjiIzNRPi6R1QEnW/afz2pvd8qDkerX50KaGEfUT39OUI/tkEkeq7iuBKZlLeIumrR ckeyMHXrU9VCsFMWpAonKYDODiidw6iQTZqba4F9mkDJbdhv68m7wL4NA0GBM6ehs41IUl 3y13aRyyCh4lYJIKI4YNsb/xZtaUD+YIK+jKRqE3nokKaMiz7OEm5MCdILIwUA== Message-ID: Subject: Re: openvpn-2.7_rc1 From: ummeegge To: development@lists.ipfire.org Date: Tue, 23 Dec 2025 17:13:52 +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 Hello Michael, 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 sub= mit > 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 ` . To use DCO with versions < 2.7_rc4 , the old OpenVPN modul ovpn-dco https://github.com/OpenVPN/ovpn-dco needs to be used (seperate compilation, seperate package). Since Kernel 6.16 there is a in-tree `ovpn` modul=C2=A0https://github.com/OpenVPN/ovpn-net-next which will be shipped with the Kernel=C2=A0https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/log/drivers/net/ovpn . Arne has been published the 6.18.1 Kernel for testing which i have used for those tests. ` # 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 # root @ ipfire-prime in ~ [16:47:31]=20 $ lsmod | grep ovpn ovpn 98304 0 ip6_udp_tunnel 16384 2 ovpn,wireguard udp_tunnel 36864 2 ovpn,wireguard ` 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-december= -2025 . >=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 > > 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 > > =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 > All the best, > -Michael 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 > >=20 > > Best, > >=20 > > Erik > >=20 >=20