WireGuard is submitted for Linux kernel inclusion | Hacker News Reader

WireGuard is submitted for Linux kernel inclusion

marc.info

331 pointsdochtman181 comments

I started using Wireguard two days ago to access my home LAN and love it, I can access everything with one command, as if I'm home. The only problem I have with it is the complete lack of documentation. The tutorial refers to a configuration file, but nowhere on the site does it tell you how to write one.

It also took me days to set up what I think is a common use case, logging in to a server/router at home and accessing the rest of the computers in the LAN. I I couldn't find how to forward/masquerade traffic, and it took some help from the good people at #linux to get it set up. I think it would be a great help if they had a configuration file on their site detailing how to set that up.

Lacking that, I'll write an article with my config so the info is at least out there, but I believe Wireguard is held back by its lack of documentation.

I've been using wg for over a year now and never had any difficulty finding documentation.

`man wg` works just fine as does `man wg-quick`

https://www.wireguard.com/quickstart/ also shows you how to make a config file

The problem is that a regular user [some of them] can follow documentation, set up a server and a client, use wg to connect them and may be even ping the connection. That's it, congratulations.

How is this connection can be used? Which IPs should be used to establish a useful connection? How can a user see their LAN resources through it? How can a user route his web browsing through this connection (here we at least have wg-quick)? And so on.

This information is lacking, and WG documentation is not the sole offender.

That's the thing with a vpn - it is just a single component of a fully setup network. The vpn documentation generally just covers how to setup the vpn connection. The routing and rest of the network setup, as per the questions you are asking, generally falls out of its domain and into general networks.. which is quite a huge area!

this is a very good point.

Also, from a network design perspective, the difference between a tunnel, GRE interface or VPN is nonexistant. They all accomplish the same objective with different technical methods.

This is certainly not true. Tunneling and VPN protocols have distinct characteristics and capabilities which greatly affect network design. The reason for this is that they are not all designed to accomplish the same objective.

Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it, and nobody can understand this mode anyways. Nobody needs ECB or 3DES or any of the other zillions of IPsec methods. The great thing about WireGuard is that it removes all the crap and has one mode: Fast and Secure.

The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out.

From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer.

On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed.

‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.

That's an OK point, but when half the comments on this thread are "I had to mess around for days to work out the config" then surely some common use cases can be covered by general FAQ's, like every other VPN/networking technology provides?

After that point it works exactly like any other network connection. I'm not sure what you feel needs to be documented here.

Common use cases. People will hear about WireGuard the new OpenVPN, and they'll want to "just set up a quick VPN" with it, to "hide their IP address" or whatever.

Of course it's up to WG to decide if they want to deal with this kind of community education/outreach.

FWIW Openvpn did just fine without doing that.

I agree. I've been using Wireguard for about 6 months now. The quick start is great for getting a quick overview but it doesn't really document properly how a configuration file should be made.

There is no real detail about how a wg-quick config differs from a wg one, and they're not compatible; it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg.

I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. It's not a big deal, but it messes with the usual workflow of editing the config file of a service (you don't want to down it while updating your config, which could take time).

otherwise, wg has been great, it is generally quite reliable on Android but I'd like to see an easier way of doing the exclusions, inverse CIDRs are not my forte.

> it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg.

Really? I didn't even know that, thanks.

> if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config

Ouch. Yeah, these things definitely need to be documented, I had no idea about this either. I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc.

> I would also like to see an easier way to configure authentications

Agreed. I like the way home assistant does it with a secrets.yml and you refer to your secrets by !secret <name of secret>

> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc.

The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that calls the lower level "wg" command instead of "wg-quick". Alternatively, you can write a script that generates a wg-quick configuration file.

Exactly this. WireGuard and wg(8) are meant as building blocks. For example, the wg-quick(8) tool is a simple bash script I built out of wg(8) and ip(8) that mostly works for my use cases and those of some other folks. But if you want something more complicated, then it's supposed to be easy to build that out of the building blocks presented.

What I am wondering is why they chose 25519.

It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection.

https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...

Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm.

NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".

The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update."

ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable.

On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems.

Android, however, cannot do that.

p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway.

"In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."

If you believe that demanding agility is "far from unreasonable" I strongly recommend taking that line rather than insisting people should use relatively untried shiny new toys out of fear of a monster that may not actually be under their beds.

I don't know that WireGuard's author will agree, but you at least have a coherent argument that makes sense. Replacing 25519 with NTRU because you're terrified of a bogeyman (in the form of Quantum Computers able to run an algorithm that solves the appropriate hard problem) doesn't make sense.

I never said "instead of," although I can see in hindsight why it might be seen that way. I should have been more clear.

Wireguard could have used P521 and AES-GCM with similar security, but it would be slower and equally vulnerable.

You can use WireGuard with rather expensive but conservative PQ primitives like Classic McEliece using the PSK feature of WireGuard, giving you hybrid PQ secrecy. The PSK feature was explicitly designed for this. The idea is that first you create a normal WireGuard tunnel. Then _through it_, so that it's authenticated, maybe even over boring old TCP, you negotiate your potpourri of experimental post quantum exchanges, maybe several of them if you don't want to trust a first round NIST submission right off the bat. Then you put the resultant key from this into WireGuard's PSK slot, and voila, now you have post quantum forward secrecy.

The Noise protocol framework (on which WireGuard is based) is now looking into doing PQ authentication, so that will be interesting. But until we actually have a clue which PQ primitives to use and have spent some time working out PQ handshakes, I think it's best to keep this all separate and ad-hoc, making it possible with the simple PSK feature.

Does this hold up though?

The PQ algorithms are only adding anything in scenarios where real adversaries can run quantum algorithms to break public key crypto. In those scenarios you don't have worthwhile authentication in WireGuard itself because your adversary broke that with their quantum computer.

The claim of "forward secrecy" seems particularly dubious when resorting to PSKs. Forward secrecy relies upon keys being ephemeral. The PSKs a TLS 1.3 web server remembers for minutes or hours automatically to support fast session resumption maybe count; some semi-detached manual PQ key agreement procedure sounds like it'll get done once and then left in place, no forward secrecy there.

> I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. It's not a big deal, but it messes with the usual workflow of editing the config file of a service (you don't want to down it while updating your config, which could take time).

`down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it.

> I'd like to see an easier way of doing the exclusions, inverse CIDRs are not my forte

WireGuard uses the standard Linux routing infrastructure. wg-quick uses the powerful Linux policy routing functions along with the suppress_prefixlength policy routing rule in order to use your main routing table for exclusions. Therefore, the command to exclude an IP is simply "ip route add 10.0.1.0/24 via 10.0.0.1 dev eth0". Obviously you should replace the example subnets and interface, and this is not permanent. The beauty of wg-quick is that you don't need to add this rule every time you bring up your VPN, but can instead add it as a temporarily redundant static route.

> `down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it.

Nope, it's not in my config file. I didn't even know the option existed until you mentioned it, again, nothing on the Quick Start about it.

> WireGuard uses the standard Linux routing infrastructure...

I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these".

What's the inverse of 192.168.0.0/16? I have no idea without looking it up.

> I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these".

The Android app now has a little checkbox to toggle a common set complement operation ("Exclude private IPs"). If you want to do something wild and include or exclude very particular ranges, then you can compute that yourself and put it in there, since ostensibly you have a very particular networking idea in mind.

No. Only if you've explicitly chosen to add "SaveConfig = true" to the config file, which by default is not there.

I actually gave up after trying for a while. They mention an "easy" way to do traditional VPN usage, but it never worked, and various blogs have differing opinions on how to properly do that.

I wish there was better hands-on documentation for WG, but I guess it really is an addition to iptables and thus restricted to people versed in that area. Which I am not.

I do intend to try again though.

Here you go, plug and play:

https://www.pastery.net/gvfyub+hacbne/#gvfyub

Use with `wg-quick up <configfile.conf>` and you're done. I don't know why this isn't in the documentation, it strikes me as what 99% of users want, and the other 1% knows how to do whatever they need.

Adding the masquerade rules and forward rules as an example in the wg-quick(8) man page sounds like a good idea. Want to send a patch to the mailing list?

Err, sure, I'll have to figure out how to do that first, though. I'm assuming I can't make a pull request somewhere?

It's even easier than that:

    $ git commit -s -m "man: add example for bla bla bla"
    $ git send-email --to=wireguard@lists.zx2c4.com HEAD~

And that's it!

This is also, by the way, how submissions to the kernel itself work, so if you're ever interested in doing that and want to get used to the process in a smaller environment, this could be a place to learn.

Oh huh, cool, I'll get to that shortly, thanks!

Thank you, I will try that

can wireguard be run from different namespaces so that only certain applications are tunneled through the wg0 interface?

I assume this is what you want? https://wiki.archlinux.org/index.php/WireGuard#Setup_a_VPN_s...

Yep, although the outbound iptables ALLOW is missing, which won't work with default DENY. Check my config in a sibling comment for the right one.

Added the line to the Arch Wiki entry. Thanks :)

We have a guide [1] up on using Wireguard and go into some detail on the configuration and how it works. But we mainly use it to build container networks.

[1] https://www.flockport.com/guides/build-wireguard-networks.ht...

The lack of a forum for discussion is also a problem. (Or maybe I'm just spoiled by github.)

There is one feature that I want that should be trivial to add that I don't know how to voice it. There is an AllowIPs config directive, but not an ExcludeIPs directive.

There's the mailing list: https://lists.zx2c4.com/mailman/listinfo/wireguard

And there's the IRC channel: #wireguard on Freenode

And in both of these there is quite a bit of discussion.

> There is an AllowIPs config directive, but not an ExcludeIPs directive.

I think you're mostly just tripped up by the naming here. Everything is excluded by default. Add things to AllowedIPs to have packets sent to those IP get encrypted for that peer.

Like I said, spoiled by github. I need to get back into IRC. Never felt comfortable on mailing lists.

I want everything included except my local LAN. I can probably do something stupid to generate a config that works (i.e., such that I manually include 0.0.0.0/8, 1.0.0.0/8, ... etc excluding 192.168.0.0/16) or do something smart outside of wg/wg-quick, but I lack the expertise.

> but I believe Wireguard is held back by its lack of documentation.

Indeed having good documentation is super important. I'm not so arrogant as to proclaim, "I don't have time to write docs! Understand it yourself!", but I am stretched super thin, and I suspect that often times documentation from somebody who _isn't_ the creator winds up being a bit better, because exterior perspectives are useful. So it's my hope that somebody can chip in and help out writing tutorials and docs and walkthroughs and whatnot. We really do need it.

From the sound of your message, though, I wonder if maybe you haven't found the man pages (primary documentation source):

https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8

https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick...

I had, indeed, not found the man pages, thank you. I also intend to write up how to deploy Wireguard with a simple "access the home LAN from the outside" configuration in the next few days, which will hopefully be useful to people.

Please do! And can you come back to this thread and let us know?

I'll make a new post here, I'm guessing a few people will want to know.

Yes, we'd all love to see it when you're done.

If you don't want to wait, I posted the configuration in a sibling comment. It's pretty much that, along with some more details on how to add it and run it.

If you want to document "How I access my home network remotely" but you're really spending a few paragraphs repeating the wireguard docs before moving on to other things like your choice of IPs, your logging setup, how to retrieve mail, how to ssh places, and stuff like that, please realize that none of that other stuff has anything to do with wireguard. You could just as easily be documenting those things with an OpenVPN or IPsec vpn or even an unencrypted tunnel. That's why those things are not in the wireguard docs.

If there's something that involves wireguard itself that's missing from or unclear in the docs, could you please clarify?

> none of that other stuff has anything to do with wireguard

Sure, none of it is specific to Wireguard, but my personal use case was "hey, Wireguard looks cool, maybe I could use it to access my home LAN when I'm away. Hmm, how do I talk to the other machines from the VPN server?".

It's like saying "if you want to bake a cake, none of the baking has anything to do with our flour". You're technically right, but it'll benefit you to put a recipe on the box.

"How do I talk to the other machines from the vpn server"

The same way you would if everything on your side of the VPN tunnel was on the other side of the VPN tunnel, there was no VPN, and the VPN server was just a router joining the two subnets.

"I don't know how to do that, oh well, too bad, Wireguard would have been nice"

I've been using Wireguard on both my laptop and my Android phone for about two months. I've been using the wg-quick systemd units, and everything has worked amazingly well. The only downside I've notice is slightly increased battery consumption on my phone, but that's to be expected (it uses approximately 5% of the battery per day).

I use dnsmasq to resolve DNS queries on the server side. Dnsmasq's configuration file includes entries to block connections to ad networks, based on Steven Black's host file [0]. It's a great to achieve ad blocking on Android, since Google has banned ad blockers from the Play Store.

Jason Donenfeld, Wireguard's author, has a Patreon page: https://www.patreon.com/zx2c4

[0] https://github.com/StevenBlack/hosts

> it uses approximately 5% of the battery per day

OpenVPN uses about 20% of mine, so I guess it really is a step forward.

Also, for your DNS lying file, you might be interested in: https://gitlab.com/moviuro/moviuro.bin/blob/master/lie-to-me (which sources multiple domain lists)

Steven Black's list sources from multiple lists as well. Checking out your lie-to-me project, there is actually a lot of overlap between what Steven is already pulling in and what you are getting. Looks like one of your sources 'palevotracker.abuse.ch' is discontinued and responds with a 500.

You can install pretty easy the F-Droid repository / store and download DNS66 from there. ( FOSS Ad-Blocking via DNS ).

I was using DNS66, much is user friendly and very effective. Unfortunately, it is implemented as a VPN, and Android will allow one VPN to be active at a time.

>slightly increased battery consumption on my phone, but that's to be expected (it uses approximately 5% of the battery per day).

Are you using the user-space implementation or the kernel module? I'm curious as to the difference in battery consumption.

I'm using the user space implementation.

> The only downside I've notice is slightly increased battery consumption on my phone, but that's to be expected (it uses approximately 5% of the battery per day).

I believe that Android does not accurately represent the battery usage of VPN apps. It seems to count all the radio (i.e. mobile and Wi-Fi) usage against the VPN app, but actually the traffic was sent only because some other app requested its transmission. WireGuard itself uses zero battery if no network traffic is being passed and the NAT keepalive mode is off. (at least this is true in the abstract, it might run occasional timers to update system information as Android requires)

What's the benefit of running this on your Android phone? Are you connecting back to a home/cloud server and accessing the Internet through that?

> The only downside I've notice is slightly increased battery consumption on my phone, but that's to be expected (it uses approximately 5% of the battery per day).

Note that if you run a phone that has the WireGuard kernel module (rather than the userspace implementation), battery usage winds up being basically nil in my tests.

As for the userspace fallback, we expect performance (and hence battery life) to increase on that once these are merged:

https://go-review.googlesource.com/c/crypto/+/107628 https://go-review.googlesource.com/c/crypto/+/105896

>Note that if you run a phone that has the WireGuard kernel module

I wonder if LineageOS plans to include this module..

I've been working on it with them actually. We'll see where that goes.

Wow one of my favorite FLOSS developers replied to me! Hopefully they (lineageos) adopt it, it would be a HUGE improvement over the native android VPN options and openvpn.

Would adding such a module break SafetyNet? Can you even add modules to the Android ROM / Kernel and then relocking bootloader and disabling root access?

Not everyone cares about 'safetynet', and LineageOS does not support secureboot-style locked bootloader booting.

You can literally build the ROM with any kernel modules you want, provided the module has been backported to the almost-guaranteed ancient kernel your device needs for initializing/using its hardware.

I can't wait until pfSense supports it. That'll be the moment I'll set the OpenVPN config on fire, because honestly, OpenVPN configs are magic and if it's not generated by some UI wizard, it's probably broken in some scenario. And even if you do the wizard, it's probably broken.

Atm I have that funny bug where my laptop drops connection after 3 seconds but my desktop does fine. With the same configuration! Thank OVPN for that annoyance!

> Thank OVPN for that annoyance!

Certainly, you reported that issue through proper channels, and attached detailled information regarding your hardware, software, as well as packet logs?

It's a configuration error, not a OVPN bug itself. OVPN's configs are just so obfuscated that it's difficult to find the error.

OpenVPN is really not that hard to configure, and I'm pretty darn sure my config isnt broken (it's been audited at least twice.)

OpenVPN is quite difficult to configure IMO, 90% of the time I spend setting up an openvpn install is spend figuring out the routes that make everything go and have both server and client set them up properly.

Yeah, I'm with you. Saying a software package with over 300 different options and keeps default defaults that were depreciated years ago is easy to configure really is a stretch. Combine that with it being _very_ finicky about what x509 certs it accepts, requiring a directory of configuration files to set up the network and giving you raw openssl error messages, and I'd say it one of the harder things to I had to configure. IPSec is easier to setup, and by any measure IPSec isn't easy.

OpenVPN still wins over IPSec because it works over so many different transports, and there is only one implementation so IPSec's interoperability issues vanish. It maintains that advantage over WireGuard too.

I've been using WireGuard on my router for the last 6 months, and it's fantastic. I get the full speed of my line through it, when OpenVPN was only giving me 20%. Because of the great plugin they have for Vyatta I'm going to be looking at using it for some stuff at work now too.

Only 20%? How did you test this? I'm currently using OpenVPN but am looking at Wireguard.

By running speed tests through both tunnels. I was getting ~7Mbps over OpenVPN and get ~35Mbps over WireGuard to the same server :)

I believe the speed difference is primarily related to the processing power of my router. WireGuard is seemingly much quicker because it's less intensive on the router.

How did you install it on your router? I'm assuming this isn't a throwaway $30 consumer router?

I use it on an EdgeRouter Lite 3 which is about $99. See:

https://github.com/Lochnair/vyatta-wireguard

https://community.ubnt.com/t5/EdgeRouter/Release-WireGuard-f... (discussion)

The EdgeRouter Lite 3 also happens to be one of the few generally available Mips64 platforms (Cavium OCTEON CN5020). Actually I have just ordered its big brother EdgeRouter Lite 4. It costs double as much, but it also packs a quad-core 1GHz OCTEON CN7130.

I'm running an EdgeRouter X myself, which is actually not too far off your price at ~£50. Fantastic little router, great for home use.

Great news. I started using Wireguard instead of OpenVPN and won't look back. Actually it was easy to set up even with DKMS kernel modules but having it in mainline will be great.

Do you only use it to connect remotely into your home network or are there VPN Services for wireguard available?

I use the mullvad VPN service for wireguard. They currently have 44 wireguard servers active around the world.

I second this. I remember reading an interview with one of the mullvad staff saying "y dream openVPN config would be [insert more or less verbatim the wireguard spec], but due to the nature of openVPN that either won't happen or will take a long time". They were quick at adopting wireguard :)

They are very knowledgeable and spend a lot of effort in securing their VPN. I contacted them about what I thought was a bug, and got a very thorough answer about why mullvad behaved like that, what kind of threat it mitigated, and how I got the behaviour I wanted together with things I could do to keep safe (which was to update the kernel). Within 6 hours.

I am a very happy customer.

Azire gives free WG access while in beta

I second Azirevpn.com! Great speeds

Can you explain what makes it better than venerable old OpenVPN?

Mostly speed, a more minimal configuration syntax, more modern crypto.

OpenVPN works fine, is quite portable and runs in user space. It's quite a lot slower, but is well-tested and can be managed with a Certificate Authority in organisation where that's desired.

I presume speed on linux? Otherwise doesn't wireguard suffer from the same peformance drawback than OpenVPN on windows (running in user mode)?

OpenVPN is quite configurable, not as much as IPsec, but still a lot, and (from what I hear) has quite a bit of code bloat. I believe that userspace WireGuard has better performance than OpenVPN.

My understanding (and experience) is that OpenVPN on windows is structurally capped at about 5-10 MB/s. I was curious of how that compares to WireGuard.

Performance issues with OpenVPN on Windows arise out of the inefficiencies of the TUN/TAP driver, not the OpenVPN software itself.

I am sure that's true, but unless there is an alternative driver I am not sure why that makes a difference.

Thomas Ptacek does it better than me: https://news.ycombinator.com/item?id=14599834

They are trying to get a completely new crypto interface into the kernel, and they are posting the patches to linux-netdev mailing list.

This is not gonna fly.

They were asked to do that by the kernel maintainers.

> This is not gonna fly

This response on the 'linux-crypto' list seems to agree: https://marc.info/?l=linux-crypto-vger&m=153310819905231

"Not gonna fly" in the sense that this maintainer doesn't want the patch as-is, but they lay out a clear set of steps the WireGuard authors can take to get it in shape for an eventual commit.

You may want to check out the very nice presentation on WireGuard at Kernel Recipes: https://www.youtube.com/watch?v=9Rk4doELmwM

There are several other (and newer) presentations here as well: https://www.wireguard.com/presentations/

is there a presentation explaining some of the networking setup you need to understand in order to get wireguard working properly? For example, a common openVPN complaint is that the default setup hijacks all your network traffic -- and on ubuntu since 16.04 the default config gives a dns leak (they changed to systemd-resolved)

The biggest issue we’ve encountered with WireGuard is that it doesn’t (yet?) support GRO, which means the kernel doesn’t combine multiple sequential TCP frames inside the tunnel into one before presenting it to a program. This increases RTT by a significant amount.

That doesn't sound right, GRO is a performance optimization but shouldn't be required for interactive response.

Sounds like what you need is TCP_NODELAY?

See above. ;)

Actually, I turned on inner-packet GRO a few weeks ago with this one-line change, resulting in surprisingly massive performance boosts for TCP:

https://git.zx2c4.com/WireGuard/commit/?id=95951af7249912a43...

Woohoo!

Well, that’s amazing. We built a whole massively scalable CDN on top of WireGuard then hit that issue and had to shelve like 3 months of work.

Thanks for that!

There's no next message in this thread? Huh?

This mail archive works:

https://www.spinics.net/lists/netdev/msg516566.html

[0/3] https://marc.info/?l=linux-netdev&m=153306429108040&w=2

[1/3] https://marc.info/?l=linux-netdev&m=153306429908043&w=2

[2/3] https://marc.info/?l=linux-netdev&m=153306437408074&w=2

[3/3] https://marc.info/?l=linux-netdev&m=153306440208084&w=2

I had the pleasure to meet Jason at 34C3 past winter, he's incredibly capable and I really hope this goes through somehow.

After using WireGuard you really don't want to go back to the horrible IPSec/OpenVPN solutions.

IPSec IKEv2 is actually pretty good

It's pretty good if you have two devices that support the same proposed ciphers and don't implement other non-standard behaviour (I'm looking at you, Juniper). It's eye-bleed otherwise.

Why Juniper? I would not trust proprietary stuff over Strongswan, even if it worked correctly :) And Apple IKEv2 native clients work fine too.

strongSwan is literally 2 orders of magnitude more code than WireGuard, and for all that you get 1990s cryptography. Why would you trust it at all?

Trust must be earned. In crypto it is mostly by time, since it takes quite a few research papers to arrive at scientific consensus.

Codebase size is good argument, but consider how many optional components are in Strongswan, tens of RFCs supported. You can build it smaller omitting it in make.

And what is the size of OpenBSD iked?

Try again. strongSwan hasn't earned trust. It's had something like 30 vulnerabilities over the last 10 years, including 6 code execution vulnerabilities. And strongSwan is considered one of the better IPSEC implementations! What do I care whether it bought support for "tens of RFCs" with those vulnerabilities? I don't want "tens of RFCs". I want a working VPN and no vulnerabilities.

Bugs scale with C codebase size, full stop.

Is it?

You are holding the rope you're hanging on. Your choice :)

I can foresee a long, long and mostly pointless discussion/argument about code line length.

Especially with Linus being the one who dislikes long lines. I'm wondering if there has been any precedent of a non-trivial patch that was 80+

Nah, if people freak out I'll just change it. I _prefer_ my insanely long lines, and if Dave & co are alright with my preference, great, but if not, Linux is a big project with many people, and I'm happy to accommodate for different preferences.

I'd kind of like to see a screen shot of this

Why does this need to be included in the kernel directly and not just as a loadable module?

When the API it relies on changes, the person doing the change will fix WG rather than the WG maintainers. Also it enables you to update the kernel without having to hunt for the matching release of WG separately.

Like most device drivers it can be included in the mainline kernel but compile as a module.

On a slight tangent, I wonder how realistic it would be to implement Wireguard as an eBPF program.

There are three related decisions in how software can be constructed in relation to linux, and it sounds like you might be confusing them a bit. They are: user space vs kernel space, base kernel vs kernel module, in tree vs out of tree.

User space vs kernel space is the biggest decision and has a huge impact on nearly every aspect of the software. Wireguard has both user space and kernel space implementations. I'll link you to the Wireguard author's explanation as to why he chose to do a kernel space implementation: https://news.ycombinator.com/item?id=11994544

Base kernel vs kernel module is usually an easy one: almost everything that CAN go in a kernel module SHOULD go in a kernel module. Since modules can be loaded only when needed, it avoids using everyone's computing resources on features that not everyone might want. Wireguard is a kernel module.

In tree vs out of tree means whether you commit your code into the main linux source tree, or whether you distribute it outside of the linux project. Linux software development practices make it pretty annoying to distribute kernel software out of tree, even if it's a module. Basically, linux doesn't maintain stable APIs or ABIs in kernel space, so if you distribute in binary form you'll need to distribute different versions for every kernel version, and if you distribute in source form, your users will need to recompile whenever they update their kernel, which is pretty often if they're keeping up with security updates. DKMS helps with the recompilation process, but it's still pretty annoying for users. This announcement is about the proposed transition of the wireguard kernel module from out of tree to in tree.

> Why does this need to be included in the kernel directly and not just as a loadable module?

From the patch:

    +       tristate "WireGuard secure network tunnel"

This means that it can be a built-in, a loadable module, or not included at all, depending on what you select when building.

How would this compare to ZeroTier? (zerotier.com)

It seems that someone asks about ZeroTier on every thread about WireGuard. According to tptacek:

https://news.ycombinator.com/item?id=13601928

ZeroTier is cryptographically inferior to Wireguard, but also isn't really a VPN: it has centralized configuration and rendezvous. If you're running VPNs to get the US Netflix from your UK vacation, this is probably fine. If your VPN is how remote employees access your prod network, it is way less fine.

I think it's a bit unfair to judge ZeroTier in comparison to VPNs, because that's not strictly speaking what it's trying to be. I like overlay networks!

And here's some info from the ZeroTier developer:

https://news.ycombinator.com/item?id=11996687

You can think of ZeroTier as a virtual smart switch built on a P2P network

...

WireGuard does have some things in common with ZeroTier, such as the use of cryptography to identify endpoints and eliminate the hard-coding of endpoint addresses. ... I really like the WireGuard design in general and I think it has a somewhat different use case from ZeroTier, namely fast long-lived provisioned links across WANs and insecure LANs. You could use ZT for that but this being in-kernel makes it likely faster.

The only downside with WireGuard for me is that it only works over UDP. I am in a situation where I only have two or three TCP ports available for a VPN, so I won't be moving off OpenVPN anytime soon.

I was following WG development for a while now and I think it's a great project, but sadly not for my particular use case.

You really need to get that fixed, as you are severely handicapped without UDP. Apart from existing UDP usecases, the general progression is away from TCP and onto UDP. QUIC is an example of such progression.

The reason Wireguard doesn't do TCP is that it is only a handicap for tunneling, and impedes Wireguard's connectionless features. Maybe Wireguard could add it as a compat option, but the experience will be worse than over UDP.

In the meantime, making a hacky UDP<->TCP<->UDP proxy isn't very hard. Less than 100 lines of Go. It'll handicap Wireguard quite a bit (even more than a built-in TCP compat feature), but it'll probably still be faster than OpenVPN.

Well, this is a network where only SSH and one or two more TCP ports are open, and it's not something I can "get fixed".

Still, I do not have any practical reason for switching to Wireguard, as I do not really see any reduced speed - it is possible that the bandwidth limitation of this network's internet connection is low enough for that to be the bottleneck, instead of OpenVPN. :)

> Well, this is a network where only SSH and one or two more TCP ports are open, and it's not something I can "get fixed".

Are the other TCP ports, as well as UDP blocked by a force of nature? :)

> Still, I do not have any practical reason for switching to Wireguard, as I do not really see any reduced speed - it is possible that the bandwidth limitation of this network's internet connection is low enough for that to be the bottleneck, instead of OpenVPN. :)

At lower throughput networks, you don't need wireguard. It'll still mean fewer CPU resources used, much simpler configuration, and things OpenVPN and the likes just cannot do (such as maintain the connection despite both ends changing IP, as long as it doesn't happen simultaneously).

> Are the other TCP ports, as well as UDP blocked by a force of nature? :)

Yes; the force in question is usually spelled out as "auditors." :(

Ah, that force. Does this force allow VPNs, or are you just reusing existing open ports for... alternative purposes? :)

In case of the former, then Wireguard will likely be permitted some day as the status quo of VPNs. OpenVPN and IPSec appear as dead ends, so it's just a matter of time. If Wireguard is successfully upstreamed soon, I wouldn't be surprised if it rose to the throne of VPN monopoly sooner rather than later.

In case of the latter, you're out of luck without a compat mode or a bridge tool... :/

Unfortunately, it's the latter. :)

So, since lots of people here have experience with VPN, I'd like to ask theoretical project question:

I have distant family memebers, and it'd be nice to have a simple way to get devices on the same network easily.

My initial thought would be to setup a VPN server somewhere central and fast, and then distribute wireless routers with custom firmware that they could plugin to their network. Then anything they connect to that router would be connected to the VPN (because the router is pre-setup to connect to the VPN).

Is that doable? Is it a good idea? I know just enough about networking to be dangerous...

Unless you are ok living with pwned routers, printers, you don't want devices with javascript-enabled web browsers and other random 3rd party software, like apps, to have access to anything on local network or at least not when they have access to the internet.

Wait what? Are you saying for example at home you would not allow your PC access to anything else on your LAN?

Home equipment often is relatively poorly secured. The reality is that intra-LAN communication causes contagion to spread easily, that blocking intra-LAN communication can be very inconvenient, and that often there is no good solution.

At least restrict it as much as possible. For example, allow connections only to the printer, if that is needed, and maybe only in one direction - and lock down that printer. But consider walk-up printing via USB cable: People print much less often these days and they have to walk over to the printer to pickup the document anyway.

Have you seen ZeroTier?

I've only used it for testing purposes, so I can't vouch for the quality of connections or anything else really, but it seems like something that could be useful for your use case.

ZeroTier. It's excellent for your use case.

Yeah run it on OpenWRT, PFsense, or OPNsense and have the router bridge from zerotier to lan. Flat family L2 network.

Certainly doable, but it really looks like the unnecessary hard way to do it.

If you set up openvpn somewhere you can just handout .ovpn files and tell your relatives to install the openvpn client on windows. Then they just have to double-click the .ovpn file and iconise "that black window that appears" (the DOS prompt window).

Its doable and is called a site-to-site VPN.

There a various options to implement VPNs and each has its own problem

a) The option everyone else here tries to tell you about is a Client-to-Site VPN. Its downsite is that you'll need to connect each client separately and the VPN isn't entirely 'transparent' (the client and programs can and do know that they're not directly connected to the internet)

your performance will suffer unless your VPN server has enough upstream to offset the combined downstream of all connecting clients. You can offset this by manually routing all internet traffic along the normal gateway and just use the VPN for inhouse connections.

  ie.
  192.168.111.0/24 (vpn) gateway 192.168.111.1 (VPN HOST)
  0.0.0.0/0 192.168.0.1 (Router)

b) a true Site-To-Site VPN is possible with enterprise routers. You'll probably have to define static route across all routers as routing protocols will probably add more maintenance than they'll prevent. Each has to be manually added on all routers but remote management is generally possible at that price point. Expect at least $300 for the very cheapest router, and you'll probably want to spent at least $500 per device.

The VPN is entirely transparent and at that price point, you'll be able to configure the routers remotely. Management won't be as big as a problem as you'd expect, as these devices are very stable.

  i.e.
  house a 192.168.111.0/24
  house b 192.168.112.0/24
  house c 192.168.113.0/24

What you were probably hoping for was to get a cheapish router, flash DD-WRT or similar and just use that? if so, i don't believe thats viable. they just don't have the CPUs power to handle this amount of package inspection (its probably using IPSEC, so each IP Package should be flagged and needs to be validated separately)

c) ISPs can provide you with a network across sites. Expect to pay thousands though. really good performance however

d) client-client VPNs. Zero Tier is one of these. Each client needs to install a software and all communications are directly addressed.

You don't need a central server anymore (still have one for initial authentication however). You'll however have to force people to

1. install the software,

2. start the software,

3. update the software. You probably don't want to do that with family members though. Its very ... annoying

performance is pretty great and you can actually buy appliances which give you the same Site-To-Site capabilities. Beautiful technology which is just as expensive as the enterprise routers. No idea about managing them however. Never had one of these appliances myself

/edit it might be possible with the edge router? i don't have any experience with that, but it does look like it. https://news.ycombinator.com/item?id=17660518

Thank you for the very thorough reply, especially the terminology. Yes, I think what I want is site-to-site vpn hardware to have lan parties with my family on consoles that don't do well with the internet (I'm looking at you nintendo switch).

So multiple people have listed ZeroTier, and you mentioned it as a client-client. It looks like they have a crowdfunding campaign to launch a site-site vpn device... I think: https://www.indiegogo.com/projects/zerotier-edge-open-source...

Edit: Thank you so much for teaching me to fish (the terminology) instead of just giving me a fish (recommendation).

> It looks like they have a crowdfunding campaign to launch a site-site vpn device

that is what i meant with the appliance.

I can't speak from experience, but what i've read yesterday makes the previously linked comment the most interesting [0]

the edge router costs ~$100 and has enterprise hardware. The only missing feature is the management frontend, which isn't stricly necessary. And the referenced vyatta-wireguard [1] has a code excerpt which looks like a site-to-site vpn

  [0] https://news.ycombinator.com/item?id=17660518
  [1] https://github.com/Lochnair/vyatta-wireguard

I would think carefully about why you want to get them all on the same network, and then find other, application-based ways to accomplish the same thing. For example if you want to share files, use Dropbox instead of a LAN file share. This will most likely be easier to implement and secure.

Consider that cutting edge companies are in the process of basically deprecating their LAN in favor of app-based security. Google "zero trust network" or BeyondCorp.

You can build this sort of ecosystem yourself using commercially available products and services. Instead of enterprise single-sign-on, set up family members with a password manager.

I should have mentioned I'm trying to connect devices that can connect only to wireless that you can't set up a VPN on (the Nintendo Switch). Though I'm sure once I got it setup I'd abuse it for easy file transfer occasionally...

I have a VPS I use for VPN, which means, unfortunately, no custom kernels or kernel modules. So, I'm stuck with OpenVPN. It would be awesome to have WireGuard included in the kernel by default.

Based on what you stated, I assume this VPS is running on OpenVZ? If so, I doubt it will ever see newer kernel features, in part due to OpenVZ hosts relying on ancient LTS kernel branches and also due to OpenVZ "optimizations", whereby kernel features that use extra resources to enable just get disabled. Or, if your lucky they'll give you a button to re-enable them for youe container on an ad-hoc basis.

Heads up, $20 yearly and similar KVM deals are becoming more common, and you can run any kernel you want in KVM :P

Where do you get these $20/y deals?

arubacloud.com has KVM based VPSes starting at 1€/month.

https://www.arubacloud.com/vps/virtual-private-server-range.... says "based on VMware technology". Doesn't sound like KVM.

Nothing between small and medium, with 2 to 3 Gb RAM?

Lots of offers on lowendtalk.com. Not all equally reliable.

Arubacloud is pretty good, but €1 offer is only available in Italy.

Besides that RamNode, BuyVM, Hetzner and Ultravps are pretty good (though all a bit more expensive than 20$/year).

Here is a KVM VPS with a gig of ram for $15: https://www.lowendtalk.com/discussion/150797/virmach-raid-10...

find a VPS provider that supports using KVM properly as a hypervisor. Vultr is a good one to look at first.

I'd love to see this included as part of the next macOS / iOS.

I'm sorry.

It probably won't happen for other reasons, but there is a userspace port, so it should be usable from Darwin.

It works well from macOS.

The only thing I don;t like about current WireGuard is that the single config file contains both the private key in clear, and all the public keys.

IMHO the private keys should be in a separate file.

https://wiki.archlinux.org/index.php/WireGuard#Store_private...

Private keys should be in secure hardware. Short of that it's all hand-waving.

That's one benefit that IPSec+IKE has over Wireguard at the moment. With IPSec authentication can occur in userspace and the private key never needs to be exposed to the kernel or to userspace. By the time you implement this for Wireguard, if ever, the Wireguard "stack" (inside the kernel and, hopefully, outside the kernel) code size will have gotten considerably larger.

It's largely theoretical at the moment because few IPSec setups actually make use of this capability. But it will become more common over time.

It's super easy to configure overall. But I know how to configure networing under Linux. The only thing I struggled with was AllowedIps concept, because that was the most unfamiliar thing to me.

I use WireGuard to give my IPv4 only home computers fixed IPv6 addresses and connectivity via my VPS. It also serves as a sort of overlay network, where my devices despite not having a fixed IP address, are still reachable on a WireGuard network via my VPS.

Great to hear that.

What's the status with the official Windows client?

So I can use this as a secure proxy to get around region restrictions? In the same way I do ssh -D? And then configure the proxy on my browser?

It is more low level than that and closer to OpenVPN in terms of setup. Which means not bad.

The main gain is in efficiency. It is much less resource intensive and thus sometimes faster.

Really recommend if your systemd is up to date, describing your wg interfaces in .netdev files. Really clean, starting to really like systemd with things like this...

is there a way for linux desktop to have some apps go through wireguard tunnel, and other apps to go through regular network interface?

Is there any paid VPN provider that supports it?

Yeah, Mullvad and Azure both have a WireGuard offering.

Mullvad does

AzireVPN. Another one was mentioned in the thread. Mullvad?

Also bunkervpn

This is great News!

Which of the popular VPN offer wireguard? Pia doesn't.

Mullvad

this news is lit! i remember using wireguard seems decent.

Reply on news.ycombinator.com