Re: openvpn-2.7_rc1

[ummeegge <ummeegge@ipfire.org>]

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