AirVPN is faster than NordVPN but...

[freak 1]

Hi,
I have 500/500 internet connection, Windows 10 PC, and using speedtest.net, I compared the performance of NordVPN with AirVPN.
On AirVPN, using hand-picked servers in Eddie, I'm able to achieve 120 MBit/s up/down - if I'm lucky. Often it is at the 90 MBit/s range.

With NordVPN, out of the box, I'm able to always get 300 MBit/s up/down, and regularly in the 400-450 MBit/s range.
NordVPN (in it default configuration) uses WireGuard, which certainly makes a lot of difference.

I read somewhere on this forum that some people are able to get 700 MBits/s through AirVPN. I do not know how to achieve
this, and I would like to see that good performance comes out of the box (Eddie).

Is the 120 MBits/s the best performance I can get with AirVPN?
What do I need to do to get good performance with AirVPN - ideally something closer to the 500/500, like NordVPN can do? 

[Staff 10016]

Hello!

Moving to "Troubleshooting and problems" because AirVPN is much faster than NordVPN with the same transit providers, we guess because NordVPN does not have our load balancing system (on the single server we mean) and NordVPN servers are congested at times. Using Wireguard by default also slows down NordVPN if your system supports AES-NI.

Also consider to open a ticket if necessary.

Kind regards
 

[Staff 10016]

@freak

Hello!

Try to use wintun (another driver for tun-like virtual network interfaces) as you might have a bottleneck caused by the TAP driver. Eddie 2.19.6 for Windows is packaged with OpenVPN 2.5 and they both support wintun, you can enable it with a click.

See here to download Eddie 2.19.6:
https://airvpn.org/forums/topic/46329-eddie-desktop-219beta-released/

Kind regards
 

[shiro213 1]

The other way round for me, 500 Mbit/s with AirVPN and 90 with NordVPN. NordVPN is slower most of the time. Set buffer to 512 KB. Connect to some server that isn't loaded too much, check the blue bar on the servers in https://airvpn.org/status

Cheers, happy new year to everyone!
 

[Staff 10016]

Check also https://airvpn.org/forums/topic/48234-speedtest-comparison/ in order to verify what you can expect from AirVPN best performance.

Kind regards
 

[freak 1]

On 12/30/2020 at 6:39 PM, Staff said:

@freak

Hello!

Try to use wintun (another driver for tun-like virtual network interfaces) as you might have a bottleneck caused by the TAP driver. Eddie 2.19.6 for Windows is packaged with OpenVPN 2.5 and they both support wintun, you can enable it with a click.

See here to download Eddie 2.19.6:
https://airvpn.org/forums/topic/46329-eddie-desktop-219beta-released/

Kind regards
 

Thanks @Staff! The use of wintun and CHACHA20-POLY1305 makes a significant difference in my situation.
@shiro213: I had the buffer size already set at 512 Kb - so that for me could not make a difference.
I'm able to achieve ~300 MBit/s down and ~150 MBits/s up.

I would recommend wintun + CHAHA20-POLY1305 + 512Kb buffer to be the default in Eddie - such that more people get the best possible performance out of the box.

Anyhow, even though this is a significant improvement, it is not yet in the NordVPN range with WireGuard. It does however beat NordVPN on OpenVPN.
I'm running Windows 10 on a QuadCore Intel Xeon E3-1265L v2, 2500 MHz.
It would be interesting to have WireGuard also available as an option for AirVPN, to see if that makes the difference...

[Staff 10016]

@freak

Hello!

Good, the infamous bottlenecks caused by the OpenVPN TAP driver should be resolved. However it's strange that CHACHA20 provides you with higher performance than AES does.

A possible explanation is that your system does not support AES-NI. Your CPU does, though, so you should beat CHACHA20 performance with AES-GCM, if you can enable AES-NI.

Wireguard must be faster than OpenVPN with CHACHA20, because Wireguard runs in the kernel space and CHACHA20-POLY1305 implementation should be fine,. Running in the kernel space, however, has security implications that must be considered. OpenVPN with AES, in an AES-NI supporting system, linked against latest OpenSSL which includes assembly code (at least for Linux), is faster than Wireguard according to our tests, even though OpenVPN runs in the userspace.

Wireguard offer is planned, but as you know it's a wreck lacking many basic features: no DNS push, no dynamic IP address assignment, no AES or other ciphers support, no TCP support, fixed bijection of real IP addresses onto client  keys/VPN address, clients real IP address storage in a file, thus posing paramount privacy as well as technical issues.

Many people will be disappointed and worried when they understand the implications of all of the above. Many other people will not be able to use Wireguard at all (mobile ISPs blocking or shaping UDP, countries blocking or shaping UDP etc.).

We will release software aimed at patching, when possible, those numerous problems, but we need to keep approaching and offering Wireguard with care.

Kind regards
 

[freak 1]

@Staff    The 'cipher AES-256-GCM' also works well.   Thanks!    It is difficult to see whether it is better - but it definitely also works fine.

[siberianwlf 3]

@freak if your ISP is traffic shaping try also experimenting with different ports and/or having 2 connections with multi gw setup in active-active mode. I'm hitting 1Gbit/s that way, my router runs on Pentium G4560 and pfSense

[Daniel15 14]

On 1/6/2021 at 2:37 AM, Staff said:

OpenVPN with AES, in an AES-NI supporting system, linked against latest OpenSSL which includes assembly code (at least for Linux), is faster than Wireguard according to our tests, even though OpenVPN runs in the userspace.

Do you have any details about how this testing was performed? For example, the configuration you used for OpenVPN and Wireguard?
I've been unable to replicate that with my own testing. I have two VPSes in the same data center, both with a CPU that supports AES-NI (Intel Xeon E5-2680 v2) connected via a 10 Gigabit LAN with jumbo frames (9000 MTU), rmem_max and wmem_max set to 54 MB, and BBR congestion control enabled. I'm testing throughout using iperf3. Unencrypted, I can get around 7.5 Gb/s between the two servers. The network is shared with other VPSes in the same data center, so I didn't expect to get the full 10 Gb/s.
With OpenVPN, I've only been able to achieve around 400 Mb/s maximum. However, with WireGuard on the same systems, I can reach 2.2 Gb/s.
I think as the connection gets faster, OpenVPN's context switching between kernel mode and userspace gets more expensive (especially over the internet where you're pretty much limited to 1500 MTU), and the cost of the context switching becomes greater than the difference in performance between AES and ChaCha20.
 

On 1/6/2021 at 2:37 AM, Staff said:

Wireguard offer is planned, but as you know it's a wreck lacking many basic features: no DNS push, no dynamic IP address assignment, no AES or other ciphers support, no TCP support, fixed bijection of real IP addresses onto client  keys/VPN address, clients real IP address storage in a file, thus posing paramount privacy as well as technical issues.

Many people will be disappointed and worried when they understand the implications of all of the above. Many other people will not be able to use Wireguard at all (mobile ISPs blocking or shaping UDP, countries blocking or shaping UDP etc.).

For what it's worth, I'd love if you offered Wireguard as an opt in feature. Still use OpenVPN by default, but provide Wireguard to people that want to use it, as long as they understand the risks.

[Staff 10016]

6 hours ago, Daniel15 said:

I think as the connection gets faster, OpenVPN's context switching between kernel mode and userspace gets more expensive (especially over the internet where you're pretty much limited to 1500 MTU), and the cost of the context switching becomes greater than the difference in performance between AES and ChaCha20.
 

Hello!

Yes, that's plausible. The outcome we and our customers had with Wireguard can have been capped by server bandwidth availability (which may become more significant with WIreeguard than OpenVPN, according to your report) and other factors. Anyway it's a real world/real life test performed between different providers and on equal ground with OpenVPN.

On the other end, your OpenVPN findings are low when compared to our customers' and ours.. With weaker CPUs (old i7) our clients achieve much higher performance than yours, up to 700 Mbit/s, with a single instance, while on the server side, with a slightly weaker CPU than yours (but maybe stronger on a per.-core basis, which is crucial with OpenVPN), we could manage to beat 700 Mbit/s on a single OpenVPN daemon connected to about 200 clients.

Another factor that comes to mind is the SSL library, which you don't need to worry about when you run Wireguard, but which is vital for OpenVPN performance. Did you compile the library with high optimization for your own server?  We recommend OpenSSL currently in x86-64 systems, because it is now remarkably faster than mbedTLS which lacks asm. NOTE: we have never tested LibreSSL and we don't know whether it's a pain to link OpenPVN against LibreSSL.

If you need to beat the current performance you report, on top of OpenVPN and OpenSSL optimizations for your system when you build them, the most obvious way is running multiple instances, each one with a different CPU affinity. With the large cores amount you have, you can even aim to saturate your 10 Gbit/s line. Currently our VPN servers Xuange and Ain work around 2-3 Gbit/s with a very low load (around 11 on 32 "CPU" systems).

Kind regards
 

[Daniel15 14]

Thanks for the details!

With the large cores amount you have

I've only got a virtual server (VPS), that only has access to two cores, with "fair share" CPU usage (not dedicated), so running multiple instances wouldn't really work for me (since I don't have dedicated CPU cores, I can't set CPU affinity in a way that'd actually work). That's one reason I'm pretty impressed with WireGuard - It can achieve a lot even on shared hardware.