public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: openvpn-2.7_rc1
Date: Tue, 23 Dec 2025 17:13:52 +0100	[thread overview]
Message-ID: <bf7bd77238fd8735edb3fc0c374a035a6079fc33.camel@ipfire.org> (raw)
In-Reply-To: <E2140DA7-66E7-416B-9F57-0758FB4560C5@ipfire.org>

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


  reply	other threads:[~2025-12-23 16:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06 21:19 openvpn-2.7_rc1 Adolf Belka
2025-11-07 14:18 ` openvpn-2.7_rc1 Michael Tremer
2025-12-20 18:05 ` openvpn-2.7_rc1 ummeegge
2025-12-23 11:27   ` openvpn-2.7_rc1 Michael Tremer
2025-12-23 16:13     ` ummeegge [this message]
2025-12-28 12:18       ` openvpn-2.7_rc1 Michael Tremer
2025-12-30 11:17         ` openvpn-2.7_rc1 ummeegge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf7bd77238fd8735edb3fc0c374a035a6079fc33.camel@ipfire.org \
    --to=ummeegge@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox