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.
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):
If there's something that involves wireguard itself that's missing from or unclear in the docs, could you please clarify?
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.
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.
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.
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.
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.
It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection.
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".
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."
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.
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 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.
Wireguard could have used P521 and AES-GCM with similar security, but it would be slower and equally vulnerable.
Agreed. I like the way home assistant does it with a secrets.yml and you refer to your secrets by !secret <name of secret>
`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.
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.
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.
`man wg` works just fine as does `man wg-quick`
https://www.wireguard.com/quickstart/ also shows you how to make a config file
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.
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.
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.
Of course it's up to WG to decide if they want to deal with this kind of community education/outreach.
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.
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.
$ git commit -s -m "man: add example for bla bla bla"
$ git send-email --email@example.com HEAD~
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.
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.
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.
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, 126.96.36.199/8, ... etc excluding 192.168.0.0/16) or do something smart outside of wg/wg-quick, but I lack the expertise.
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 . 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
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:
I wonder if LineageOS plans to include this module..
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 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)
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)
Are you using the user-space implementation or the kernel module? I'm curious as to the difference in battery consumption.
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!
Certainly, you reported that issue through proper channels, and attached detailled information regarding your hardware, software, as well as packet logs?
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 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.
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.
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.
This is not gonna fly.
This response on the 'linux-crypto' list seems to agree: https://marc.info/?l=linux-crypto-vger&m=153310819905231
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!
Sounds like what you need is TCP_NODELAY?
This mail archive works:
After using WireGuard you really don't want to go back to the horrible IPSec/OpenVPN solutions.
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?
Bugs scale with C codebase size, full stop.
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.
From the patch:
+ tristate "WireGuard secure network tunnel"
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:
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.
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.
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.
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. :)
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).
Yes; the force in question is usually spelled out as "auditors." :(
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... :/
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...
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.
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.
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.
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).
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.
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.
house a 192.168.111.0/24
house b 192.168.112.0/24
house c 192.168.113.0/24
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
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).
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 
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  has a code excerpt which looks like a site-to-site vpn
Heads up, $20 yearly and similar KVM deals are becoming more common, and you can run any kernel you want in KVM :P
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).
IMHO the private keys should be in a separate file.
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.
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.
What's the status with the official Windows client?
The main gain is in efficiency. It is much less resource intensive and thus sometimes faster.