Road to OpenVPN 2.6 and DCO

[Staff 9971]

Hello!

We're glad to inform you that we have just released:

• "Road To OpenVPN 2.6" migration plan - https://airvpn.org/road_to_openvpn26/
• A new version of Config Generator with options related to OpenVPN 2.6
• A new Eddie Desktop beta release (2.23.0) related to the road above, feature-locked to reach stable release https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/
• A new server (Marsic), the first running OpenVPN 2.6 powered by DCO (server-side) and ready for client-side DCO.

Kind regards & datalove
AirVPN Staff
 

[go558a83nk 362]

Did some testing from my pfsense+ box.  So far it works very well.  It's lovely to see all the openvpn work being done in kernel here and 600mbit/s from this great distance seems very respectable. 

[bnrrteterstnjrsj45 0]

". 2023.06.27 18:11:07 - OpenVPN > --windows-driver is set to 'wintun'. Disabling Data Channel Offload" - on Marsic server.

Works is underway?

[Staff 9971]

@bnrrteterstnjrsj45

Hello!
                    
The wintun driver is not for DCO. Are you running Eddie 2.23? If so, please check the caveats in the "Road to OpenVPN 2.6" page, specifically:
 

Quote

Eddie will use wintun as driver by default, and will not currently install ovpn-dco driver or create adapter.
During the Beta Testing Phase, run the official OpenVPN Installer (which installs the driver and create the adapter) and in Eddie specify in Preferences  Advanced  Driver the value ovpn-dco
Future releases in the beta phase will install and manage automatically ovpn-dco driver and network adapter (WIP).

Kind regards
 

[bnrrteterstnjrsj45 0]

Oh, thanks a lot, mate!

[bnrrteterstnjrsj45 0]

Done.

https://prnt.sc/0vleGtymRKn4

[bnrrteterstnjrsj45 0]

Twitch now blocks even openvpn while dco (was wg). Or, maybe, it's Kazakhstan's network itself, like chinese wall or kgb's control.

[bnrrteterstnjrsj45 0]

Bro, twitch starts working after reported problem by user in another thread. Meaning, while on dco. 

Perhaps, wg start too? Didn't tested myself.

[Air4141841 24]

I wish I had seen this earlier... really hoping some in the USA soon 
 

	library versions: OpenSSL 1.1.1u 30 May 2023, LZO 2.10
	Notice		OpenVPN 2.6.4 amd64-portbld-freebsd13.1 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]

well see how it goes, staying connected and speed wise

[Air4141841 24]

Post deleted 

opnsense doesn’t utilize dco
apologies 

[bnrrteterstnjrsj45 0]

I'm confirm, now twitch opens while on wg. But tested only once, I mean not several times checked.

And thanks for "post-quantum resistence" on new dco server Marsic, but it is wg, not about dco.

[Wolf666 17]

Excellent job!
Testing OpenVPN + DCO with pfSense 23.05 with IPsec-MB Crypto: Yes (active), on fiber 1000/300. 
 

[Flx 76]

@StaffCan you deploy a server in Canada or US for this test-phase?(if possible) 
Reason: Max speed qbit(~60-80MB/s) to Marsic(Mars I see). Need another server to compare speed-wise(etc).
 

[oassQ9w4cbl4AySZhhth%p36x 3]

On 6/30/2023 at 2:41 PM, airvpnforumuser said:

I am honestly still confused by this whole ovpn-dco thing and maybe @staff can answer a few questions?

Although they don't mention Wireguard in their blog post it seems to me after years of stagnation they've finally figured that in-kernel is the _only_ way to get the performance needed with higher bandwidth use-cases - Wireguard offers the best speeds in the business so it's nice to see them catching up.

However, there are a few caveats

1: It does not appear they are planning to submit a patch to DavidM to include this into Linux natively? They mention they build against net-next but the github page has been very sparse for a few months, It surely is a waste of time to make an out-of-tree kernel module? If their code is so good either submit the patch to net-next or it's a joke, surely? Won't this mean constantly having to test/rebase as the kernel updates every few months? When it's part of the tree you get 'free' support as the code is effectively maintained forever (hence the appeal of Wireguard, it's part of Linux forever now).

2: It seems the restrictions are quite strict: each server needs dco, and that breaks compatibility. I implore staff to keep old servers around without dco, many, many people will not upgrade to latest eddie (on any platform) for various reasons. It would be massive mistake to force dco in next few years. Add it to servers, sure, but keep servers that work on older clients. You should support as many older eddies (within reason with regards to security) as possible. Breaking users is a huge no-go.

It seems there is limited support for Linux (ironically, you need to build a module yourself and not many are going to do that, or know how!) and Android, which makes this effort feel...less impactful. I don't understand the benefits of dco directly - will this match wireguard in terms of performance? I am interested in AirVPN's tests as to how good dco is in their experience on multiple platforms (windows, routers, raspberry pi etc etc). I have yet to see the justification for dco that would make users update to latest eddie and be a breaking change.

 It's probably a worthwhile effort in the long run but absolutely not worthwhile breaking the user. It remains sad that AirVPN needs to maintain its own fork of OpenVPN as they were too arrogant to accept legitimate patches sent to them by ProMind. I wonder if their code would even be accepted by David M anyhow
 

1. I don't personally see this as much of an issue but I agree with you that it would benefit from being in the kernel. Just being in the Linux tree doesn't provide near as universal benefits as are made out, because whilst true you might get some bug fixes that come down the line through testing - and the testing that goes on is largely automated tested testing, it doesn't ensure that anybody is really going to actively maintain it in relation to feature sets or utilities or any meaningful development. I can point to a variety of in-kernel stuff which is just like that, hasn't received any meaningful updates in years and likely won't receive any (because the dev has long abandoned it)

2. I was under the impression that the two could co-exist, we've had reports of others in various threads connecting to OVPN servers whilst having DCO supported clients but not supported servers and everything working fine. 

RE: performance - from benchmarks others have done, it appears that OVPN will be significantly faster than wireguard. I don't know how they are accomplishing this but I think it will likely be due to the ciphers that are being used. Making use of the AES-NI ciphers, AES-256-GCM, AES-128-GCM are likely how they are reaching those performance values. 

Finally on your last point, cant you fork their fork and merge it back? or whoever else who wants to? It sounds to me like you want people to actively maintain something in a manner that you see fit, which just seems silly. AirVPN have made various posts on various changes they made and the performance gains they had as a result or use case scenarios that benefitted them.  

[Flx 76]

32 minutes ago, oassQ9w4cbl4AySZhhth%p36x said:

AES-128-GCM are likely how they are reaching those performance values. 

Bingo ....don't forget to change the buffer-size.

[go558a83nk 362]

26 minutes ago, Flx said:

Bingo ....don't forget to change the buffer-size.

are you sure buffer does anything with DCO?  The pfsense+ folks say it and some other things are not compatible with DCO but maybe that's just their implementation at this time?

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/dco.html#limitations

[go558a83nk 362]

BTW, I think the really speedy stuff with DCO is coming from machines that have QAT available not from AES-NI. 

[Flx 76]

15 minutes ago, go558a83nk said:

implementation at this time?

From the article/link Yes I read that BTW:
"Some features are not compatible with DCO or are not relevant with DCO."
Now which one is it "compatible or relevant"?
And this is the part that confused the most:
"Per-peer data usage is not tracked properly"
 

[go558a83nk 362]

1 hour ago, Flx said:

From the article/link Yes I read that BTW:
"Some features are not compatible with DCO or are not relevant with DCO."
Now which one is it "compatible or relevant"?
And this is the part that confused the most:
"Per-peer data usage is not tracked properly"
 

yeah so usually your openvpn peers will show a total upload/download when looking at openvpn status.  but DCO clients currently do not.

[Flx 76]

5 minutes ago, go558a83nk said:

yeah so usually your openvpn peers will show a total upload/download when looking at openvpn status.

Yup.

6 minutes ago, go558a83nk said:

DCO clients currently do not.

Nope.

[Air4141841 24]

1 hour ago, Flx said:

Yup. Nope.

146.70.111.21:443

36 KiB

37 KiB

that's for sure.  I boot up my backup router.  SG3100.    and couldn't figure out why the numbers were not increasing.. 

its just doesn't change on the status page 

[Wolf666 17]

21 hours ago, go558a83nk said:

BTW, I think the really speedy stuff with DCO is coming from machines that have QAT available not from AES-NI. 

pfSense Plus software supports ChaCha20-Poly1305 with OpenVPN DCO, but currently only IPsec-MB can accelerate that algorithm. At this time, neither AES-NI nor QAT can accelerate ChaCha20-Poly1305. Some newer QAT hardware may be capable of accelerating ChaCha20-Poly1305, but the current QAT drivers do not yet include support for that encryption algorithm.

In pfSense+ I found using ChaCha20-Poly1305 and enabling IPsec-MB be faster than wireguard.

[go558a83nk 362]

1 hour ago, Wolf666 said:

pfSense Plus software supports ChaCha20-Poly1305 with OpenVPN DCO, but currently only IPsec-MB can accelerate that algorithm. At this time, neither AES-NI nor QAT can accelerate ChaCha20-Poly1305. Some newer QAT hardware may be capable of accelerating ChaCha20-Poly1305, but the current QAT drivers do not yet include support for that encryption algorithm.

In pfSense+ I found using ChaCha20-Poly1305 and enabling IPsec-MB be faster than wireguard.

it wasn't clear but my comment was in reference to AES-128-GCM being fast with DCO.  and even faster if you have a QAT machine.

[Flx 76]

On 7/3/2023 at 1:29 PM, go558a83nk said:

it wasn't clear but my comment was in reference to AES-128-GCM being fast with DCO

No matter what cipher you pick the CPU load stays the same?

[go558a83nk 362]

On 7/4/2023 at 1:59 PM, Flx said:

On 7/3/2023 at 12:29 PM, go558a83nk said:

it wasn't clear but my comment was in reference to AES-128-GCM being fast with DCO

No matter what cipher you pick the CPU load stays the same?

difficult to say but it seemed like CPU load is less with AES than with chacha yet chacha was a little faster.  pfsense and using IPsec-MB