openvpn-2.7_rc1

openvpn-2.7_rc1

[Adolf Belka]

Hi All,

Follow-on from my previous mails about testing openvpn-2.7_alpha3.

Since then I have tested out openvpn-2.7_beta1 and today I tested out openvpn-2.7_rc1

It built without any problems and I also tested it on my vm system and confirmed that my android phone and linux laptop road warriors worked without any problems.
I also tested out the n2 connection with openvpn-2.7_rc1 at one end and openvpn-2.6.15 at the other end and it connected without any issues.

So the rc1 version has performed as the previous alpha3 and beta1 versions.

I have merged the build branch into my ipfire repo

https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=shortlog;h=refs/heads/openvpn-2.7_rc1

Regards,

Adolf.

Re: openvpn-2.7_rc1

[Michael Tremer]

👍

> On 6 Nov 2025, at 21:19, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> Follow-on from my previous mails about testing openvpn-2.7_alpha3.
> 
> Since then I have tested out openvpn-2.7_beta1 and today I tested out openvpn-2.7_rc1
> 
> It built without any problems and I also tested it on my vm system and confirmed that my android phone and linux laptop road warriors worked without any problems.
> I also tested out the n2 connection with openvpn-2.7_rc1 at one end and openvpn-2.6.15 at the other end and it connected without any issues.
> 
> So the rc1 version has performed as the previous alpha3 and beta1 versions.
> 
> I have merged the build branch into my ipfire repo
> 
> https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=shortlog;h=refs/heads/openvpn-2.7_rc1
> 
> Regards,
> 
> Adolf.
> 

Re: openvpn-2.7_rc1

[ummeegge]

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

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

Best,

Erik

Re: openvpn-2.7_rc1

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

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

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

Re: openvpn-2.7_rc1

[ummeegge]

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.

`
# 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 :-) .
> 
> > 
> > Best,
> > 
> > Erik
> > 
> 

Re: openvpn-2.7_rc1

[Michael Tremer]

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

Re: openvpn-2.7_rc1

[ummeegge]

Am Sonntag, dem 28.12.2025 um 12:18 +0000 schrieb Michael Tremer:
> 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?

You can find it in the release history of OpenVPN 2.7_rc4 release
https://community.openvpn.net/ReleaseHistory#openvpn-27_rc4-released-17-december-2025
. The quote "Support for new upstream DCO Linux kernel module

    This release supports the new ovpn DCO Linux kernel module which
will be available in future upstream Linux kernel releases." 

or better/more explained in the README.dco
https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#getting-started-linux
. The logs which i posted above does reflect that OpenVPN-2.6.x even
with compiled `--enable-dco` option does not work with the kernels
`ovpn` module, it works only with the old `ovpn-dco` which reaches in
the old branch his EOL .

According to the
https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#limitations-by-design
limitations, have tested it with `--compress migrate` in server.conf
and DCO works also with this option and a regular client.ovpn .

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

Great news. Will keep an eye of the OpenVPN-2.7.0 release.

Have seen two warnings in the logs. The first one is about the
deprecation of `--persist-key` as an option since it is implemented in
the code but Adolf made already a patch for this. The second one was
because of `--redirect-gateway` which collides with `--redirect-
private` . I think it has something to do with the global `--redirect-
gateway` in server.conf and also, if it has been set, the `--redirect-
gateway` in CCD but except the warning, nothing else has happened. If
i´ am back home i can dive into it a little deeper.

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