WireGuard is in net-next - <AUTHOR> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e7096c131e5161fa3b8e52a650d7719d2857adfd <comment><USER2> If anyone wants some more docs and examples for Wireguard usage, I made some here: [https://github.com/pirate/wireguard- docs](https://github.com/pirate/wireguard-docs)

\- how it works internally

\- how the routing works in different topologies

\- a few complex and simple example setups

\- performance expectations

\- security model, key & config distribution

\- setting up wireguard for, or inside of docker

\- GUI tools and other wireguard-related software

\- links to other tutorials, references, guides

<comment><USER3> > _(they do have docs, they 're just hidden away in the manpages)_

I feel old and obsolete.

<comment><USER2> For most users, if it's not Google-able and in nice HTML format it doesn't exist ;)

</comment></comment></comment><comment><USER4> Release announcements are here:

[https://lists.zx2c4.com/pipermail/wireguard/2019-December/00...](https://lists.zx2c4.com/pipermail/wireguard/2019-December/004704.html)

[https://lists.zx2c4.com/pipermail/wireguard/2019-December/00...](https://lists.zx2c4.com/pipermail/wireguard/2019-December/004711.html)

[https://lkml.org/lkml/2019/12/8/257](https://lkml.org/lkml/2019/12/8/257)

<comment><USER5> Congrats, hopefully you'll be able to port it back to Zinc sometime over 2020.

<comment><USER4> We merged "Frankenzinc" for 5.5, some sort of contorted compromise solution. I'll be working on fixing lingering warts during the 5.5 and 5.6 cycles there.

<comment><USER6> Is there a way I can learn more about the compromises made in Frankenzinc / etc without reading LKML? I realize it might not be interesting to document if you hope to clean it up shortly, but I would be curious if you've already got something prepared.

Congrats on getting in for 5.6 and thank you very much for your years of work on this project. It is extremely impressive.

</comment></comment></comment></comment><comment><USER7> If I understand the kernel development process correctly, this means it's on track to land in 5.6 (since 5.4 is the current stable and the merge window for 5.5 is already closed). Correct?

<comment><USER8> yes.

</comment></comment><comment><USER9> This is very welcome news! I had a seamless time using wireguard (via a streisand installation) on my honeymoon in Italy on my phone and more importantly, my wife's phone. It worked seamlessly.

Next up I'd like to see this be an easy config option in Unifi's network managment tools

<comment><USER10> > I had a seamless time using wireguard (via a streisand installation) ...

I've been using Wireguard via [https://github.com/trailofbits/algo](https://github.com/trailofbits/algo) for a while now. Of all of the VPN experiences over the last couple of decades, Wireguard has been light-years ahead of the rest.

First: it's _fast_. If the server is up and you don't have packet loss, you can't tell when it is turned on. For fun, I wrote some trivial automation to automatically and randomly switch between a few wireguard back ends, and I generally can't detect it.

Second: it's easy. For me, an experienced technical user. I don't know enough about the ecosystem to recommend it to less technical people, though given how basically sound it is, I'll be surprised if there aren't really easy and robust front-ends coming up.

<comment><USER11> > Second: it's easy.

To give you some perspective, it's so easy that my four year old knows how to turn it on when we're traveling and she wants to watch PBS Kids.

<comment><USER12> At the terminal with wg-quick, in NetworkManager, on a phone? Just wondering how impressive your kid is.

<comment><USER13> On my Macbook there's a drop-down menu hanging off a menu bar icon. I feel like I could definitely show a little kid how to get themselves on the VPN.

<comment><USER12> I didn't know that. Ubuntu user.

</comment></comment></comment></comment></comment></comment><comment><USER14> I've been using tinc[1] as a way to get a mesh VPN on all my machines that works even if some of them are behind restrictive firewalls. It works really well and I've automated the setup with puppet so I just deploy it automatically any time I bring up a machine. Highly recommended.

Anyone know if there has been any recent work on making wireguard cover this use case? I'm not really worried about security as I treat this overlay network as just as insecure as any other (running ssh over it) and mitigate exploits by running the tinc daemon as a normal user. But it would still be nice to get more performance and security from an in-kernel quality solution like wireguard.

[1] [https://tinc-vpn.org/](https://tinc-vpn.org/)

<comment><USER15> I use zerotier[1] in a similar fashion, and I don't think there's any out of box solution to get wireguard to do "smart" routing (have two hosts on same switch talk directly, still be able to talk to server in a remote datacenter and a client roaming on cellular - with multicast and mDNS/bonjour working seamlessly).

It should be possible to set something up - but I believe you'd need some kind of managing daemon that helped nodes rendevouz and set up routes.

[1] [https://www.zerotier.com](https://www.zerotier.com)

<comment><USER16> I use zerotier in a similar fashion. It has been great.

</comment></comment></comment><comment><USER17> Yes!

Hoping this will will have a pervasive effect like https in the networking world, esp for point to points that glue things together behind the scene. Encrypt all the things!

<comment><USER18> One would wish so!

I recently had to start using PulseSecure. For authentication that damn thing loads a full blown webpage in the background, actually executes the JavaScript therein, fills some forms and submits that via POST. There's a PulseSecure module for openconnect, but it's unable to send the keepalive reauthentications, because it's unable to correctly associate the presented form inputs with the credential fields, so I'd have enter them manually, on each keepalive.

I can only hope that WireGuard is going to drive a solid piece of hardwood through every "commercial grade" VPN appliance out there, and then desintegrates their heads, too, just to be sure.

But given the inertia of big orgs, and the that public and governmental institutions for one reason or another seem to trust "BIG" names with "BIG" (i.e. bloated) products and marketing more, than small, easily auditable stuff, I don't see it happening… sadly.

<comment><USER19> WireGuard is actually pretty awful from an IT security org perspective. There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures. Additionally, there is no concept of two step auth, so if your key is compromised, anyone can connect without anyone knowing about the compromise.

If security companies adopt WireGuard, expect things like PulseSecure to remain as a wrapper around WireGuard. They'll at least standardize on a performant and verifiable VPN solution.

<comment><USER18> There are (at least) two pieces to WireGuard. The wireguard "wire" protocol itself, which is implemented in the kernel. And the authentication and key exchange, that are done by userspace tools.

Right now there exist the "default" tools, which require a manual exchange of key pairs and do only very rudimentary user mapping and authorization.

However: It is perfectly possible to implement much more complex authorization schemes, with all the two step auth, logging, etc. you desire. Somebody has to write the tools for that, still. But the nice thing is, that this is a pretty much independent task, which you could do over any transport/protocol you desire (HTTPS, SSH, custom made, etc.).

An idea I've had for a longer time, but don't have the time to actually invest developing it, is using wireguard for a pure IPv6 mesh VPN.

\- The ULA network part would be the key-id (lower bits) of the mesh public key (i.e. with knowledge of the mesh private key you can join the mesh), used for the mesh setup.

\- The Host part would be each individual host's key-id (again lower bits of the public key).

Since wireguard uses Cryptokey Routing ([https://www.wireguard.com/#cryptokey- routing](https://www.wireguard.com/#cryptokey-routing)) this would directly map.

<comment><USER20> If you haven't already, you should give Yggdrasil ([https://github.com/yggdrasil-network/yggdrasil- go/blob/maste...](https://github.com/yggdrasil-network/yggdrasil- go/blob/master/doc/Whitepaper.md#addressing)) a read.

> IP addresses are derived from cryptographic keys, to reduce the need for > public key infrastructure

</comment></comment></comment></comment></comment><comment><USER21> If you haven't given WireGuard a try yet, now is a good time.

Securely and reliably connecting all my devices with WireGuard was a big reminder to me that there's a much better internet hiding under the hub-and- spoke consumer services model. The internet can be so much more than our phones connecting to large data centers.

<comment><USER22> Can you give us an illuminating example of the fulfillment you've gained from ... ip-over-udp tunneling? It doesn't really sound that revelatory?

<comment><USER23> Not OP. I have a wireguard server setup on my home network. Client installed on my mobile devices. The always on UDP connection seems to use less battery than my previous setup of a TCP VPN. I use this setup to allow my mobile devices to use my home recursive DNS server, which blocks tons of domains for tracking, ads, etc.

</comment></comment></comment><comment><USER24> This is a big step forward!

I'm hoping that the 1.0 release will prompt Netgate to consider inclusion in pfSense.

<comment><USER6> pfSense is a FreeBSD downstream, right? First you'd have to port Wireguard to FreeBSD. Or you could run the userspace server, but expect poor performance.

<comment><USER25> Userspace already has a package [https://www.freshports.org/net/wireguard/](https://www.freshports.org/net/wireguard/)

<comment><USER26> Boringtun (cloudflare's rust implementation of wireguard in userspace) also has work in progress FreeBSD support apparent[1].

[1]: [https://github.com/cloudflare/boringtun/pull/35](https://github.com/cloudflare/boringtun/pull/35)

</comment></comment></comment></comment><comment><USER27> Great experience with WireGuard so far, but does anyone know a simpler way to use it over networks where UDP is blocked (e.g. university Wi-Fi)? I've only found this comment[1].

[1] [https://news.ycombinator.com/item?id=17847008](https://news.ycombinator.com/item?id=17847008)

<comment><USER28> You could try setting up a WireGuard server that listens on udp port 53, which is typically used by DNS and unlikely to be blocked. I haven't used it, but algo recently added a configuration option to do so[1]. Of course WireGuard traffic will look much different than DNS, so they could still block it if they really care to.

[1]: [https://github.com/trailofbits/algo/pull/1594](https://github.com/trailofbits/algo/pull/1594)

<comment><USER29> I would say DNS is more likely to be blocked than other UDP ports, to force the use of a specific DNS server (not uncommon on public networks).

<comment><USER30> either that or port 53 is simply DNATted to an internal DNS server.

Which will make your wireguard VPN unreachable.

</comment></comment></comment></comment><comment><USER31> I'm excited by this, but I'd really love a userspace C or C++ implementation. I know that context switching syscalls take time, but I've enjoyed the trend of the last 10 years towards more userspace services, not less. (I'm particularly thinking of filesystems in userspace and block devices in userspace)

Still, cool. cool, cool cool. I wonder how long until it's in debian.

<comment><USER32> I use BoringTun, it is written in Rust and runs entirely in user space.

<comment><USER31> Cool, thanks, I'll have to check that out!! I've sorta been itching for an excuse to learn rust. Go left me underwhelmed, but that's probably due to me having misplaced expectations. (it's not a better C or C++, it's a better Perl/Python/Shell)

</comment></comment></comment><comment><USER33> Great news. They've been hard at work for a while and it's finally come to fruition. Congrats

<comment><USER7> Well, to be fair, it was already pretty straight-forward to run WireGuard in production (if your distribution of choice has a WireGuard DKMS package). What I'm more excited about is more people building products on top of WireGuard, thus making it more accessible for the non-sysadmins out there.

<comment><USER34> This is what we ([https://tailscale.com](https://tailscale.com)) are working on! WireGuard is incredible, but adding some key management (that integrates with your IAM system) and NAT traversal really helps to round things out. I'd love to hear suggestions and feedback on what we're building.

<comment><USER35> See this comment here: [https://news.ycombinator.com/item?id=21742482](https://news.ycombinator.com/item?id=21742482)

They make a good point about two-factor auth.

</comment></comment></comment></comment><comment><USER36> I'm running wireguard in production on ~50 VMs for over a year (centos). Zero problems yet.

<comment><USER37> So, it scales well with multiple peers? Are all peers aware of each other or are you using some sort of hub and spoke topology?

<comment><USER36> I created a script to distribute the configuration to all relevant VMs.

A network configuration is basically: a port, a name, a set of peers(public key, external ip, wireguard ip). If you want, you can distinguish between master and slave peers (=the slaves do not know/trust each other; master knows everyone)

<comment><USER38> What is the maximum number of peers you have scaled it to per Wireguard server?

<comment><USER36> I don't have "user" peers. I just use it to connect the VMs. So around 50 I guess.

</comment></comment></comment></comment></comment><comment><USER39> Does there exist an effort encapsulate WireGuard in HTTP/3 or, when UDP is blocked, in HTTP/2?

</comment><comment><USER40> This will mean a lot for the future of WireGuard and VPNs if it catches Ubuntu 20.04

<comment><USER41> There is almost no way that occurs. 5.6 and the compatible wireguard-tools won't be out before the 20.04 freezes.

<comment><USER42> But its point updates will provide the option to update the kernel. [https://wiki.ubuntu.com/Kernel/LTSEnablementStack](https://wiki.ubuntu.com/Kernel/LTSEnablementStack)

</comment></comment></comment><comment><USER43> Does this mean WireGuard will be moving to stable?

My VPN provider has said they won't support WireGuard until it hits 1.0

<comment><USER44> Get a better VPN provider. Or better yet, run your own.

<comment><USER45> I don't think it's fair to say "better" here. Waiting for stable software releases is a perfectly valid approach. It may not be _your_ approach, which is also fine, but neither approach is better than the other.

<comment><USER46> The end goal here is security. Wireguard has an __excellent __track record, having a tiny, simple and clean codebase and having been reviewed by many skilled eyes.

Most of other solutions don't come close to that.

<comment> yjftsjthsd-h I actually do trust WG here, but it is explicitly pre-release software and I would really struggle to fault a provider from avoiding pre-release software. I mean, the WG main page still contains the following ([https://www.wireguard.com/](https://www.wireguard.com/)):

> WireGuard is currently working toward a stable 1.0 release. Current > snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these > should not be considered real releases and they may contain security quirks > (which would not be eligible for CVEs, since this is pre-release snapshot > software). This text will be removed after a thorough audit.

</comment></comment></comment></comment></comment><comment><USER47> What is the timeline for making wireguard viable for commerical VPNs?

"""

There's a few fundamental issues with wireguard that make it relatively unsuitable for commercial VPNs with many customers.

For a start, if you want to offer customers multiple concurrent devices, each device needs it's own key, and all keys for all customers' devices need to be loaded into kernel memory and cross checked against every packet received, which as you might imagine gets incredibly unwieldy and could savagely impact the performance of PIA servers.

When wireguard has the ability to hook a userspace daemon when it receives a valid-looking packet with unrecognised encryption, it'll be a lot closer to usable in commercial contexts, as the daemon could poke a database or cache to load the required keys on demand

"""

[https://www.reddit.com/r/PrivateInternetAccess/comments/d1bl...](https://www.reddit.com/r/PrivateInternetAccess/comments/d1blo2/wireguard_update/ezk41ix/)

<comment><USER48> Mullvad VPN already supports wireguard fyi

</comment></comment><comment><USER49> I recently started using OpenVPN (My router comes with it pre-installed).

Does anyone know how this compares with OpenVPN? Is is worth setting up my own wiregaurd machine?

<comment><USER13> WireGuard is much faster than OpenVPN, much simpler to set up than OpenVPN (except for having to set up IP addresses it's approximately as easy to get working as SSH), and it's much, much more secure than OpenVPN.

<comment><USER50> > WireGuard is much faster than OpenVPN

Not relevant for most home internet connections

> much simpler to set up than OpenVPN

+1

> and it's much, much more secure than OpenVPN.

That's uselessly vague. Do you mean the protocol, the implementation approach, the underlying crypto, or what?

<comment><USER51> >> WireGuard is much faster than OpenVPN

> Not relevant for most home internet connections

Why it is not relevant?

<comment><USER15> I'd say it is. While I'm handwaving based on what I've read - wg should be better for voice and video chat, due to being low-overhead udp - which should translate to lower latency.

</comment></comment></comment></comment></comment><comment><USER52> Sorry for off topic, but is there any way, how to setup wireguard (or any VPN) to be used for just single app (lets say Firefox) and not system wide on macOS? Something similar to [https://github.com/darkk/redsocks](https://github.com/darkk/redsocks) with ssh and setting up proxy in Firefox?

<comment><USER53> Looks like this might help you: [https://superuser.com/a/241200](https://superuser.com/a/241200)

Redsocks is a transparent proxy, though. That'll redirect system-wide. I think you're thinking of your basic socks proxy - `ssh -D`.

</comment></comment><comment><USER54> This is great news! I've been a wg user on an EdgeRouter for a little over a year now, and the experience is always just so _seamless_. The architecture of this thing's a beaut.

That news aside, this is an outstanding commit message. The kernel never disappoints on those.

</comment><comment><USER55> what does this mean for users of wireguard? An explanation for linux noobs?

<comment><USER4> It means that WireGuard will be included in your distro's kernel, which will ease installation. Before, you had to do some ugly kernel module compilation steps, usually using dkms, which was prone to failure and was a general nightmare to deal with. Moving forward, you'll just run "apt install wireguard-tools", and you'll be all set.

To temper expectations, though, this is slated for 5.6, which won't be released for another ~120 days or so. After that point it will trickle down to distros. So there's some time yet before users start seeing the direct consequences of this exciting announcement, but it'll be coming.

<comment><USER56> It works mostly without problems, but be careful relying on it as a sole means of accessing your server. I've locked myself out (luckily it was just a test server) by closing SSH port on public IP and allowing it only on Wireguard interface. One day I updated the kernel, dev headers got mixed up and my wg0 interface didn't come up after reboot.

<comment><USER57> The issue you described (DKMS wasn't able to build the module for the new version of the kernel) will go away once Wireguard is in the kernel "properly" (which is what this announcement is about)

</comment></comment></comment></comment><comment><USER58> Is there a simple way to tunnel specific apps only through wireguard?

<comment><USER59> WG exposes a point to point / l3 network interface like any other to userspace, so an answer would not be specific to wireguard but about networking and routing in general.

Network Namespaces and VRFs are the correct way to approach this I think: [https://www.kernel.org/doc/Documentation/networking/vrf.txt](https://www.kernel.org/doc/Documentation/networking/vrf.txt)

</comment></comment><comment><USER60> Awesome development!

</comment><comment><USER61> When will we see support for this built into iOS?

<comment><USER62> Whenever so many networks are deployed with this that Apple becomes interested in supporting it for their users. Being in the kernel should help with this, but obviously there's no actual timeline. Maybe never

</comment></comment><comment><USER63> How it fares against IPSec?

<comment><USER64> way simpler (and thus, I would argue, way more secure). way faster.

On the other hand: No built-in client in any of the mobile OSes, so a third- party client install is required.

<comment><USER65> I like my always-on IPsec tunnel on android. Never really understood this entire wireguard hype. Probably because VPN just got a bit easier for some people..?

<comment><USER66> One of the big things is that it uses more common UDP rather than a completely new IP protocol like IPsec wants. This makes it play much nicer with a lot of networks that have unusual setups or restrictions that otherwise block IPsec. OpenVPN can also accomplish that, but it's got a more complicated setup than WireGuard since it needs a full TLS stack and certificates.

</comment></comment></comment></comment><comment><USER67> Next stop: NT and XNU?

</comment><comment><USER68> About time</comment>