Sharing/comparing of wireguard bandwidth/throughput benchmarks vs.other vpn solutions

Software SW tweaks
1

It might perhaps be interesting for TO users to share here benchmarks of wireguard’s bandwidth/throughput performance in their real life enviroment compared to other vpn solutions, that is not in the local LAN but over public WAN.

Unless there is a remote WAN vpn exit node involved which is controlled by the TO user it will probably a VPN provider’s exit node with unknown bandwidth capabilites and thus benchmark results may only be rather indicative.

Particularly interesting might be the loss of bandwidth due to the cryptographic overhead of the various vpn solutions compared to the bare connection with the ISP.

1 Like
2

Haven’t yet got around to test wg (will update here once done) but let’s start with an openvpn benchmark as baseline

  • ISP promise 100 Mbps down | 20 Mbps up
  • NetMetr average ~92 Mb/s down | ~20 Mb/s up
  • Ovpn | WG exit node promise 150 Mbps down | 150 Mbps up
  • Ovpn | WG exit node actual meter > 150 Mbps down | > 150 Mbps up
  • Ovpn TO client actual meter ~ 50 Mbps down | ~ 20 Mbps up
  • Ovpn TO client bandwith loss ~46 % down | 0 % up
  • WG TO client actual meter ~ 82 Mbps down | ~19 Mbps up
  • WG TO client bandwidth loss ~ 11 % down | ~5 % up

The Ovpn | WG exit node is controlled by me (except for the bandwidth provision), utilizes TUN | WG UDPv4 and the physical distance between TO router and the exit node is in the range of 1.500 km.

Loss percentage is calculated against the NetMetr figure and not the ISP promise.

3

Did you test wireguard? I would be interested in the results to see if it‘s worth to migrate my setup from OpenVPN to wireguard.

4

Just updated the figures. Mind you that may not be a blueprint for every other setup and outcome may differ.

The speed test was conducted with OpenVPN v 2.4.4 on the TO side and v 2.4.6 on the server (with a heavy encryption implementation - ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, tls-crypt, ecdh-curve secp521r1, dhpram 4096 bit).

WG on the other hand v 0.0.20171017 on the TO and v 0.0.20180708 on the remote endpoint (server) and utilizing a preshared key.

1 Like
5

After having wireguard upgraded both ends to version 0.0.20180910 noticed severe bandwidth degradation

WG TO client actual meter ~ 50 Mbps down | ~ 12.5 Mbps up

6

some wireguard improvement after the previous regression now with v 4.4.157+0.0.20180918 on the TO and v 0.0.20180925 on the remote endpoint

WG TO client actual meter ~ 78 Mbps down | ~ 16.5 Mbps up

7

FTR, these observations should be better reported to the Wireguard mailing list.

9

This is an update on wireguard now with version 0.0.20181007 on the remote endpoint and having the SQM instance for the wireguard interface on the TO disabled (SQM instance for WAN interface still enabled).

Download (bandwidth in Mbps)

exit node promised bandwidth actual measured bandwidth bandwidth loss (promise vs actual) bandwidth loss lowest actual ISP (local here) vs actual VPN
local ISP 100 ~ 92 ~ 8 %
remote ISP > 150 > 150 0 %
OpenVPN ~ 50 ~ 46 %
WG ~ 84 ~ 9 %

Upload (bandwidth in Mbps)

exit node promised bandwidth actual measured bandwidth bandwidth loss (promise vs actual) bandwidth loss lowest actual ISP (here local) vs actual VPN
local ISP 20 ~ 20 0 %
remote ISP > 150 > 150 0 %
OpenVPN ~ 20 0 %
WG ~ 17.5 ~ 13.5 %
1 Like
10

Update with currently wg 0.0.20181119 on both ends.

Down has a bit improved from previously ~ 84 Mbps to ~ 90 Mbps and the loss being a mere ~ 2.2 % now (previously ~ 9 %).

Up is still suffering a loss of ~ 10 % with a slight improvement from previously ~ 17.5 Mbps to ~ 18 Mbps.

12

For the technical inclined some Master’s Thesis about performance of VPN gateways

The thesis features a performance comparison between Wireguard, OpenVPN, and Linux IPsec

1 Like