Wireguard response from Mullvad

[Staff 9972]

@go558a83nk

The main advantage over OpenVPN in terms of performance is the fact that Wireguard runs in the kernel space while OpenVPN runs in the userspace, Cipher CHACHA20 is available in OpenVPN too. It's slower than AES in AES-NI supporting systems, so it is very relevant only in those systems which do not support AES-NI, typically mobile and embedded devices based on ARM processors.

So when Wireguard can't run in the kernel space (for example when you use it in Android or iOS) you lose that gain.

The fact that Wireguard does not support TCP is bad for us, because it cuts out a  very remarkable percentage of our users: those who have their ISP blocking or heavily shaping UDP, those who need to pass through some proxy (which supports only TCP) to get on to the Internet, and those who need to tunnel the VPN protocol over SSH or sTunnel.

Kind regards
 

[WxjThf8HJV5ShAQ 1]

13 hours ago, go558a83nk said:

Saying that wireguard gained performance by eliminating TCP is like saying my car got faster because I removed low gears.  Physically impossible and it's just silly.

Wireguard is supposedly faster because of its modern protocol and the fast chacha20 data cipher and that's comparing UDP vs UDP.

Please read up on the facts. TCP-over-TCP introduces a dramatic loss in transmission performance known as TCP meltdown. OpenVPN recommends using UDP also to avoid this overhead. Anyway, yes wireguard is built from scratch with less code to execute and runs in kernel space which also adds to its performance gain. Not liking and criticizing because it doesn't do TCP is asinine since you're using the wrong tool for your use-case. If you need TCP, either run it over a TCP supported method as mentioned before or use something else. 
 

TCP stands for Transmission Control Protocol. Basically a means of sending traffic over the Internet with some built-in measures to ensure that traffic can get to its destination. If anything goes wrong during transmission, the protocol has some means to try to find a solution (send the packet of information again or try an alternative route or such). TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it. The underlying layer may detect a problem and attempt to compensate, and the layer above it then overcompensates because of that, and this overcompensation causes delays and problems with the transfer of data. That's the layman's version of it that is easy to explain and understand. We therefore instead recommend that you use UDP, which has no transmission control, and on top of that send your TCP traffic as usual, so that there's only one layer of transmission control, and the problem can be avoided.

Some people mistakenly believe that TCP is the best protocol to ensure the best reliability and performance for sending traffic over the Internet. This is the exception.

If you want to learn more there's a good article here on an external website: Why TCP Over TCP Is A Bad Idea

[WxjThf8HJV5ShAQ 1]

6 hours ago, Staff said:

@go558a83nk

The main advantage over OpenVPN in terms of performance is the fact that Wireguard runs in the kernel space while OpenVPN runs in the userspace, Cipher CHACHA20 is available in OpenVPN too. It's slower than AES in AES-NI supporting systems, so it is very relevant only in those systems which do not support AES-NI, typically mobile and embedded devices based on ARM processors.

So when Wireguard can't run in the kernel space (for example when you use it in Android or iOS) you lose that gain.

The fact that Wireguard does not support TCP is bad for us, because it cuts out a  very remarkable percentage of our users: those who have their ISP blocking or heavily shaping UDP, those who need to pass through some proxy (which supports only TCP) to get on to the Internet, and those who need to tunnel the VPN protocol over SSH or sTunnel.

Kind regards

 

Agreed, I don't propose one solution or the other, but offer the option to those of us who want to use it as it fits what we are trying to do.

Thank you.

[go558a83nk 362]

20 minutes ago, WxjThf8HJV5ShAQ said:

Please read up on the facts. TCP-over-TCP introduces a dramatic loss in transmission performance known as TCP meltdown. OpenVPN recommends using UDP also to avoid this overhead. Anyway, yes wireguard is built from scratch with less code to execute and runs in kernel space which also adds to its performance gain. Not liking and criticizing because it doesn't do TCP is asinine since you're using the wrong tool for your use-case. If you need TCP, either run it over a TCP supported method as mentioned before or use something else. 
 

TCP stands for Transmission Control Protocol. Basically a means of sending traffic over the Internet with some built-in measures to ensure that traffic can get to its destination. If anything goes wrong during transmission, the protocol has some means to try to find a solution (send the packet of information again or try an alternative route or such). TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it. The underlying layer may detect a problem and attempt to compensate, and the layer above it then overcompensates because of that, and this overcompensation causes delays and problems with the transfer of data. That's the layman's version of it that is easy to explain and understand. We therefore instead recommend that you use UDP, which has no transmission control, and on top of that send your TCP traffic as usual, so that there's only one layer of transmission control, and the problem can be avoided.

Some people mistakenly believe that TCP is the best protocol to ensure the best reliability and performance for sending traffic over the Internet. This is the exception.

If you want to learn more there's a good article here on an external website: Why TCP Over TCP Is A Bad Idea

I know this.  What I'm saying is that removing TCP doesn't make UDP faster but that's what you imply.  People who complain about openvpn being slow have already tried UDP as that's the default protocol with AirVPN and every other VPN I've tried.  They're typically only using TCP if their network requires it.

[WxjThf8HJV5ShAQ 1]

3 hours ago, go558a83nk said:

I know this.  What I'm saying is that removing TCP doesn't make UDP faster but that's what you imply.  People who complain about openvpn being slow have already tried UDP as that's the default protocol with AirVPN and every other VPN I've tried.  They're typically only using TCP if their network requires it.

What I'm saying is that TCP doesn't add any value to the Wireguard design except if you want to use it to get through open ports. In that case, use something else.

1. OpenVPN: TCP/TCP - Bad
2. OpenVPN: UDP/TCP - You're establishing the tunnel via UDP here, so no gain over Wireguard
3. Wireguard: You're establishing the tunnel over UDP, same as #2 above but wireguard is more performant, so choose wg.

I fail to see the benefit of OVPN UDP/TCP over Wireguard. Unless you're trying to use a non-recommended configuration of OpenVPN (TCP/TCP) in which case you're only doing so due to other limitations which should be the exception and not the rule.

BTW - Another good reference where you can get wireguard to work where UDP is blocked.

[Terry Stanford 11]

This thread was a very interesting read. I have to say I was considering switching back to PIA. I have a subscription with them but I just don't trust anyone behind any software as much as I trust the guys at AirVPN. I spent a good year looking at VPN outfits and nobody gave me the warm feeling of trust I feel I have rightly placed in AirVPN.
I did want to try Wireguard as friends of mine said it was better and may help my phone (android 10) connection stay more stable, it's choppy and often mail servers wont connect (through Eddie) as well as other apps. It may be Eddie not being compatible with my OS though, so I am going to try OpenVPN for Android from Fdroid store (when I work out how!). I will keep an eye on this thread but for now I think I was mis-sold the idea of WG. I didn't even know there were security and/or privacy issues, in fact I was given the impression it was more secure and private! glad I found this thread

[RaineyPass 12]

I tried Mullvad for a month in June and used their Wireguard for a while until going back to their Open VPN.  WIreguard was fast, noticeably faster than OpenVPN but Mullvad's own description of how it works with their privacy concerns was odd considering their (and many other VPN providers) enthusiastic endorsement of it.   Every VPN I consider reputable that has implemented Wireguard seems to love its security but warns about what they had to do for privacy.

Mulvad and others have similar static IP privacy mitigations.  Mullvad's method kinda broke for a month, nice:
https://mullvad.net/en/blog/s

Now Wireguard's in the Linux kernel with Everyone Linux waxing ecstatically, even Torvalds.  Weird.  Everyone's selling speed and lines of code with the word "modern" appearing ad nauseum.

Open VPN's marketing, if you can call it that, amounts to good encryption, good privacy, passed a million audits, been around for ever, good choice, huge user base.  I can buy that; The Wireguard Sell Job is too typically "Tech."    

Seems like Wireguard's security is fine but the static IP thing as described by Wireguard (why?) leaves high privacy up to the VPN service to implement.
https://www.wireguard.com/#simple-network-interface
 

[nva 0]

This thread is hilarious and I believe privacy issue with Wireguard static internal IP is massively overblown.

Full privacy is guaranteed only if I don't have to trust anybody and that has nothing to do with the VPN protocol of my choice. If you use any centralized VPN service, you're trusting them to not log your connection and report to authorities accordingly. None of them provide trustless solution. By trustless I mean they technically can't log even if they want to.

OpenVPN is horribly slow as typical resident internet speed approaching Gigabit. The CPU with best single core performance has trouble reaching 500Mbps of OpenVPN routing. Of course this can be solved by having multiple tunnels and do "load-balancing" between them, but that's ugly hack. Meanwhile a cheap Raspi can handle 700 - 800Mbps of Wireguard.

I'm still using OpenVPN with AirVPN, but i'm going to replace my pfSense router with VyOS for native WG support. In-kernel WG implementation for FreeBSD is still years away, according to Netgate.

Most smartphone users with VPN would report that Wireguard is much better for battery life. This is the popular use case in which OpenVPN is worse for privacy because I can't have OpenVPN enabled all day.

[NaDre 157]

An earlier post by staff in this thread implies that AirVPN does intend to provide Wireguard in time.

https://airvpn.org/forums/topic/44949-wireguard-response-from-mullvad/?do=findComment&comment=107170
"... anyway we will make them all very clear when we offer Wireguard."

Perhaps sometime after the next stable release of Debian is released, with Wireguard support?

I wonder if the question of a static local IP address could not be mitigated substantially by AirVPN. At some point, on the server, the "AllowedIPs" value for the Wireguard configuration file for each user will have to be set. Collisions will have to be avoided. Much like forwarded port numbers now. It seems to me allowing a user to use a web interface similar to the one used for ports in order to set the local IP address would go some way to mitigating this. Users who are concerned could change this frequently. They would need to download a new network configuration script for their device after doing that. Of course AirVPN would keep no record of past local IP addresses, just as it keeps no record of past forwarded port numbers.

For those using an AirVPN wrapper program (i.e. Eddie or Hummingbird), could there not be a handshake in the server API to randomly change the local IP address just before starting Wireguard?

It seems to me that the existing API and client, as well as the load balancing front-end are probably already much more complicated than anything AirVPN would need to do to achieve something similar to what I have described.

EDIT:

Keep in mind that even with OpenVPN, there is a record of the local IP address for each server kept by each server, so that the same local IP address will be given again to the same client. Using "--ifconfig-pool-persist file". At least it used to be like this, Has AirVPN dropped this in favour of a random local IP address on each connection?

When AirVPN does provide Wireguard, I would expect AirVPN will emulate this behaviour of OpenVPN. I will explain why.

At present there is a separate sub-net for each server to accomodate multi-homing as is done now. I assume this will be kept. And a WG configuration file will need to be generated for each server for each user before any WG connections are attempted. Unless AirVPN intends to write some sort of font-end for Wireguard connections. To me this appears to force emulation of the current OpenVPN behaviour.
 

[Clodo 176]

Quote

Perhaps sometime after the next stable release of Debian is released, with Wireguard support?

It is not mandatory to wait for next Debian version: we are already testing up to date WireGuard version.
When we'll make WireGuard available to customers, it will be on all servers.
 

Quote

At some point, on the server, the "AllowedIPs" value for the Wireguard configuration file for each user will have to be set

Exactly, it's unavoidable.
 

Quote

Of course AirVPN would keep no record of past local IP addresses, just as it keeps no record of past forwarded port numbers.

With OpenVPN that's currently correct.

However, with WireGuard we need to keep it, because it's written in .conf file generated via Config Generator and stored by users. See below for users' option to change or invalidate it.

 

Quote

For those using an AirVPN wrapper program (i.e. Eddie or Hummingbird), could there not be a handshake in the server API to randomly change the local IP address just before starting Wireguard?

Some of our competitors do this. 
Some accept only their official client software because of the issue. That's neither good nor acceptable for us, as we don't want to lock user into our software.
Therefore the change you mention might be an Eddie's additional feature but we will try to make Wireguard main branch as secure as Eddie's, whenever possible.
 

Quote

>Keep in mind that even with OpenVPN, there is a record of the local IP address for each server kept by each server, so that the same local IP address will be given again to the same client. 

 

Quote

>Using "--ifconfig-pool-persist file". At least it used to be like this, Has AirVPN dropped this in favour of a random local IP address on each connection?

Yes, we still use ifconfig-pool-persist in OpenVPN.  It's very different than Wireguard's addresses binary mapping, especially under a legal point of view.

When a client is connected, OpenVPN daemon necessarily needs to link clients' public and VPN IP addresses. As soon as the client disconnects the link is lost.
One of WireGuard controversies is that client's real IP address remains visible with 'wg show' even after client's disconnection. The issue is resolved by removing and re-adding the peer after a disconnection (disconnection in WireGuard is basically a handshake timeout).

 

Quote

>At present there is a separate sub-net for each server to accomodate multi-homing as is done now. I assume this will be kept. And a WG configuration file will need to be generated for each server for each user before any WG connections are attempted. Unless AirVPN intends to write some sort of font-end for Wireguard connections. To me this appears to force emulation of the current OpenVPN behaviour.

Some current testing implementation features are:

• Unique WireGuard IPv4 and IPv6 subnets across servers which don't conflict with OpenVPN subnets
• Assigning a non-conflicting, pseudo-random, local IP address  for each customer's device (for AllowedIPs), similar to remotely forwarded port assignments
• Users can renew a local IP address for a device anytime. WireGuard .conf manually used in official client would become invalid. Eddie will automatically update. The same happens when a user regenerates OpenVPN client certificate and key pair: the action invalidates any previously stored OpenVPN profile.

We will offer an API to automate the above, letting users write a script that performs HTTPS calls to change local IP address, download updated .conf, and then wg-quick. 

An API to obtain a .conf file (Config Generator without UI) is already in production for OpenVPN and it will be of course available for WireGuard too.

When a device's WireGuard local IP address changes, up to a 10 seconds wait is required. It's the time required to propagate device key onto all VPN servers, in order to update the AllowedIPs peer node.

No other solution allowing us to let our customers use the official WireGuard client with a simple .conf file and, at the same time, preserve their privacy currently exists.

Please keep the above information as a proposal: we are currently studying pros and cons and something may change before WireGuard public beta support in our VPN servers is available.
 

[moejoe 1]

Quote

Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high;

This is an old statement from airvpn 

So is this still the case ? 

best regards 

[Flx 76]

On 7/30/2020 at 7:38 AM, Clodo said:

It is not mandatory to wait for next Debian version: we are already testing up to date WireGuard version.
When we'll make WireGuard available to customers, it will be on all servers.

When Wireguard AirVPN wave of servers will be available? Any updates?