LWN: Comments on "Virtual private networks with WireGuard"

WireGuard: Problem with routing all traffic through the tunnel

DarkMelman — Tue, 27 Nov 2018 14:01:59 +0000

I have a working setup with WireGuard „Server“ on a Ubuntu 18.04.1 System.
1 Client also Ubuntu is working fine a all the traffic goes through the tunnel with config 0.0.0.0/0
When I am using my iPhone with the WireGuard App, with AllowedIPs = 0.0.0.0/0 I can ping the server an the other client but I can’t reach the internet.
When I configured AllowedIPs = 10.0.0.2/24 then I can connect the internet but an Iip-check shows, that its using the public ip from the iPhone and not from the server.

Did anyone have an idea what can be the issue?
Thanks a lot! Best Regards

Virtual private networks with WireGuard

zuki — Mon, 19 Mar 2018 15:43:19 +0000

Also "Example 13" in https://www.freedesktop.org/software/systemd/man/systemd.....

Virtual private networks with WireGuard

biergaizi — Mon, 19 Mar 2018 12:04:33 +0000

I believe WireGuard offers the most robust, latest state-of-art cryptography and the highest performance and best quality of implementation compared to any other solutions. Even the humble base64 encoding is implemented in cryptographic-grade constant-time code.

If I remembered correctly, the lifetime of a single session key is 5 minutes, every five minutes the session key is rotated by X25519 Diffie-Hellman key exchange. The key exchange itself can be further protected by 256-bit ChaCha20 encryption using a pre-shared key, in case a massive quantum computer breaks ECC in the future (yes, it's explicitly designed for this use case) - a quick-and-dirty approach towards Post-Quantum Cryptography. And because the Diffie-Hellman is still there, losing the PSK doesn't affect every a single bit of security without considering quantum computers.

In 2050 when a giant quantum computer have been built by the NSA, all PGP, HTTPS, TLS, IPSec, etc-encrypted data will be broken, but your WireGuard traffic is still secured if your PSK is exchanged out-of-band.

What lead to different designs in the past?

jengelh — Fri, 16 Mar 2018 09:55:51 +0000

>with tunnel mode you get another set of network address prefixes to deal with, which complicates routing.

Not necessarily. I have a tunnel mode setup running that looks like this, and no extra routes are needed.

conn x
leftid=@a
left=5.9.23.70/32
leftsubnet=5.9.23.70/32,88.198.1.160/29
rightid=@b
right=62.245.7.1
rightsubnet=62.245.7.1/32

Virtual private networks with WireGuard

Bronek — Tue, 13 Mar 2018 23:29:41 +0000

Would be nice to also have the support for WireGuard interfaces added to netctl

What lead to different designs in the past?

perennialmind — Tue, 13 Mar 2018 03:33:35 +0000

IPSec tunnels encapsulate packets much as do other tunnels, but they behave very differently in practice. IPSec policy, for both tunnel and transport mode, imposes a colleciton of special cases on the normal routing path. I tend think of it as another, particularly rigid firewall/NAT layer. I find it much easier to internalize the "route-based" and "point-to-point" IPSec modes: VTI and BEET respectively. The former has broad industry support and allows you to largely opt-out of key elements of the original IPSec design. That's about as politic as I can be on the subject.

Much network-level flexibility is simply off the table if you stick to policy-based IPSec. Want failover? Don't count on routing protocols like OSPF or IS-IS to work over standard IPSec tunnels. Forget about Bidirectional Forwarding Detection helping you figure out whether your tunnel is actually good for handing off packets. Do not forget to take extra care with your firewall to distinguish between the pre- and post- encapsulation stages as packets get cloned and re-injected.

Virtual private networks with WireGuard

james — Mon, 12 Mar 2018 22:46:02 +0000

I've seen people go one stage further and configure the router without a default gateway, just with routes to the public IP addresses of the VPN concentrators.

Those routes to the VPN concentrators are the only routes over the WAN link(s): even without a firewall, the router won't know which way to send packets to the Internet until the VPN is up. Then routing protocols (configured to talk to the internal addresses of the VPN concentrators) can add more routes.

Virtual private networks with WireGuard

smurf — Sat, 10 Mar 2018 06:17:53 +0000

Yes. You can also add a pre-shared key for further data confabulation.

Virtual private networks with WireGuard

pabs — Sat, 10 Mar 2018 00:54:12 +0000

Does WireGuard have forward secrecy?

Virtual private networks with WireGuard

coolhandluke — Sat, 10 Mar 2018 00:53:49 +0000

Just to chime in for the possible benefit of others and in addition to the other comments here, Jason (zx2c4) previously stated [0] that "Mac and Windows support ... [is] already mostly done" but that "there may still be a bit of work to do here".

So it certainly looks like cross-platform interoperability is both desired and actively being worked on (as far as open-source devices go, of course). On closed platforms (IOS, JunOS, etc.), it would obviously be up to the vendor whether they decided to add support for WireGuard.

Personally, I'd love to support for WireGuard available in both FreeBSD and OpenBSD. I expect that this will happen eventually, likely some time after it is fully upstreamed in mainline and most of the kinks have been worked out.

[0]: https://lwn.net/Articles/748584/

Virtual private networks with WireGuard

coolhandluke — Sat, 10 Mar 2018 00:20:16 +0000

In the case where all traffic absolutely *must* go over a VPN (or else not be sent at all), I have previously configured firewall rules (both on the host itself as well as its upstream router, for an additional layer of defense) to only permit outbound IP traffic destined to the VPN gateway and drop any other traffic.

This ensures that traffic will not be sent out if the VPN link dies for any reason.

Whether or not this approach is an acceptable solution for you obviously depends on your specific requirements.

What lead to different designs in the past?

zdzichu — Fri, 09 Mar 2018 12:16:29 +0000

This isn't innovative. There were always two approaches, WireGuard just choose one of them.

Within IPSec the appropaches are called "modes". There is a "transport mode", which encrypts data which would normally go unencrypted. And there is a "tunnel mode" which gives you separate network interface handling only encrypted traffic. Both have their advantages and disadvantages – for example transport mode gives you ability to encrypt only some of the streams between two hosts. And with tunnel mode you get another set of network address prefixes to deal with, which complicates routing.

WireGuard avoids complexivity of IPSec by making a sensible choices.

What lead to different designs in the past?

jarmar — Fri, 09 Mar 2018 10:00:23 +0000

I am not a kernel programmer, but reading through the introduction and motivation in the white paper, this (behaving like any other network interface) seems like the "obvious" way to implement VPNs (as also evidenced by the small amount of code required). For that reason, it would be interesting to read why previous offerings *didn't* use this solution. What are the downsides of this approach? The whitepaper mentions:

> It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update.

Virtual private networks with WireGuard

z3ntu — Fri, 09 Mar 2018 08:37:56 +0000

Are you sure "ip addr add 10.0.0.1/24 wg0" shouldn't be "ip addr add 10.0.0.1/24 dev wg0"?

Virtual private networks with WireGuard

Alphix — Thu, 08 Mar 2018 12:21:49 +0000

There's some examples in the Debian wiki Wireguard page.

Virtual private networks with WireGuard

thestinger — Thu, 08 Mar 2018 05:37:49 +0000

It's worth noting that as of Android 8.0, there's a toggle to block connections not made via the always-on VPN to deal with issues like an OpenVPN app dying. A kernel implementation is more efficient but there's a sane way to use userspace VPN implementations.

Virtual private networks with WireGuard

smurf — Wed, 07 Mar 2018 23:04:25 +0000

There is no special command; if you need the command line, continue to use "wg".

With systemd, you add a .netdev file (the contents of which are almost identical to a wireguard config file) to /etc/systemd/network, and restart systemd-networkd.

Virtual private networks with WireGuard

flussence — Wed, 07 Mar 2018 22:43:13 +0000

What does the systemd equivalent of the example command in the article look like? I don't run it, just curious.

Virtual private networks with WireGuard

smurf — Wed, 07 Mar 2018 14:57:00 +0000

Wireguard simply throws away packets it can't decrypt. It works at wire speed (for some definition of "wire", anyway) so even if you saturate the link with bogus encrypted packets, that's no worse than saturating it with any other kind of packet.

Android will get a userspace implementation.

Virtual private networks with WireGuard

smurf — Wed, 07 Mar 2018 14:45:10 +0000

Wireguard does not "lose a connection" the way a VPN link dies. The connection and the rest of the kernel setup are is still there, packets simply get dropped until the connection is re-established.

I've been using it for months on my office VPN. Zero problems, it's a breeze to set up compared to OpenVPN (and much faster).

Virtual private networks with WireGuard

bavay — Wed, 07 Mar 2018 14:12:37 +0000

I am absolutely naive with VPNs, so my questions might be totally off, but one thing I find potentially dangerous is the ability to silently loose a VPN connection. If you are transmitting sensitive data over a link that you know is most probably under surveillance, you absolutely don't want the VPN to disconnect and your data transfer to resume over the non-VPN network (when accessing public IPs). Is it something that is addressed at the VPN level or should it be addressed at another level? Does WireGuard offers something to prevent it?

Mathias
PS: Yes, the data transfer itself is also encrypted, but better safe than sorry and encapsulate it within a VPN alongside masses of uninteresting data

Host "names"

ejr — Wed, 07 Mar 2018 08:38:48 +0000

One very useful aspect of the Anyconnect-style (at least ocserv) certificate management is that I can embed a host name in the key and not need to worry about setting up my own mapping. As far as I can tell, WireGuard punts that to higher-level tools. The choice is fine but may slow deployment.

(I dodge DNS altogether for server->client lookups via occtl. Maybe not the best choice, but it certainly keeps things simple for connecting back to my RaspberryPi sensors.)

Virtual private networks with WireGuard

amworsley — Wed, 07 Mar 2018 02:18:03 +0000

The key advantage as stated was a vastly smaller implementation (4000 lines) making vastly easier to check for flaws.
Another additional design features is that it has very few options and deliberately selected modern algorithms likely to be secure for much time in the future. Greatly reducing the chance of insecurity through mis-configuration versus ipsec.
Finally once a secure tunnel is set up the remote end can change IP as the public key is used to verify any new IP address automatically - removing another "brittleness" where transport network changes can kill the connectivity.

I am not aware of how it handles replay and denial of service attacks but hopefully when it is merged in there will be many chances to check for these and other issues.

Also if it is 4000 lines to implement it would be hard to add it to other platforms.
Presumably if it is popular Android phones could start using fairly quickly.
It would be interesting to know how it would handle the China's great firewall.

Virtual private networks with WireGuard

SEJeff — Tue, 06 Mar 2018 21:16:46 +0000

Ah thanks! They both run EdgeOS, so it will probably work on the security gateway as well. I might give it a go and let upstream know.

Virtual private networks with WireGuard

zdzichu — Tue, 06 Mar 2018 20:41:45 +0000

Moreover, systemd-networkd includes support for WireGuard for couple of versions. The config file format is of course the same. So basically Linux distribution will support WireGuard almost universally the moment it's included in kernel.

Virtual private networks with WireGuard

judas_iscariote — Tue, 06 Mar 2018 20:36:30 +0000

"I ran a test, using WireGuard to set up a link between the desktop machine and a remote cloud instance. It took a little while, but that is mostly a matter of being extremely rusty with the ip command set. "

Current versions of systemd-networkd, (v237+) support setting up wireguard without any fiddling with "ip" atrocious command interface .. of course you still need the out of tree kernel modules.

Virtual private networks with WireGuard

zx2c4 — Tue, 06 Mar 2018 20:33:21 +0000

Specifically I mean: https://github.com/Lochnair/vyatta-wireguard/releases -- so their EdgeRouter devices.

Virtual private networks with WireGuard

SEJeff — Tue, 06 Mar 2018 20:27:05 +0000

Assuming you mean it would work with the Unified Security Gateway and/or EdgeRouter series of equipment? Anything else (I overlap in current Ubiquiti owner + potential fan of wireguard after seeing Thomas Ptacek say such nice things about it.)

Virtual private networks with WireGuard

zx2c4 — Tue, 06 Mar 2018 19:30:10 +0000

WireGuard is available for Ubiquiti equipment actually. For other operating systems, we're developing several cross-platform implementations. So we should have pretty good compatibility throughout.

Virtual private networks with WireGuard

Cyberax — Tue, 06 Mar 2018 19:03:33 +0000

What is the advantage compared to IPSec? The in-kernel ipsec encryption is perfectly adequate for most purposes (just ignore the crappy ciphers).

The userspace key agreement protocol (IKE) is another story, but you don't have to use it, ipsec actually has a standardized cross-platform API to manage the kernel-level keys.

Virtual private networks with WireGuard

dmoreno — Tue, 06 Mar 2018 18:57:11 +0000

Using the included wg-quick (https://git.zx2c4.com/WireGuard/about/src/tools/wg-quick.8) makes configuration and management a bit easier, giving away some control.

Virtual private networks with WireGuard

dsix — Tue, 06 Mar 2018 18:08:59 +0000

While there is no guarantee of adoption, there is a page and a plan for cross-platform userspace implementations: https://www.wireguard.com/xplatform/

Virtual private networks with WireGuard

yokem_55 — Tue, 06 Mar 2018 17:06:02 +0000

The nice thing about ipsec vpn's is that there is a fair amount of intervendor interoperability that is possible. A mixed vendor ipsec network with Cisco, Juniper and Ubiquiti endpoints is possible. OpenVPN is portable to lots of different platforms.

Will wireguard ever be more than just a linux thing?

Virtual private networks with WireGuard

Lekensteyn — Tue, 06 Mar 2018 16:42:04 +0000

> It will be interesting to try WireGuard at the next conference with an overloaded network to see how well it copes with packet loss.

WireGuard encapsulates IP packets in its transport messages and does no attempt on retransmission (leaving this up to the upper layers). The initial handshake consists of only two (small) UDP datagrams (one for each direction), there are no explicit acknowledgement messages.

Compare this to (for example), OpenVPN with its TLS authentication mode that requires many more UDP datagrams to transport the full TLS handshake (including large certificates), it seems likely that WireGuard is faster to establish a session.

Virtual private networks with WireGuard

zx2c4 — Tue, 06 Mar 2018 15:44:22 +0000

> Getting to that point will require that WireGuard be merged into the mainline kernel, though. Donenfeld has stated that upstreaming the code was his intent from the beginning, but there have been almost no postings of the code on the kernel mailing lists.

Expect to see some patches in the spring for this. We're steadily moving ahead to our v1 submission. I should write another status update to netdev; thanks for encouraging me here.

Virtual private networks with WireGuard

dezgeg — Tue, 06 Mar 2018 15:28:03 +0000

It might be worth noting that even the Penguin Chief himself has expressed his opinion on wanting WireGuard merged: https://lkml.org/lkml/2018/2/13/752