I also want to point out that Manuel Schoelling been working on and released a p2p [1] distributed hash table [2] work on top of WireGuard to build a VPN mesh. He talked about this recently [3] at FOSSEM.

[1] https://github.com/manuels/wireguard-p2p [2] https://github.com/manuels/bulletinboard-dht [3] https://www.youtube.com/watch?v=0Z8Lougf9Vk

Any idea how this compares to CJDNS? That sounds similar.

https://github.com/cjdelisle/cjdns

Interesting! I really like this from their description: "Compared to behemoths like *Swan/IPsec or OpenVPN/OpenSSL, in which auditing the gigantic codebases is an overwhelming task even for large teams of security experts, WireGuard is meant to be comprehensively reviewable by single individuals."

It's so rare and so pleasant to see people treating small code base size and high comprehensibility as a major benefit, rather than a nice-to-have or a negative.

I have never encountered a situation where high comprehensibility was viewed as a negative. Can you give an example of when this might be the case?

When looking at it from a business perspective, comprehensibility only makes sense to a certain degree. It often takes a lot of time to get to a certain degree of quality, which could otherwise be used elsewhere.

I think that part fits with the "nice to have", and the "small code base size" is sometimes viewed as either a nice to have or a negative. It's reasonable to abbreviate it this way instead of saying "people viewing a high comprehensibility as a nice-to-have or small code base size as a nice-to-have or a negative".

Well, they never phrase it that way. Instead they see its opposites, complexity and mystery, as positives. E.g., the complicated, innovative new architecture that turns out to be a boat anchor. Or the people who, intentionally or not, write themselves 200kloc of job security and treat the resultant incomprehensibility as a byproduct of their genius. Rather than their failure to apply that genius to making things clear and approachable to others.

It's usually just not a priority. Making it your top or one of your top priorities is rare.

It might be seen as a waste of time.

Wireguard sounds intriguing, but it seems to lack one of tinc's main features, which is presenting a fully-reachable network regardless of the underlying connectivity.

I really like being able to roam with my laptop(s) and have my routing table look exactly the same, as opposed to having a "home network" and then having to explicitly "connect to the vpn" when away from it.

With a quick reading, it looks like the Wireguard protocol wouldn't preclude adding this functionality via userspace forwarding daemons on the better-connected hosts. It's just not there right now, especially in the just-works package tinc provides.

Indeed we've had nice conversations with the author about using Tinc's full-mesh logic ontop of WireGuard.

Does that mean that this is something expected to become available in WireGuard in the future?

In tinc rather. The idea would be that tinc would use WireGuard as the underlying backend.

Just wanted to take a second and personally say thanks for a great(and easy to understand) product!

The amazing thing about wireguard is its ease of use once you understand its concepts. Just read the part under 'Cryptokey Routing' on the homepage and you're good to go. Also the this page[1] you want more sophisticated setup (like remote ssh to your computer behind NAT without affecting your normal browsing)

If anyone wants help with their setup, ask here[2]. I can help anyone out with questions. I didn't create the sub, but should be okay.

[1]: https://www.wireguard.com/netns/ [2]: https://www.reddit.com/r/WireGuard

That's strange. Who made this sub-reddit? Not me (the creator).

If you have questions, come to #wireguard on Freenode -- https://kiwiirc.com/client/irc.freenode.net/wireguard -- or ask the mailing list https://lists.zx2c4.com/mailman/listinfo/wireguard -- or just ask me here. We're a friendly bunch.

I was going to create it, but saw that someone else just did. You can try asking the person for mod access.

I don't mind getting help on IRC, but often there are problems that many people come across that can be solved by looking at other people's answers. Reddit is great for that, and StackOverflow hates being tech support and closes questions.

I understand if you want people to use the mailing lists for normal tech support, but I wonder if WireGuard's increasing adoption will bring a lot more people than everyone would like there.

Also the average person would find the use of mailing lists daunting, and tend to not love IRC.

I think this[1] said it better than I did.

[1]: https://lists.zx2c4.com/pipermail/wireguard/2017-December/00...

From the WireGuard website[0]:

> WireGuard is not yet complete. You should not rely on this code.

So...should we not rely on this code?

[0] https://www.wireguard.com/#about-the-project

WireGuard is likely going to be merged into Linux kernel[1]. And it's already supported by latest Systemd 237[2].

If you're comfortable with beta/dev software versions, or using ArchLinux/Debian Sid/other distro with the latest software—there's no reason not to rely on WireGuard today. Otherwise, wait until it arrives at your system, being built into the mainline kernel. Also, I would like it to get audited by independent third-party.

[1] https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...

[2] https://www.phoronix.com/scan.php?page=news_item&px=systemd-...

It's reasonable to want to see an audit report but bear in mind:

1. There aren't many audit firms qualified to do that audit, and only a subset of the people at most of the qualified firms are themselves qualified.

2. As a result, none of WireGuard's competition has been meaningfully audited --- all of them have been audited, but the projects are pretty much seen as a well that we can keep going back to for more bugs.

The only exception to that rule is probably OpenSSH, which despite the very complex code base has received pretty significant coverage --- not so much from formal audits (it's had some, but they're the same kind as I just described above) but from a decade of close scrutiny.

Against the desire for an audit, I'd also bank:

- The author is a Linux kernel vuln researcher

- The codebase is deliberately tiny

- The protocol was streamlined specifically to make it possible to implement as simply as it was

> 1. There aren't many audit firms qualified to do that audit, and only a subset of the people at most of the qualified firms are themselves qualified.

I know of one (and we're hosting the dude who wrote the Wireguard go implementation this summer (hey Mathias))

I'd rely on this code before I relied on literally any other VPN codebase. Jason should change the wording here, which I think might be old. Like I said: the protocol just got a set of formal proofs, in addition to the Tamarin prover work Jason did for it.

I should change the wording there indeed. It's a bit drastic.

Just because the protocol has a formal set of proofs, doesn't mean it's production ready. The very fact that the only releases are snapshots and not eligible for CVE's makes me weary of utilizing this in a non-testing environment.

"Not eligible for CVEs" means absolutely nothing.

But how does a set of proofs let you know that it's not going to cause a kernel panic or stop forwarding traffic in edge-cases that aren't well-tested (e.g. lossy and/or high-latency links).

If you have nation-states for enemies, probably not. For most other uses, I'd say give it a try (I am typing this over a Wireguard connection right now, to a Streisand[1] vm at DO).

1: https://github.com/StreisandEffect/streisand

For me, it'd be almost the reverse: state-level adversaries almost certainly have remotes for strongSwan and OpenVPN, but due to its design, it's unlikely that they do for WireGuard.

Good point, though presumably the more it succeeds, the more they'll try...

If you need something very lightweight, to connect sockets on two systems that you control, I've liked spiped.

http://www.tarsnap.com/spiped.html

I've used this for internal ldap, etc. as it's easier than configuring a certificate authority and using TLS.

Very interesting, thanks. A question: how does it run on embedded systems? I was wondering of two very small boards, such as a Nano/Orange PI or similar ones implementing a VPN portable box that can be used both to connect PCs/tablets etc, and/or offering encrypted voip communications: plug one here, the other one there, give each other's ip addresses (using encrypted mail?) and you get a secured pipe to talk or send data through. (I assume the keys are hardcoded) Finding each other IP could be achieved by using an external trusted email server; each box cold employ a button to send a mail with a id:ip pair (or a daemon to do that every time it changes), so that the other box(es) know what is connected from where and keep the connection alive. Doable?

I'm not sure how complicated (or how stupid) this question is, but what's the difference in security between using this versus an SSH tunnel as a proxy?

* The SSH codebase is much, much more complicated than WireGuard's (but it has a very strong track record at this point).

* The underlying SSH protocol dates back into the 1990s, is cryptographically inferior to WireGuard, and does not have an especially strong track record (it's record is similar to that of TLS).

* SSH is opt-in secure for a selection of ports; WireGuard (really, any real VPN) is default secure for all traffic, which is why you use it.

Mostly, though, the reason you'd use a VPN instead of SSH is that VPNs are easier to use. The reason people use SSH instead of VPNs is that most VPNs are hard to set up. That's a big part of what WireGuard fixes.

Another stated reason is that SSH runs on TCP and running TCP apps on a TCP VPN is inefficient. It’s two layers of reliable delivery. It’s better to use UDP in the VPN which is what WireGuard does.

That's not the entire truth. TCP over TCP is not a good mix, but SSH tunnels are different.

SSH tunnels are not VPN tunnels. SSH will act as the endpoint for your TCP application and only tunnel the application payload over SSH (TCP). On the other side a new TCP session will be opened over which that payload is sent. So you never do TCP over TCP.

It's more so a proxy than a tunnel and that avoids the real issue, which is nested congestion control. In addition SSH should also be able to do so with less overhead (in bytes) than a VPN (which need to forward the IP and TCP header intact), but I don't know how well SSH takes advantage of that.

SSH tunneling can outperform OpenVPN running in TCP or UDP mode.

By SSH tunneling, I assume you mean SSH port forwarding (-R/-L). Recent OpenSSH also has Tunnel (-w) which provides an IP-level VPN, in which case it does do TCP over TCP.

Yes, or even SOCKS mode (-D).

Also, sshuttle.

You're right, I'm referring to port forwarding, including the SOCKS interface.

> is cryptographically inferior to WireGuard

Would you say this is true even if you configured openssh to only use the more modern options?

In recent years they've added a chacha20+poly1305 option as well as Curve25519 for key exchange and ed25519 for host and user authentication.

This would seem to bring it up to about an equivalent level cryptogtaphically speaking, in terms of application security, it's definitely more complicated, but it's also one of the most proven pieces of software around and much of that complexity is post-auth. The wireguard site itself pretty clearly states that it hasn't seen much in the way of field testing, though it does look extremely promising. I'll definitely be keeping on eye on it once it's available on more platforms.

Yes. The primitives aren't where protocols tend to go wrong; it's the joinery that's the problem. WireGuard is Noise, which was designed with 20 years of hindsight into what breaks transport protocols.

openssh supports a full pseudo-interface VPN mode, so its no longer limited to select ports.

SSH tunnels only forward a selection of ports.

Usually you'd use SSH in socks mode if emulating VPN behaviour.

This looks awesome

But, unfortunately for me, step 0 for Android is to install a new kernel. Whilst other people have already done the hard work to build kernels for my device (Pixel XL), it would create a significant maintenance headache for me to use one of them. I rely on the device manufacturer's security team to release updates to keep my device safe (particularly as I use mobile banking apps on it). But installing a custom kernel would create a large hole in that, and I can't dedicate sufficient time to reviewing the code patches and building the kernel myself. (Of course, better programmers could do that faster, so the trade-off would be easier.)

Do you happen to know whether WireGuard support will be in the mainline kernel in future?

It seems a bit like a toy project right now.

SSH supports a wider array of features while having effectively the same cost in implementation and use. The only difference is SSH doesn't support dual IP roaming and IP over UDP. Probably didn't need to start a whole new project when they could have added this to SSH, but then crypto nerds couldn't reinvent the wheel (and SSH probably wouldn't accept the patches).

And this baffles me:

"In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer gN65BkIK..., after being decrypted and authenticated, if its source IP is 10.10.10.230, then it's allowed onto the interface; otherwise it's dropped." "system administrators do not need complicated firewall extensions, such as in the case of IPSec, but rather they can simply match on "is it from this IP? on this interface?", and be assured that it is a secure and authentic packet."

If this is on a dedicated tun/tap interface, shouldn't it only be transmitting secure and authentic packets anyway?? Why is IP traffic on an interface just assumed to be authentic information, if for example you aren't sure what put that packet on that interface? And you still need firewalls, so this duplicates configuration. This is basically an .rhosts file for a VPN.

If WireGuard is as easy to set up as SSH, why not use SSH? Because you want a VPN. But if you want a VPN, don't you want VPN features? WireGuard doesn't have VPN features. So you have to get a real VPN, or use SSH.

To put it another way: if you only want roaming IP and public keys, use WireGuard. For any other use case, you're going to get a real VPN or use SSH.

> It seems a bit like a toy project right now.

Certainly not. However, I see how you might think that: the code base and design is deliberately small and readable. It's very far from being a toy, but it aims to be as auditable as a toy would be.

>If this is on a dedicated tun/tap interface, shouldn't it only be transmitting secure and authentic packets anyway?

I was confused about this too, but it made sense when I saw it another way. The network/IP address you put there is also added into the routing table, so it routes traffic to that network via the wireguard interface to the specific endpoint using the key associated with the destination address. While it might seem it doesn't have an important place in the receiving side (which I believe it does, especially when you have multiple hosts sharing a key), I feel it vastly simplifies things. You wouldn't have to worry about where a packet is getting routed if you look at the output of `wg` (if you keep the ACL minimal)

When the config is used with wg-quick(which you can setup as a service with systemd), it adds the address to the routing tables automatically and is less work for you to do.

>If WireGuard is as easy to set up as SSH, why not use SSH

Because SSH can't do many things that WireGuard can, and also speed. Especially since I believe it will get merged into the kernel. AFAIK Greg Kroah-Hartman is all for it[1], so I don't think it'll have any trouble.

Also, I'm interested in what you consider a 'real' VPN is. What do you think this cannot do, compared to say, OpenVPN?

[1]: https://plus.google.com/+gregkroahhartman/posts/jD6N4BzToa3

I will never understand how people go through the trouble of adding cryptographic tunneling components to their network and manage to put "security" at the bottom of their desiderata.

> What do you think this cannot do, compared to say, OpenVPN?

  * Certificate management
  * VLAN assignment
  * LDAP, RADIUS
  * Layer 2 bridging
  * Multi-platform
  * App deployment
  * Host check
  * NACLs
  * DMZ
  * HA
  * Web UI
  * TAP or TUN
  * Stats, Reporting
  * Scripted extensions
  * API

> Greg Kroah-Hartman is all for it[1], so I don't think it'll have any trouble.

This is no guarantee; he was all for AF_DBUS / kdbus and that never happened.

You're right, there is no guarantee. Just that kernel folk aren't entirely opposed to the idea, or I think we'd heard about it by now.

I think what convinced me at least was the argument that larger codebases like IPSec were merged into the kernel, so why would WireGuard have any trouble?

Of course someone upstream might just decide to say no, and we'll have to live with the kernel module which is just as fast especially since it tends to reach line rate.

Oh, definitely.

It looks to me like this is useful for these reasons:

When sending; a single interface may have many peers configured. In that case WG needs to be told which peer to tunnel the packet to or it wouldn't know. It's can be viewed as WG internal routing table, in addition to the ordinary IP routing table.

When receiving; although the packet is proven to be from a configured peer, that peer may have used any IP as a source (referring to the encapsulated traffic). Even if you trust all your peers are who they should be this is a potential security risk. For example a peer may spoof its source IP to imitate another peer. You could patch this hole with iptables rules, but this way is more convenient and has a better chance of being correct since it's simpler to configure.

If you don't want any of this I suppose you could just set up multiple WG interfaces instead, configuring only a single peer for each interface and setting AllowedIPs to 0.0.0.0/0. That should give you the same behavior as a what I think you mean by "real VPN".

Yeah, it also has less space than a Nomad.

Wireguard is blazingly fast - faster than ssh tunnels or other vpn solutions. Because it's tiny, well designed and baked into the kernel, it can really fly.

Do you possibly know how's WireGuard dealing with the Great Firewall of China?

Streisand [1] claims it's effective against the GFW but I've not tried since I only have iOS/Windows devices when there.

[1] https://github.com/StreisandEffect/streisand#more-features

Last time I looked at it, Streisand worked by setting up basically every conceivable remote tunneling service. This is a bad idea; don't do it.

My intended goal was to evade the GFW for a two week work trip, whereafter I was deleting the droplet anyway. I didn't know what protocols would be effective against the GFW and have neither the time nor capacity to set these up manually. Moreover, as the sibling mentioned, you can pick which you install.

I agree that minimising the attack surface is the right course of action but on balance the increased risk of several protocols didn't outweigh the convenience given my purpose and temporary nature.

I fell back to global roaming data if I needed to do anything involving logging in, which I avoided doing unless strictly necessary anyway (e.g.: no banking, etc.).

All this is moot, however, as I was citing it for the point at hand rather than suggesting it over a manually set-up install of Wiregard.

You can pick and choose which VPN daemons get installed during setup time.

From what I've seen on the mailing list, penetrating the GFoC is not a priority. Although people have forked it to try.

> You can only use it on Linux at the moment, but that will change this year.

What's the story there? Is it being ported to some other platforms, and, which ones?

There's a userspace port being actively worked on that should allow you to run wireguard on most platforms (taking a performance hit).

Thanks!

> You can only use it on Linux at the moment, but that will change this year.

What's the ETA on a Windows build? I'd love to try it!

(argh: doesn't contemplate protocols without separate key exchange and data transport; dumb typo)

Can you connect to wireguard from windows?

There is no windows support yet, although you'll definitely know when it arrives.

Eagerly awaiting a cross platform user space version. Not much fun to play with if you use a Mac.

It's happening.

Can it do mesh routing in the same way as tinc? Otherwise it's a poor replacement. It was not immediately evident in the three or so minutes I took to look at the project's web page.

So, I think WireGuard can't, but it can be used as a part of the puzzle. I'm running a mesh using WG as the security layer, and then l2tp to provide a layer 2 on which to run batman-adv. I have a bunch of machines getting DHCP addresses from my home router that way, and (I assume) batman gives me good routing. Of course, cobbling together your own "secure" mesh probably isn't ideal, but it works surprisingly well.

Mind providing more details on your setup here? I tried throwing together an overlay network using OSPF, but never really got it off the ground. I'd love to hear what you've got here!