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

Re: openvpn-2.7_rc1

[ummeegge]

Hi all,

since OpenVPN 2.7.0 was released last week, I’ve done some more testing
with the new DCO flag.

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

I’ve found a couple of other issues:

There have been some changes in the management interface, and a
protocol prefix is now included (e.g. udp4:).
As a result, the old regex patterns for
a) OpenVPN Connection Statistics and
b) Connection Status
no longer update or show data. This shouldn’t be hard to fix.

With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client with
“redirect-gateway”. Example message:

```
Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual IP
for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates tunnel
network/netmask constraint (10.73.104.0/255.255.255.0)
```

The connection still works fine, but the log entries don’t look good.
This happens because older setups used `redirect-gateway def1` in the
advanced options, and remnants of this are still present in server.conf
(push "redirect-gateway def1"), even though the checkbox for this
option has disappeared.

When creating a new client, enabling redirect-gateway (here without
def1) now triggers this MULTI ERROR (“violates tunnel network/netmask
constraint”).

Using redirect-gateway def1 might actually be the better and more
modern approach, since it adds two more specific routes (0.0.0.0/1 and
128.0.0.0/1) instead of replacing the original default route — keeping
it available as a fallback.

→ Should `redirect-gateway def1` therefore be pushed globally for all
clients? If not explicitly configured otherwise, it would still apply.

So far, DCO seems to makes his job.

Some smaller issues have been noticed, but I think these are the key
points so far.

Hope this mail isn’t **too long**, but I thought it might be useful to
share.

Best,

Erik

Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb 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

[Adolf Belka]

Hi Erik,


On 19/02/2026 16:03, ummeegge wrote:
> Hi all,
> 
> since OpenVPN 2.7.0 was released last week, I’ve done some more testing
> with the new DCO flag.
> 
> ```
> @@ -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
> ```
> 
> I’ve found a couple of other issues:
> 
> There have been some changes in the management interface, and a
> protocol prefix is now included (e.g. udp4:).
> As a result, the old regex patterns for
> a) OpenVPN Connection Statistics and
> b) Connection Status
> no longer update or show data. This shouldn’t be hard to fix.

I already have patch fixes for this from my testing of the alpha3, beta1 and rc1. If you go to my IPFire git repo (link at end of this mail) the patch is in that rc1 branch. There is also the removal of the deprecated persist-key which is now always enabled by default.

Regards,

Adolf.

> 
> With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client with
> “redirect-gateway”. Example message:
> 
> ```
> Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
> PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual IP
> for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates tunnel
> network/netmask constraint (10.73.104.0/255.255.255.0)
> ```
> 
> The connection still works fine, but the log entries don’t look good.
> This happens because older setups used `redirect-gateway def1` in the
> advanced options, and remnants of this are still present in server.conf
> (push "redirect-gateway def1"), even though the checkbox for this
> option has disappeared.
> 
> When creating a new client, enabling redirect-gateway (here without
> def1) now triggers this MULTI ERROR (“violates tunnel network/netmask
> constraint”).
> 
> Using redirect-gateway def1 might actually be the better and more
> modern approach, since it adds two more specific routes (0.0.0.0/1 and
> 128.0.0.0/1) instead of replacing the original default route — keeping
> it available as a fallback.
> 
> → Should `redirect-gateway def1` therefore be pushed globally for all
> clients? If not explicitly configured otherwise, it would still apply.
> 
> So far, DCO seems to makes his job.
> 
> Some smaller issues have been noticed, but I think these are the key
> points so far.
> 
> Hope this mail isn’t **too long**, but I thought it might be useful to
> share.
> 
> Best,
> 
> Erik
> 
> Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb 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

[ummeegge]

Hello Adolf,
great so you know about :-) .

Have you recognized the redirect-gateway message too ?
Also, did you check the new script in libexec `dns-updown` ? It seems
that this is a kind of new feature from 2.7.0 (haven´t digged deeper) ?

Best,

Erik

Am Donnerstag, dem 19.02.2026 um 17:04 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> 
> On 19/02/2026 16:03, ummeegge wrote:
> > Hi all,
> > 
> > since OpenVPN 2.7.0 was released last week, I’ve done some more
> > testing
> > with the new DCO flag.
> > 
> > ```
> > @@ -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
> > ```
> > 
> > I’ve found a couple of other issues:
> > 
> > There have been some changes in the management interface, and a
> > protocol prefix is now included (e.g. udp4:).
> > As a result, the old regex patterns for
> > a) OpenVPN Connection Statistics and
> > b) Connection Status
> > no longer update or show data. This shouldn’t be hard to fix.
> 
> I already have patch fixes for this from my testing of the alpha3,
> beta1 and rc1. If you go to my IPFire git repo (link at end of this
> mail) the patch is in that rc1 branch. There is also the removal of
> the deprecated persist-key which is now always enabled by default.
> 
> Regards,
> 
> Adolf.
> 
> > 
> > With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client
> > with
> > “redirect-gateway”. Example message:
> > 
> > ```
> > Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
> > PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual
> > IP
> > for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates
> > tunnel
> > network/netmask constraint (10.73.104.0/255.255.255.0)
> > ```
> > 
> > The connection still works fine, but the log entries don’t look
> > good.
> > This happens because older setups used `redirect-gateway def1` in
> > the
> > advanced options, and remnants of this are still present in
> > server.conf
> > (push "redirect-gateway def1"), even though the checkbox for this
> > option has disappeared.
> > 
> > When creating a new client, enabling redirect-gateway (here without
> > def1) now triggers this MULTI ERROR (“violates tunnel
> > network/netmask
> > constraint”).
> > 
> > Using redirect-gateway def1 might actually be the better and more
> > modern approach, since it adds two more specific routes (0.0.0.0/1
> > and
> > 128.0.0.0/1) instead of replacing the original default route —
> > keeping
> > it available as a fallback.
> > 
> > → Should `redirect-gateway def1` therefore be pushed globally for
> > all
> > clients? If not explicitly configured otherwise, it would still
> > apply.
> > 
> > So far, DCO seems to makes his job.
> > 
> > Some smaller issues have been noticed, but I think these are the
> > key
> > points so far.
> > 
> > Hope this mail isn’t **too long**, but I thought it might be useful
> > to
> > share.
> > 
> > Best,
> > 
> > Erik
> > 
> > Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb 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

[Adolf Belka]

Hi Erik,

On 19/02/2026 18:25, ummeegge wrote:
> Hello Adolf,
> great so you know about :-) .
> 
> Have you recognized the redirect-gateway message too ?

No. I tested the build with my existing client connections by installing 2.7 and restoring my backup and testing out the connections for roadwarrior and n2n. None of my connections had the redirect-gateway option selected.


> Also, did you check the new script in libexec `dns-updown` ? It seems
> that this is a kind of new feature from 2.7.0 (haven´t digged deeper) ?

No. I was just checking that existing connections would still work with 2.7 on my thought that we would first move from 2.6 to 2.7 and then look at additional options like DCO etc as follow-up modifications. Of course we could also jump right in to them but then there would need to be more testing for both the major version change and the additional options, especially if those are globally applied and implemented ones. I am not familiar enough with those options to come to any conclusion on that.

I was just thinking of making any changes in smaller steps that are easier to confirm as working.
I don't fancy another change like we had to do from 2.5 running without negotiation to 2.6 with all its changes.

Regards,

Adolf.


> 
> Best,
> 
> Erik
> 
> Am Donnerstag, dem 19.02.2026 um 17:04 +0100 schrieb Adolf Belka:
>> Hi Erik,
>>
>>
>> On 19/02/2026 16:03, ummeegge wrote:
>>> Hi all,
>>>
>>> since OpenVPN 2.7.0 was released last week, I’ve done some more
>>> testing
>>> with the new DCO flag.
>>>
>>> ```
>>> @@ -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
>>> ```
>>>
>>> I’ve found a couple of other issues:
>>>
>>> There have been some changes in the management interface, and a
>>> protocol prefix is now included (e.g. udp4:).
>>> As a result, the old regex patterns for
>>> a) OpenVPN Connection Statistics and
>>> b) Connection Status
>>> no longer update or show data. This shouldn’t be hard to fix.
>>
>> I already have patch fixes for this from my testing of the alpha3,
>> beta1 and rc1. If you go to my IPFire git repo (link at end of this
>> mail) the patch is in that rc1 branch. There is also the removal of
>> the deprecated persist-key which is now always enabled by default.
>>
>> Regards,
>>
>> Adolf.
>>
>>>
>>> With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client
>>> with
>>> “redirect-gateway”. Example message:
>>>
>>> ```
>>> Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
>>> PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual
>>> IP
>>> for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates
>>> tunnel
>>> network/netmask constraint (10.73.104.0/255.255.255.0)
>>> ```
>>>
>>> The connection still works fine, but the log entries don’t look
>>> good.
>>> This happens because older setups used `redirect-gateway def1` in
>>> the
>>> advanced options, and remnants of this are still present in
>>> server.conf
>>> (push "redirect-gateway def1"), even though the checkbox for this
>>> option has disappeared.
>>>
>>> When creating a new client, enabling redirect-gateway (here without
>>> def1) now triggers this MULTI ERROR (“violates tunnel
>>> network/netmask
>>> constraint”).
>>>
>>> Using redirect-gateway def1 might actually be the better and more
>>> modern approach, since it adds two more specific routes (0.0.0.0/1
>>> and
>>> 128.0.0.0/1) instead of replacing the original default route —
>>> keeping
>>> it available as a fallback.
>>>
>>> → Should `redirect-gateway def1` therefore be pushed globally for
>>> all
>>> clients? If not explicitly configured otherwise, it would still
>>> apply.
>>>
>>> So far, DCO seems to makes his job.
>>>
>>> Some smaller issues have been noticed, but I think these are the
>>> key
>>> points so far.
>>>
>>> Hope this mail isn’t **too long**, but I thought it might be useful
>>> to
>>> share.
>>>
>>> Best,
>>>
>>> Erik
>>>
>>> Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb 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]

Hello everyone,

OpenVPN 2.7 is out! Finally.

However, I am not entirely sure when we should make the switch. We would gain a couple of features like DCO, but so far not many people have actually asked for them. Although it would improve bandwidth, I don’t think many people have a lot of OpenVPN traffic on weak hardware so that this is an issue.

On the other hand, Adolf is right. Every OpenVPN upgrade is a huge job. A lot of things are being changed and we only find out in the middle of the testing phase. So what should we do? I suppose at some point we have to make the switch. But until then I would not mind to have at least a few of the teething issues resolved in a .1, or even .2 release.

Regarding the redirect-gateway problem, I cannot see anything in the change log that touched this. This therefore proves my point from above that there are a lot of hidden “features” to find. Erik, what needs to be changed to make the message go away; what change of behaviour would we see?

-Michael

> On 19 Feb 2026, at 17:38, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Erik,
> 
> On 19/02/2026 18:25, ummeegge wrote:
>> Hello Adolf,
>> great so you know about :-) .
>> Have you recognized the redirect-gateway message too ?
> 
> No. I tested the build with my existing client connections by installing 2.7 and restoring my backup and testing out the connections for roadwarrior and n2n. None of my connections had the redirect-gateway option selected.
> 
> 
>> Also, did you check the new script in libexec `dns-updown` ? It seems
>> that this is a kind of new feature from 2.7.0 (haven´t digged deeper) ?
> 
> No. I was just checking that existing connections would still work with 2.7 on my thought that we would first move from 2.6 to 2.7 and then look at additional options like DCO etc as follow-up modifications. Of course we could also jump right in to them but then there would need to be more testing for both the major version change and the additional options, especially if those are globally applied and implemented ones. I am not familiar enough with those options to come to any conclusion on that.
> 
> I was just thinking of making any changes in smaller steps that are easier to confirm as working.
> I don't fancy another change like we had to do from 2.5 running without negotiation to 2.6 with all its changes.
> 
> Regards,
> 
> Adolf.
> 
> 
>> Best,
>> Erik
>> Am Donnerstag, dem 19.02.2026 um 17:04 +0100 schrieb Adolf Belka:
>>> Hi Erik,
>>> 
>>> 
>>> On 19/02/2026 16:03, ummeegge wrote:
>>>> Hi all,
>>>> 
>>>> since OpenVPN 2.7.0 was released last week, I’ve done some more
>>>> testing
>>>> with the new DCO flag.
>>>> 
>>>> ```
>>>> @@ -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
>>>> ```
>>>> 
>>>> I’ve found a couple of other issues:
>>>> 
>>>> There have been some changes in the management interface, and a
>>>> protocol prefix is now included (e.g. udp4:).
>>>> As a result, the old regex patterns for
>>>> a) OpenVPN Connection Statistics and
>>>> b) Connection Status
>>>> no longer update or show data. This shouldn’t be hard to fix.
>>> 
>>> I already have patch fixes for this from my testing of the alpha3,
>>> beta1 and rc1. If you go to my IPFire git repo (link at end of this
>>> mail) the patch is in that rc1 branch. There is also the removal of
>>> the deprecated persist-key which is now always enabled by default.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>>> 
>>>> With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client
>>>> with
>>>> “redirect-gateway”. Example message:
>>>> 
>>>> ```
>>>> Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
>>>> PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual
>>>> IP
>>>> for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates
>>>> tunnel
>>>> network/netmask constraint (10.73.104.0/255.255.255.0)
>>>> ```
>>>> 
>>>> The connection still works fine, but the log entries don’t look
>>>> good.
>>>> This happens because older setups used `redirect-gateway def1` in
>>>> the
>>>> advanced options, and remnants of this are still present in
>>>> server.conf
>>>> (push "redirect-gateway def1"), even though the checkbox for this
>>>> option has disappeared.
>>>> 
>>>> When creating a new client, enabling redirect-gateway (here without
>>>> def1) now triggers this MULTI ERROR (“violates tunnel
>>>> network/netmask
>>>> constraint”).
>>>> 
>>>> Using redirect-gateway def1 might actually be the better and more
>>>> modern approach, since it adds two more specific routes (0.0.0.0/1
>>>> and
>>>> 128.0.0.0/1) instead of replacing the original default route —
>>>> keeping
>>>> it available as a fallback.
>>>> 
>>>> → Should `redirect-gateway def1` therefore be pushed globally for
>>>> all
>>>> clients? If not explicitly configured otherwise, it would still
>>>> apply.
>>>> 
>>>> So far, DCO seems to makes his job.
>>>> 
>>>> Some smaller issues have been noticed, but I think these are the
>>>> key
>>>> points so far.
>>>> 
>>>> Hope this mail isn’t **too long**, but I thought it might be useful
>>>> to
>>>> share.
>>>> 
>>>> Best,
>>>> 
>>>> Erik
>>>> 
>>>> Am Donnerstag, dem 06.11.2025 um 22:19 +0100 schrieb 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

[ummeegge]

Hi all,

since OpenVPN 2.7.0 was released last week, I’ve done some more testing
with the new DCO flag.

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

I’ve found a couple of other issues:

There have been some changes in the management interface, and a
protocol prefix is now included (e.g. udp4:).
As a result, the old regex patterns for
a) OpenVPN Connection Statistics and
b) Connection Status
no longer update or show data. This shouldn’t be hard to fix.

With OpenVPN 2.7.0, a MULTI ERROR appears when creating a client with
“redirect-gateway”. Example message:

```
Feb 19 13:34:36 ipfire-prime openvpnserver[7329]:
PeterForden/udp4:192.168.110.10:38103 MULTI ERROR: primary virtual IP
for PeterForden/udp4:192.168.110.10:38103 (10.12.52.2) violates tunnel
network/netmask constraint (10.73.104.0/255.255.255.0)
```

The connection still works fine, but the log entries don’t look good.
This happens because older setups used `--redirect-gateway def1` in the
advanced options, and remnants of this are still present in server.conf
(push "redirect-gateway def1"), even though the checkbox for this
option has disappeared.

When creating a new client, you can enable in the specific client
coniguration `--redirect-gateway` (without def1) now triggers this
MULTI ERROR (“violates tunnel network/netmask constraint”) since two
redirect-gateway directives has been set.

Using `--redirect-gateway def1` might actually be the better and more
modern approach, since it adds two more specific routes (0.0.0.0/1 and
128.0.0.0/1) instead of replacing the original default route — keeping
it available as a fallback.

→ Should "redirect-gateway def1" therefore be pushed globally for all
clients? If on client generation not explicitly configured, it would
still apply.

Otherwise, DCO seems to work fine so far.

Some smaller issues have been noticed, but I think these are the key
points.

Hope this mail isn’t **too long**, but I thought it might be useful to
share.

Best,

Erik