Staff 9901 Posted ... 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 4 1 go558a83nk, Air4141841, nexsteppe and 2 others reacted to this Quote Share this post Link to post
go558a83nk 360 Posted ... 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. 1 Air4141841 reacted to this Quote Share this post Link to post
bnrrteterstnjrsj45 0 Posted ... ". 2023.06.27 18:11:07 - OpenVPN > --windows-driver is set to 'wintun'. Disabling Data Channel Offload" - on Marsic server. Works is underway? Quote Share this post Link to post
Staff 9901 Posted ... @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 Quote Share this post Link to post
bnrrteterstnjrsj45 0 Posted ... Twitch now blocks even openvpn while dco (was wg). Or, maybe, it's Kazakhstan's network itself, like chinese wall or kgb's control. Quote Share this post Link to post
bnrrteterstnjrsj45 0 Posted ... Bro, twitch starts working after reported problem by user in another thread. Meaning, while on dco. Perhaps, wg start too? Didn't tested myself. Quote Share this post Link to post
Air4141841 24 Posted ... 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 Quote Share this post Link to post
Air4141841 24 Posted ... Post deleted opnsense doesn’t utilize dco apologies Quote Share this post Link to post
bnrrteterstnjrsj45 0 Posted ... 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. Quote Share this post Link to post
Wolf666 17 Posted ... Excellent job! Testing OpenVPN + DCO with pfSense 23.05 with IPsec-MB Crypto: Yes (active), on fiber 1000/300. 1 go558a83nk reacted to this Quote Hide Wolf666's signature Hide all signatures - 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
Flx 76 Posted ... @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). 3 Air4141841, dIecbasC and go558a83nk reacted to this Quote Hide Flx's signature Hide all signatures Guide - EMBY Block ALL interfaces except tap/vpn Windows OS - Configuring your operating system Windows OS - Multi Session/Tunnel Share this post Link to post
oassQ9w4cbl4AySZhhth%p36x 3 Posted ... 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. 1 Flx reacted to this Quote Share this post Link to post
Flx 76 Posted ... 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. Quote Hide Flx's signature Hide all signatures Guide - EMBY Block ALL interfaces except tap/vpn Windows OS - Configuring your operating system Windows OS - Multi Session/Tunnel Share this post Link to post
go558a83nk 360 Posted ... 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 Quote Share this post Link to post
go558a83nk 360 Posted ... BTW, I think the really speedy stuff with DCO is coming from machines that have QAT available not from AES-NI. Quote Share this post Link to post
Flx 76 Posted ... 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" Quote Hide Flx's signature Hide all signatures Guide - EMBY Block ALL interfaces except tap/vpn Windows OS - Configuring your operating system Windows OS - Multi Session/Tunnel Share this post Link to post
go558a83nk 360 Posted ... 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. Quote Share this post Link to post
Flx 76 Posted ... 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. Quote Hide Flx's signature Hide all signatures Guide - EMBY Block ALL interfaces except tap/vpn Windows OS - Configuring your operating system Windows OS - Multi Session/Tunnel Share this post Link to post
Air4141841 24 Posted ... 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 Quote Share this post Link to post
Wolf666 17 Posted ... 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. Quote Hide Wolf666's signature Hide all signatures - 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
go558a83nk 360 Posted ... 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. 1 Wolf666 reacted to this Quote Share this post Link to post
Flx 76 Posted ... 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? Quote Hide Flx's signature Hide all signatures Guide - EMBY Block ALL interfaces except tap/vpn Windows OS - Configuring your operating system Windows OS - Multi Session/Tunnel Share this post Link to post
go558a83nk 360 Posted ... 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 1 Flx reacted to this Quote Share this post Link to post