Re: openvpn-2.7_rc1

[Michael Tremer <michael.tremer@ipfire.org>]

Hello Erik,

> On 23 Dec 2025, at 16:13, ummeegge <ummeegge@ipfire.org> 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 <ummeegge@ipfire.org> 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