Jump to content
Not connected, Your IP: 44.210.149.205
Staff

Road to OpenVPN 2.6 and DCO

Recommended Posts

Hello!

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


Kind regards & datalove
AirVPN Staff
 

Share this post


Link to post

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. 

Share this post


Link to post
@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
 

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

image.png


- Router/Firewall pfSense 23.01 (11th Gen Intel(R) Core(TM) i5-11320H @ 3.20GHz)

- Switch Cisco SG350-10

- AP Netgear RAX200 (Stock FW)

- NAS Synology DS1621+ (5 x 5TB WD Red)

- ISP: Fiber 1000/300 (PPPoE)

 

Share this post


Link to post
@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).
 

Share this post


Link to post
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.  

Share this post


Link to post
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"

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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 

Share this post


Link to post
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.

- Router/Firewall pfSense 23.01 (11th Gen Intel(R) Core(TM) i5-11320H @ 3.20GHz)

- Switch Cisco SG350-10

- AP Netgear RAX200 (Stock FW)

- NAS Synology DS1621+ (5 x 5TB WD Red)

- ISP: Fiber 1000/300 (PPPoE)

 

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...