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?

> 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?

> 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?

>   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.

All the best,
-Michael

> 
> Best,
> 
> Erik
> 


Reply via email to