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 4dfJLC71Htz332T for ; Sun, 28 Dec 2025 12:18:59 +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 4dfJL82wQ3z2xLt for ; Sun, 28 Dec 2025 12:18:56 +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 4dfJL666ymzbB; Sun, 28 Dec 2025 12:18:54 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1766924335; 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=nuc26XeUUXc091YINjtIOor6d5LY4+/4yHRoQVDRzxg=; b=fiZOPjsK7msc1M+KUVbG3af+90p+Pir/M+xRgdXojiME5t3qqtiToLF+6NZx1dScTxOGqI GtlQ2fcsLOXpzPBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1766924335; 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=nuc26XeUUXc091YINjtIOor6d5LY4+/4yHRoQVDRzxg=; b=B7njg6c/KrFP1yYGtyDSO2cz9XKeWk8l0BCTh29e2cZTeefMA00XG+I/OEVm67yTWoWM5z ryChOCOhxYh4mgOfETW6pH9h3gW8Vlto2yA8t+u5QY29OAgaql5qe4JCDxYbWu2QpnsC55 ia9yVBfHQ2gwMiTV8bzBzbc4olSyigkBAsADmMCLIcwIKraB5TqbH7XLsvbXzUMc8IWGYc OamX1Z4GGfOC9sowSXcD3dHMGbJgnbhLJOWgsRpSSxixMSFc0Gu/FRyyp2SAH1gqSjjuBP VAiG5w2BY0ybYCzjlRARvfhhIP/G5j7oRzrIQR4MfFl/gHfOSRS88d2bEyt8Ew== 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: Date: Sun, 28 Dec 2025 12:18:54 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4247a605-6aac-4c9c-93c8-db236c2cb769@ipfire.org> <95de13b9655902ecd319bb998a94bdd8f10186b7.camel@ipfire.org> To: ummeegge Hello Erik, > 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 needs 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 which will be > shipped with the > Kernel = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/dri= vers/net/ovpn >=20 > . Arne has been published the 6.18.1 Kernel for testing which i have > used for those tests. 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? > ` > # 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 98304 0 > ip6_udp_tunnel 16384 2 ovpn,wireguard > udp_tunnel 36864 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-decembe= r-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)) >>> 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 >>> ` 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: >>> Direkt: 49.39 Mbps >>> non-DCO: 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 >>> Server-DCO: 44.63 Mbps >>> Full DCO: 47.84 Mbps >>>=20 >>> Upload: >>> Direkt: 20.93 Mbps >>> non-DCO: 19.66 Mbps >>> Server-DCO: 20.59 Mbps >>> Full DCO: 20.54 Mbps >>>=20 >>> Idle latency: >>> Direkt: 14 ms >>> non-DCO: 15 ms >>> Server-DCO: 16 ms >>> Full DCO: 15 ms >>>=20 >>> Download latency: >>> Direkt: 41 ms >>> non-DCO: 171 ms >>=20 >> The same goes here. This is a huge increase in latency which will >> explain the large drop in throughput. >>=20 >>> Server-DCO: 53 ms >>> Full DCO: 58 ms >>>=20 >>> Upload latency: >>> Direkt: 35 ms >>> non-DCO: 37 ms >>> Server-DCO: 36 ms >>> Full DCO: 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 :-) . The plan is to merge this into next as soon as possible. I don=E2=80=99t think that we have any blockers remaining except not = having 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. Best, -Michael >>=20 >>>=20 >>> Best, >>>=20 >>> Erik