Hello Erik, > On 23 Dec 2025, at 16:13, ummeegge <[email protected]> wrote: > > Hello Michael, > > Am Dienstag, dem 23.12.2025 um 12:27 +0100 schrieb Michael Tremer: >> Hello Erik, >> >> 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. >> >> However, I believe that OpenVPN 2.6 should already be supporting DCO, >> however there is this message in the logs: >> >> configure: WARNING: DCO cannot be enabled when using iproute2 >> configure: WARNING: DCO support disabled >> >> So you are right with your changes to the configure command. Since we >> won’t 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 > ` > > . 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/drivers/net/ovpn > > . 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] > $ uname -a > 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] > $ 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 >= 2.7_rc4 version > which also uses the new modul > https://community.openvpn.net/Downloads#openvpn-27_rc4-released-17-december-2025 > . > > >> >>> On 20 Dec 2025, at 19:05, ummeegge <[email protected]> wrote: >>> >>> 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. >>> >>> Have compiled rc4 with the following diff >>> ` >>> @@ -73,10 +73,10 @@ $(TARGET) : $(patsubst >>> %,$(DIR_DL)/%,$(objects)) >>> cd $(DIR_APP) && ./configure \ >>> --prefix=/usr \ >>> --sysconfdir=/var/ipfire/ovpn \ >>> - --enable-iproute2 \ >>> --enable-plugins \ >>> --enable-plugin-auth-pam \ >>> - --enable-plugin-down-root >>> + --enable-plugin-down-root \ >>> + --enable-dco >>> >>> ` 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" . >> >> These are some serious limitations, but in the current default >> configuration our users should not walk into this. >> >> Should we add a note to the CBC ciphers in the selection box that >> choosing them would disable DCO? > Good idea. > >> >>> 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 >>> 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 >>> >>> which i wanted to provide here for you. >>> >>> Download: >>> Direkt: 49.39 Mbps >>> non-DCO: 23.99 Mbps >> >> This is an insane drop. Why would it drop so much when the bottleneck >> is clearly the WiFi and not OpenVPN? > Haven´t trust my eyes either :-) . > >> >>> Server-DCO: 44.63 Mbps >>> Full DCO: 47.84 Mbps >>> >>> Upload: >>> Direkt: 20.93 Mbps >>> non-DCO: 19.66 Mbps >>> Server-DCO: 20.59 Mbps >>> Full DCO: 20.54 Mbps >>> >>> Idle latency: >>> Direkt: 14 ms >>> non-DCO: 15 ms >>> Server-DCO: 16 ms >>> Full DCO: 15 ms >>> >>> Download latency: >>> Direkt: 41 ms >>> non-DCO: 171 ms >> >> The same goes here. This is a huge increase in latency which will >> explain the large drop in throughput. >> >>> Server-DCO: 53 ms >>> Full DCO: 58 ms >>> >>> Upload latency: >>> Direkt: 35 ms >>> non-DCO: 37 ms >>> Server-DCO: 36 ms >>> Full DCO: 35 ms >>> >>> Was at first not sure if something went wrong and i e.g. bypassed >>> accidentially the tunnel but mtr showed that all is OK. >>> >>> 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. >>> >>> Also, a lot hass been changed to the better in 2.7 IMHO. >> >> 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. > >> >> 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 :-) . The plan is to merge this into next as soon as possible. I don’t think that we have any blockers remaining except not having a kernel for ARM. I haven’t heard from Arne for a little while now, so I assume this is a little bit more tricky than usual. Best, -Michael >> >>> >>> Best, >>> >>> Erik
