Road to OpenVPN 2.6 and DCO

[Flx 77]

@StaffAny update(s) on this Road to 2.6?

 

[bnrrteterstnjrsj45 0]

This strange stalled. Why only one serbian server?

[Staff 10283]

On 7/7/2023 at 4:18 AM, Flx said:

@StaffAny update(s) on this Road to 2.6?

Hello!
If you read https://airvpn.org/road_to_openvpn26/ you will notice that the beta testing phase will end when DCO is stable. Current reported status is:

** NOTE **
ovpn-dco is currently under heavy development, therefore neither its userspace API
nor the code itself is considered stable and may change radically over time.

Under the condition of code 1) not stable and 2) subjected to radical changes it is not possible to consider the beta testing phase over.

Kind regards
 

[Oblivion 2013 8]

In the config generator I didn't know the OpenVPN2.6 with DCO, so i chose OpenVPN2.6 instead and it works. At this moment i don't configure anything yet with DCO.

This reminds me about Linus Torvalds and Andrew Tanenbaum having their first discussion about a Message Passing Kernel like Minux from Andrew vs the Monolytic Kernel that Linux wanted.

It is about performance. Hence why e.g. when Data Structures from Kernel Space do not have to be copied to User Space or back like in a Message Passing based kernel performance has it limits very fast, even with powerful CPU's, it is the Memory Latency that is a lightspeed bound limit in e.g. 15 inch a signal can reach at 3 GigaHerz.

Apple did something clever with the M1 SOC System On Chip, everything as close as possible near eachother.

Although I find Linux Kernel more having an option like Hybrid Kernel like Windows is.

NTFS-3G Fuse is another example of data stucture passing, it is very slow, but it works under Linux to read and write to NTFS.

[bnrrteterstnjrsj45 0]

Only one server. Still. 

[Staff 10283]

29 minutes ago, bnrrteterstnjrsj45 said:

Only one server. Still. 

Hello!

DCO code is in highly experimental phase and subject to radical changes. Still.

** NOTE **
ovpn-dco is currently under heavy development, therefore neither its userspace API
nor the code itself is considered stable and may change radically over time.

Kind regards
 

[oassQ9w4cbl4AySZhhth%p36x 4]

On 9/30/2023 at 2:59 PM, bnrrteterstnjrsj45 said:

Only one server. Still. 

if your having issues with reaching the limits of regular openvpn or just having issues with openvpn in general then i'd suggest setting up wireguard. 

I myself, probably like you thought that openvpn-DCO was just something that would be just around the corner but it isn't. It could be 1-2 years before we see anything or more. Don't hold out in the hopes of it just timely landing on your lap. 

I'm using wireguard now and the speeds are great, would suggest you try it too

[go558a83nk 380]

Hello, is Marsic the only server that supports DCO or have more been added to this test?  Thanks.

[Air4141841 30]

On 4/6/2024 at 5:37 AM, go558a83nk said:

Hello, is Marsic the only server that supports DCO or have more been added to this test?  Thanks.

looks like it from the configuration generator.
I am actually surprised to see almost 50 users connected.    previously it was only maybe 7.  

   I went the opnsense route so I doubt I will be able to test this anytime soon again.  my sg3100 is end of life and not getting updates anymore 

from what I recall reading you are a heavy Pfsense user. ccorrect? 

[go558a83nk 380]

1 hour ago, Air4141841 said:

looks like it from the configuration generator.
I am actually surprised to see almost 50 users connected. previously it was only maybe 7.

I went the opnsense route so I doubt I will be able to test this anytime soon again. my sg3100 is end of life and not getting updates anymore

from what I recall reading you are a heavy Pfsense user. ccorrect? 

LOL thanks. I forgot I could use the config generator to narrow down the list. 😳

[oassQ9w4cbl4AySZhhth%p36x 4]

hi @Staff how close / far are we towards a release of this? https://airvpn.org/road_to_openvpn26/ looking at this link, it started in June 2023 we entered the beta testing phase and a year and a half later, we still seem to be testing? 

do we have any results from such enormous testing? Eddie 2.23 stable version has already been released hasn't it? 

I've kept an eye on the github page https://github.com/OpenVPN/ovpn-dco/commits/master/ and there doesn't seem to be any momentum in terms of any changes that you'd like to see or issues raised towards sharing your testing data and any required bug fixes. 

Could this be looked at some more? with the view towards more of a phased rollout? the one server that was provisioned for this seems to have stayed functional https://airvpn.org/servers/Marsic/ idk with the lack of updates here, it feels like a lot of it has been left on the backburner. 

[Staff 10283]

4 hours ago, oassQ9w4cbl4AySZhhth%p36x said:

hi @Staff how close / far are we towards a release of this? https://airvpn.org/road_to_openvpn26/ looking at this link, it started in June 2023 we entered the beta testing phase and a year and a half later, we still seem to be testing? 

Hi!

Please see here:
https://airvpn.org/forums/topic/56430-road-to-openvpn-26-and-dco/?do=findComment&comment=226017

On https://github.com/OpenVPN/ovpn-dco:

Quote

** NOTE ** ovpn-dco is currently under heavy development, therefore neither its userspace API nor the code itself is considered stable and may change radically over time.

As we wrote, we are not inclined to deploy something under heavy development that can change radically. Furthermore DCO development has been very slow in the last three years and the interest around OpenVPN DCO is fading away with at least one major VPN provider dropping OpenVPN completely in 2026 (not DCO, OpenVPN in its entirety).

We'll see whether the DCO can reach a stable release and if/when the developers release something stable we will re-evaluate the matter for sure. Please check before writing the "road to OpenVPN 2.6" here: https://airvpn.org/road_to_openvpn26/ where you can read that the beta testing phase will be ongoing "Until openvpn-dco stable version is released". After a stable version is released we would start the migration phase.

Kind regards
 

[go558a83nk 380]

I noticed recently that there are 8 servers that now appear to support DCO.  That is, in the config generator they appear when openvpn 2.6 is selected.

However, when I tried connecting to one in the same way I connect successfully to Marsic no traffic flowed through the tunnel.

Are those servers appearing in the DCO list in error or is DCO intended to work for those servers? 

Thanks.

edit: looked again and now there are 12 servers that appear with openvpn 2.6 selected

[Tech Jedi Alex 1489]

22 hours ago, go558a83nk said:

However, when I tried connecting to one in the same way I connect successfully to Marsic no traffic flowed through the tunnel.

That's exactly the issue I'm having, and I don't know why that happens (or rather, why nothing is happening). If OpenVPN is to be believed, tun on server and dco on client is possible (and vice versa).

In any case, ovpn-dco is apparently mature enough to be included in net-next, so it's queued for kernel 6.16.

[go558a83nk 380]

58 minutes ago, OpenSourcerer said:

That's exactly the issue I'm having, and I don't know why that happens (or rather, why nothing is happening). If OpenVPN is to be believed, tun on server and dco on client is possible (and vice versa).

In any case, ovpn-dco is apparently mature enough to be included in net-next, so it's queued for kernel 6.16.

I know for a fact it's possible because I use DCO clients for other servers (not AirVPN) that are not running DCO. 

[Flx 77]

1 hour ago, OpenSourcerer said:

That's exactly the issue I'm having, and I don't know why that happens

Out of the 12 servers only Marsic and Telescopium servers are working.

[subni 0]

Hi! I noticed that only TELESCOPIUM and MARSIC are working with OpenVPN 2.6 and DCO, as Flx said. The rest seem to push comp-lzo no, and I’m wondering if that might be causing issues—since DCO complains about compression being enabled. I can see the following on logs when I try to connect to other servers with DCO active:
 

Quote

Compression or compression stub framing is not allowed since data-channel offloading is enabled.

 

Could that be part of the problem?

Thanks!

Edited ... by subni

[Staff 10283]

On 4/28/2025 at 11:36 PM, go558a83nk said:

Are those servers appearing in the DCO list in error or is DCO intended to work for those servers? 

Hello!

It must be a bug in the Configuration Generator: only Marsic and Telescopium should be shown when "2.6 DCO" is selected. We are going to investigate. Thank you for the head up.

Kind regards
 

[Tech Jedi Alex 1489]

13 hours ago, subni said:

The rest seem to push comp-lzo no, and I’m wondering if that might be causing issues—since DCO complains about compression being enabled. I can see the following on logs when I try to connect to other servers with DCO active:

You fix that via --pull-filter ignore comp-lzo (while not specifying it in your config and even adding --allow-compression no), then theoretically every server should work. Well, theoretically…

[subni 0]

10 hours ago, OpenSourcerer said:

You fix that via --pull-filter ignore comp-lzo (while not specifying it in your config and even adding --allow-compression no), then theoretically every server should work. Well, theoretically…

Thanks! I actually tried something along those lines, but I wasn’t able to get the options properly set in OPNsense. I’ll give it another shot, really appreciate the tip!

[Tech Jedi Alex 1489]

Now that 6.16 is out and Arch Linux updated the kernel, too, I was eager to put DCO to the test again. This is a small diary of an hour or two of testing.

First thing I did, of course, was to simply connect, as OpenVPN is supposed to dynamically enable DCO if the kernel module is there and a proper config is used (eliminate --comp-lzo, use --allow-compression no, eliminate --compat-mode, use --pull-filter ignore comp-lzo, and of course eliminate --disable-dco). But interestingly, OpenVPN didn't detect DCO. I was ready to scour the OpenVPN git repo for possible code indicating what the module is called when git grep found references in the DCO readme. Answered the question immediately.
 

Quote

NOTE: the new ovpn Linux kernel module is compatible only with OpenVPN 2.7 and greater.

So the module's name is now ovpn, not ovpn-dco, since apparently the API changed when the module was upstreamed and 2.6 only checks for ovpn-dco.
There is no testing package for openvpn in Arch, but there is an openvpn-git package in AUR. Double-checking it's not some rogue openvpn-patch-git sort of incident again I went ahead and makepkg'd that which, aside from two errors in prepare() where some Systemd service files could not be patched, compiled without further errors. Went ahead and installed that and:

$ openvpn --version
OpenVPN 2.7_alpha3 [git:master/c4f4f26d48babdf4+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Aug 14 2025
library versions: OpenSSL 3.5.2 5 Aug 2025, LZO 2.10
DCO version: 6.16.0-arch2-1 #1 SMP PREEMPT_DYNAMIC Wed, 13 Aug 2025 23:38:48 +0000
Originally developed by James Yonan
Copyright (C) 2002-2025 OpenVPN Inc <sales@openvpn.net>
Compile time defines:

Now it detected the ovpn module in the kernel! Splendid. So I connected.
The first try was actually not really that: I connected ok and traffic flowed. Euphoria, it finally works for me! So it was something with the ovpn-dco DKMS module. Phew. Did a speedtest and came up with:

$ speedtest-cli  
Retrieving speedtest.net configuration...
Testing from Netrouting (37.46.199.86)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Net-D-Sign GmbH (Munich) [302.28 km]: 18.267 ms
Testing download speed................................................................................
Download: 307.46 Mbit/s
Testing upload speed......................................................................................................
Upload: 176.27 Mbit/s

Looks ok, right? Yeah, you'd think that. But I didn't notice that DCO was actually disabled because I forgot to eliminate --comp-lzo from the config. It was hidden in the middle of the file. Uuugh. So this test is actually a no-dco test and therefore irrelevant. But this is a "diary", so you ought to write the irrelevant. That's how diaries work, right?

Anyway, I fixed that, verified DCO was used and it connected..
.. and ..
.. no traffic. Complete standstill in connectivity. Same problem as with ovpn-dco! My disappointment is immeasurable, and my day is ruined.

But there is some kernel output which doesn't make sense to me now.

Aug 14 18:29:37 pad kernel: tun0: unsupported protocol received from peer 10
Aug 14 18:29:47 pad kernel: tun0: unsupported protocol received from peer 10
Aug 14 18:29:57 pad kernel: tun0: unsupported protocol received from peer 10

Peer should be the server. But what protocol does it not like? So I kicked up --verb 10 in the hopes of seeing something, but the times don't add up at all: The kernel message is posted every 10 seconds, and OpenVPN prints some packet info every 15 seconds, kinda indicating that practically no traffic is flowing. Two packets roughly corresponding with the times above:

2025-08-14 18:29:42 us=559631  event_wait returned 0
2025-08-14 18:29:42 us=559665 I/O WAIT status=0x0020
2025-08-14 18:29:42 us=559682 TLS: tls_multi_process: i=0 state=S_GENERATED_KEYS, mysid=20276f9c 54ccbc3e, stored-sid=246c6960 b812fbc2, stored-ip=[AF_INET6]2a00:dd0:aaaa:9:2a94:d040:418f:de4a:443
2025-08-14 18:29:42 us=559691 TLS: tls_process: chg=1 ks=S_GENERATED_KEYS lame=S_UNDEF to_link->len=0 wakeup=604800
2025-08-14 18:29:42 us=559697 ACK reliable_can_send active=0 current=0 : [6]
2025-08-14 18:29:42 us=559713 ACK reliable_send_timeout 604800 [6]
2025-08-14 18:29:42 us=559717 TLS: tls_process: timeout set to 3585
2025-08-14 18:29:42 us=559726 TLS: tls_multi_process: i=1 state=S_INITIAL, mysid=e9a90a5c 3c1bc48e, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC]
2025-08-14 18:29:42 us=559735 TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC]
2025-08-14 18:29:42 us=559754 RANDOM USEC=158857
2025-08-14 18:29:42 us=559762 PO_CTL rwflags=0x0001 ev=3 arg=0x55b3382ff9d0
2025-08-14 18:29:42 us=559768 PO_CTL rwflags=0x0001 ev=4 arg=0x0000000a
2025-08-14 18:29:42 us=559775 I/O WAIT Tr|Tw| [15/158857]
SR|Sw
2025-08-14 18:29:57 us=732363  event_wait returned 0
2025-08-14 18:29:57 us=732405 I/O WAIT status=0x0020
2025-08-14 18:29:57 us=732419 TLS: tls_multi_process: i=0 state=S_GENERATED_KEYS, mysid=20276f9c 54ccbc3e, stored-sid=246c6960 b812fbc2, stored-ip=[AF_INET6]2a00:dd0:aaaa:9:2a94:d040:418f:de4a:443
2025-08-14 18:29:57 us=732424 TLS: tls_process: chg=1 ks=S_GENERATED_KEYS lame=S_UNDEF to_link->len=0 wakeup=604800
2025-08-14 18:29:57 us=732428 ACK reliable_can_send active=0 current=0 : [6]
2025-08-14 18:29:57 us=732441 ACK reliable_send_timeout 604800 [6]
2025-08-14 18:29:57 us=732444 TLS: tls_process: timeout set to 3570
2025-08-14 18:29:57 us=732449 TLS: tls_multi_process: i=1 state=S_INITIAL, mysid=e9a90a5c 3c1bc48e, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC]
2025-08-14 18:29:57 us=732457 TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC]
2025-08-14 18:29:57 us=732478 RANDOM USEC=3155
2025-08-14 18:29:57 us=732485 PO_CTL rwflags=0x0001 ev=3 arg=0x55b3382ff9d0
2025-08-14 18:29:57 us=732490 PO_CTL rwflags=0x0001 ev=4 arg=0x0000000a
2025-08-14 18:29:57 us=732497 I/O WAIT Tr|Tw| [15/3155]
SR|Sw

The verdict: I cannot use DCO, so I cannot test it.
My next idea would be to scour the kernel source and probably find out when exactly this unsupported protocol message is emitted. Anyone with less time-consuming ideas, step forward, please.