> Based on OpenVPN 3 library fork by AirVPN with tons of critical bug fixes from the main branch, new ciphers support and never seen before features
Why are these changes not being contributed upstream? It does not inspire my trust to hear these people are making "critical bug fixes" and then hoarding them without explanation. Did OpenVPN3 refuse the updates, or are otherwise dragging their feet? Or, more likely, did AirVPN decide it was more interesting/important to use these fixes as a competitive advantage / differentiator for their fork, to get people to use their client or even leave upstream?
> Why are these changes not being contributed upstream?
Perhaps more importantly, what are these supposedly "critical bug fixes"? How do you make a claim like that without clearly documenting it? Are there security impacts? CVEs?
Edit: if you click through to the actual library page[1], it makes no claims that I can find about "tons of critical bug fixes". I'm beginning to suspect that may be some extremely misleading marketing speak that made it into the README.
Edit: looking through the list of changes[2] does not inspire a lot of confidence in their fork.
> does not inspire a lot of confidence in their fork
Just out of interest, what reasons do you have for this?
Much of the code seems... incomplete? I don't want to sound too harsh, but what scares me looking glancing at the changes, are the functions `set_ncp_disable` and `set_ncp_enabled`.
Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
Pretty much this exactly. There's not a lot here, but what is there leaves you kind of confused about what the point is.
I'm not a cryptographer and can't vouch one way or another for the safety of their fork, but a lot of the changes are just stuff like moving whitespace around, and the stuff that isn't pointless sometimes involves changes to important cryptography functions without clear explanations or justifications given in the commit messages. All of the changes are by a single user without any clear indication that they've been reviewed by someone qualified to do cryptography.
And above all there's no obvious reason this fork needs to exist. There's no evidence that it's fixing any "critical bugs" that the OpenVPN project is ignoring, and if the changes are worthwhile they should just be upstreamed. If you're going to pursue something as major as forking OpenVPN, it's really on you to provide some evidence that people should trust your work.
> Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
For sure, but maybe they should put more effort into getting Wireguard support for their servers instead?
>Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
What's the advantage of those new ciphers? AFAIK they have better performance than AES on hardware without AES acceleration, but most consumer devices already have it.
Most (all nowadays?) Android tablets and smart phones are based on ARM processors that do not support AES-NI. Even a lot of consumers' routers, which can run OpenVPN, do not support AES-NI.
Raspberry Pi, nVidia Shield, Amazon FireStick are additional examples that come to mind, not to mention many other embedded devices, mediaplayers, Android based TVs...
I have verified impressive improvement (up to 45%) in throughput with CHACHA20 vs. AES-256 in several ARM based devices running either Android or Linux ARM (connecting to the same AirVPN server with same router, same ISP and same application based for Android or Linux ARM on their forked library).
About desktop computers, things might change with AVX-512 wider adoption: it remains to be seen whether AES-NI can perform better with AES-256-GCM than AVX-512 supporting processors can do with CHACHA20. I don't have the option to test that, anybody did?
Upstream isn't responsive. I have had a bug open with them about broken TAP mode routing for years, with patch, and they've ignored it.
After seeing the codebase, I'm a lot warier of using OpenVPN. It's quite a mess. I'm personally looking forward to WireGuard becoming the standard, but I'm glad to see an OpenVPN fork. These things, even if they don't replace upstream, tend to motivate them to stop dragging their feet.
As a paid customer of OpenVPN I have to admit I find their attitude over certain matters incredibly frustrating.
Their continued lack of interest in IPv6 is a prime specimen. We're now in 2020, IPv4 depletion is no longer a distant thought, and yet OpenVPN still don't have full support for IPv6.
The lack of support for modern algos is also frustrating, although not exactly a deal breaker.
That said, to give them their due, when a CVE worthy issue arises, they are quick to react and issue a patch (or at least no slower than your average).
As for WireGuard, yes, I'm looking forward to it. But let's face the truth. The WireGuard homepage makes it quite clear in no uncertain terms that WireGuard is still a work in progress. Until such time as its had a full suite of codebase reviews, including multiple independent security audits, I refuse to touch it for production. Maybe in 12–24 months things might have changed at WireGuard to an extend that makes it more worthy for consideration.
So at the moment OpenVPN is the best we've got as an alternative to IPSec (which is quite frankly a pain to deal with, especially in NAT environments and so unsuitable for road warriors).
Like IPv6 specified in the early 90s fully replaces Ipv4 with time.
Like reiserfs has become the standard Linux file system. Like btrfs is becoming the standard Linux file system (Redhat has announce to discontinue support)
Predictions are difficult, especially when they cover future developments...
Wireguard is not designed to provide any obfuscation. It has very clear fingerprints. This is by design. Jason is very clear that Wireguard does not consider obfuscating its packets to be in scope for the project.
AirVPN (I believe) attempts to provide a service that also features an obfuscated / hidden VPN.
This does not mean that Wireguard cannot become the underlay used by VPN providers like AirVPN. Just that they'll need an obfuscation overlay as well.
I use wireguard with Mullvad since it launched without issues. They even have it in the official client. I talked to them about the article that one VPN provider wrote about it not being scalable and not privacy preserving and their response was that it was mostly FUD. I believe one of their technicians wrote a blog about it, but now I can't find it.
> Or, more likely, did AirVPN decide it was more interesting/important to use these fixes as a competitive advantage / differentiator for their fork ... ?
You mean these fixes that are available in this repo that are available to absolutely anyone?
The changes have been committed as far as I can see and refused with absurd explanation IMHO, but check yourself, it's only my opinion.
What I know for sure, because it's public, is that AirVPN forked only after a long (harsh?) public debate on the commits with the main branch maintainer.
I can see bug fixes summarized in the changelog, look at "Changelog 3.3.2 AirVPN - Release date: 10 October 2019". Then look at the fixes in the code: the AirVPN developers are indeed right as far as I can see, without those fixes the library could have never worked (and the main branch still does not work!) in Linux.
I wonder whether AirVPN would have forked were those commits accepted. Surely they forked only after some time the commits were there, available, as a precious gift IMHO, but still refused without any serious analysis.
Look: I work on a lot of open source projects; I assert a bunch of undocumented changes without any attempt at organizing them, pushed to a fork on GitHub is still close enough to "hoarding".
I don't agree, but I don't want to act as an outstanding coder. I don't even want to defend AirVPN developers because their software "Eddie" for Linux is ugly, IMHO, and I say it as an AirVPN customer too. But hey I hate Mono. :)
But the OpenVPN 3 fork and Hummingbird too appear to me as good, very good. The fork is well organized, the new parts are quite elegantly coded at least to me, very readable and well commented, and it's kept ahead in alignment with the main branch. Some time ago I also followed AirVPN commits to the main branch and after I took my time to watch the code I was astonished that they were rejected with some arguments that, I think, are either pretentious or wrong, but that's an opinion of mine, the facts can be seen by anyone looking at the code and some smart solutions/implementations I find delicious such as pointers to methods to optimize and save time in packets cipher dependent decisions. I wonder... if the initial commits to the main branch were not rejected, would AirVPN have forked? They forked only after a long debate... I don't know but...
I might be missing it, but where is the actual OpenVPN source for this fork? There are only a few files in the `src` directory, and most of them appear to be wrapping shell commands and the iptables/netfilter API.
I'm not quite certain, it seems the only change is integratio of ChaPoly1305 as an encryption method. But really, you should be switching to Wireguard, if all your devices support it.
OpenVPN is a mess, both in code and configuration, getting it to work as you want can be more difficult than editing Xorg.conf.
Wireguard is very very easy to setup (simple enough to fit the entire configuration plus encryption keys into an QR code you can scan with the Android App).
Wireguard is still very early stage, and many features that are useful for enterprise Software are not available (or even not possible) with Wireguard.
For example as of today Wireguard only works with static ip addresses. Using the official client it is not possible to assign IP (or pass DNS information) through a DHCP.
Many VPN providers (I think even AirVPN was in that list) even say today that Wireguard is too unproven (client and server) in day to day life (still new) and not audited. So VPN providers stick to the proven software for now (and some of the VPNs are simply to lazy to adopt to new tech).
Why are these changes not being contributed upstream? It does not inspire my trust to hear these people are making "critical bug fixes" and then hoarding them without explanation. Did OpenVPN3 refuse the updates, or are otherwise dragging their feet? Or, more likely, did AirVPN decide it was more interesting/important to use these fixes as a competitive advantage / differentiator for their fork, to get people to use their client or even leave upstream?