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.
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.
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?
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
> I had a seamless time using wireguard (via a streisand installation) ...
I've been using Wireguard via 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.
Now I'm wondering if sheLL is a special thing or if you just held the shift key down by accident. Sadly you can't easily do a case sensitive search so I can't figure it out.
After switching to wireguard I've been really blown away at how much better the experience is on a phone than other VPN methods. It's always on on my phone as long as I'm not using my home wifi, and I just never need to think about it.
I noticed a HUGE battery drain with other VPN clients like PIA's app or just OpenTunnel, but either my 3 year old iPhone X has a great battery, or the battery drain from WireGuard has been unnoticeable for me.
I use an iPhone SE for work with a WireGuard VPN, no noticeable drain (beyond that battery life is generally pretty bad compared to my Android, even when WiFi/data/bluetooth/gps are turned off).
Do you have an automated way for turning it off when you're on home wifi? Trying a similar setup, and it isn't immediately clear other than via manual activation how to not use Wireguard in that situation.
The built-in "on-demand activation" is quite good. Can set it to specific SSIDs (white or blacklist) or cellular. I've it on for everything except my home SSID.
Edit: I'm talking about the iOS version, not sure what platform you're using.
No such luck on Android, you need to use tasker or similar. Really a nuisance but not a deal breaker. It would be dreamy to set up the client to not use specific SSIDs.
What iOS client are you using? I am using the Wireguard one (the the twisty snake/dragon) and don't see any of these options. Is this stuff that is done in the config files? Sorry, all new to me.
Presumably minimal latency from phone on home wifi to server on home wifi. I actually have no idea if this is true, or how I'd evaluate it. Does anyone understand how the internet and wireguard works well enough to know if this is true?
That's what I was wondering. I've actually done this using OpenVPN (connected to my home VPN server while on home wifi), and it worked fine. Biggest issue was battery impact, but wireguard might be better in that regard?
It works great on mullvad for me, never any issues. I just installed the PPA for Ubuntu 18.04 and everything else was easy peasy. Some people say it's faster for them but I don't see that on my Gigabit connection, just a bit less CPU compared to openvpn, but neither really uses all that much, it's a fraction of a single processor on my 6 core machine.
I don't remember exactly when I started using it but it feels like forever and I have forgotten about all the VPN nightmares that I had before.
I can't wait for Wireguard support in all kinds of routers and other appliances.
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.
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.
Properly encrypted data is basically impossible to compress. Lossless compression requires repeating patterns in the data and lossy compression requires an ability to understand the content. Since properly encrypted data should be indistinguishable from random noise, neither of these things apply.
Compressing first and then encrypting the compressed data works fine though.
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.
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.
It has a relatively seamless setup and is far from bloated, encryption is efficient on low-powered ARM devices and it works surprisingly well in environments where internet connections are shoddy at best.
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!
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.
I can tell you that as long as the crypto in WireGuard is DJB stuff that can't be FIPS certified, Cisco and Juniper and such will still do a strong VPN business and you will rarely see it in BigCo, at least in the US.
Security is largely about checking boxes to reduce liability, and FIPS is a checkbox.
Corporate IT is unbelievably conservative. It's all still about Active Directory, Windows domains, and SSL VPNs with FIPS certification and AD support.
Corp IT is still on AD as AD is literally the foundation of everything MS based. No matter if Exchange, workstations, file servers, even Office 365 - all is stored in Active Directory. Even their cloud services, even Microsoft Partner Program, it's all AD under the hood.
Sure you can use Samba / OpenLDAP / half a dozen of IMAP/SMTP servers for groupware but holy hell administering it is an utter hellhole of a mess compared to the MS offerings.
Corp IT cares about two things: retraining costs for employees and admins, and efficiency. And Apache Directory Studio just doesn't cut it compared with AD Editor.
Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis.
Industry prefers FIPS 140-2 because cryptographic expertise is extremely scarce and, prior to AES, commercial products were choc-a-bloc with broken hand-rolled cryptography. It's a rational decision to delegate selection of primitives to NIST.
I think FIPS 140-2 is aging poorly, but I think that's in part because all cryptographic standards are aging poorly; like, the whole concept: top-down standardization efforts with whole cryptosystems designed by committee have a very poor track record, and probably aren't the right vehicle to improve cryptographic soundness in the industry.
NIST SP 800-186 (Draft) has the curve definitions. But says only for Ed25519, not for X25519. They have a Weierstrass curve W-25519 that is isomorphic to Curve25519 that might allow using X25519 code, but that's way above my ability to judge. 'tptacek or 'jedisct1 or others will know.
One of the reasons it is still AD is that the management of users and computers is simplified. You have several layers of admin access etc.
I use Linux since 1993 and love it. All my servers are on Linux. Managing them as a group is a nightmare. I would love to have an umbrella à la AD to have all servers and users unified inside.
People regularly manage thousands of servers using Puppet or Ansible and version control. The structured text configuration files all UNIX-like software utilize makes this trivial.
The strengths of AD are more related to client software, where many of them uses the policy mechanisms therein for management. Maintaining servers isn't what it does best.
This is a large part of the reason why "the cloud" is pretty much Linux native.
I use ansible and salt to provision servers. It works great.
It has limited to no use to manage users and their passwords or authorizations, their control over machines, remote access to a share and zillons other usages you need specialized software for. AD has it all natively.
People with large environments that needs to be managed homogenously would beg to differ. How else would people manage these things large scale? It's exactly the kind of functionality that this software provides. Expressing rules in code might be radically different to someone used to a product like AD, but the learning curve is pretty quick and it is inherently more powerful.
I do not know about products for large environments. Our is arguably medium (around 10,000 servers) and we use solutions where each does its thing, without any reasonable cooperation between the solutions:
- users management? NIS
- configuration management? ansible / salt
- machines management? none (we use a homebrew system based off salt)
- shared storage? NFS
- policies? salt or ansible if they are common to groups of machines, or NIS if for people
etc.
I would love to have a unified tool (similar to what Zen was trying to do 20 years ago) but I do not know any. What AD does for Windows is nice (though I do not use Windows servers but I see their management from the side), Linux was intended to be standalone and this is what there are so many specialized, but disconnected management systems.
Right, but NIS and NFS are just protocols. You might as well have said DNS and IMAP. There are also services behind those protocols that needs to be managed. This is what Puppet(/Chef/Salt) does.
Take NFS as an example. Let's say all your users with meets certain criteria needs an NFS share named after their user and with an ACL that gives some running software access to drop files there. Maybe this share should be mounted on every machine where this software is present, regardless of who own it or where it runs. You write this rule in Puppet code and then it is guaranteed to be true for everyone forever.
Note that we didn't even need to feed Puppet any new information to do this. All the data required to implement the change was already in the configuration database. (Which is not even a real database but only the result of existing rules.)
Compare with a product such as AD. It doesn't really do the management for you. You can store the data there, but then you need to write a script to implement this change across your server farm. This need to be maintained, and regularly checked re-run to check for changes. Someone has to schedule this. When conditions change, the software which got access changes id, or is installed in another way, the script needs to be maintained accordingly.
Having this version controlled adds another aspect to this. Since everything is text, if you find this rule you can follow the commits and see exactly who brought this into production and when.
It's interesting that you refer to Linux as a standalone system. Linux and other unices have their roots not in single instance "personal computers" but in multi user environments. This is why to this day Linux admins treat everything as text and work mostly by text commands. Others may find this archaic but without this and without version control we could never maintain large homogenous environments. You might say that automation is built into the very way we use these systems.
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.
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).
> 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.
WireGuard's open source. Also you should bring these points up on the mailing lists. Even if you're not the one who writes it, mentioning it should put it on peoples' radar.
As you noted, Wireguard is only a part of what makes the current VPN solutions.
But that does not mean that it will stay that way. There's already effort at wg-dynamic, for dynamic allocation of ip addresses (as opposed to static allocation, which is current status quo in wireguard).
Later, it might be worth of effort to try running 802.1x over wireguard for authentication and accounting.
> There are no logs when someone connects or is trying to connect, so auditing or troubleshooting becomes extremely difficult short of packet captures.
I'm wondering if this would be a use case for eBPF
Apologies for sounding flippant: this sounds like a good opportunity for someone to build tools that use wireguard as a foundation to achieve what you want.
I tend to agree with this statement. I have been tracking WireGuard as a potential replacement for PulseSecure and it's a far ways off. We need 2FA and SAML support along with dynamic address assignment and logging before we can make the case to replace PulseSecure.
> I can only hope that WireGuard is going to drive a solid piece of hardwood through every "commercial grade" VPN appliance out there
I'm not sure that will happen. I mean, we had multiple solutions very close to what wg provides already. They're not as trivial to configure, but it would definitely be easier than creating a custom java applet instead.
Whatever makes enterprise VPN so bad, it doesn't seem to be the availability of better tech.
Currently looking at new vpn solutions where I work. Would like to use WG but it's just not suitable for a corporate environment (and neither is openvpn really, though we use it today), and it likely never will be because of how its designed (not a bad thing).
I've used it privately for a while and it is much better than anything else.
> 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.
This might quite literally be F5’s reasoning behind their BIG-IP Edge VPN client. :)
But outside of DNS (and agree that’s a big outside), aren’t pretty much all major protocols already encrypted these days? SMB2 was the last big one I could think to but SMB3 has (optional) encryption.
Apart from DNS, the destination address on each packet leaks a lot of information about which online properties you are accessing. A determined attacker may even be able to figure out exactly which webpage you are on, based on the size of the packets and the order in which you connect to various addresses. Using a good VPN helps obfuscate a lot of that metadata.
Whether you can actually trust an HTTPS site or an IMAP connection when you're in a hotel in China is another problem that a VPN can solve. The CA infrastructure is ridiculously fragile, especially now that HPKP is dead in the water.
You should encrypt DNS. DPRIVE standardised DNS over HTTPS or if wrapping yet more things inside HTTP makes you want to vomit DNS over TLS directly. You can use it today.
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.
Exactly. Netgate has long said that they won't touch it until it's production-ready; they keep pointing to the warning messages in WireGuard saying that it's beta and when the time is right, they'll consider it.
I'm happy they're being cautious. The inclusion in the Linux kernel is perhaps (to Netgate) a sign that things are headed in the right direction.
As far as FreeBSD, all that exists today is a userspace package (AFAIK). Again, I'm hoping someone sees this as a step forward and will start working on the FreeBSD port.
I'm glad to see progress and hoping for more of it!
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].
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.
Udp2raw and similar software could be used to bypass UDP restrictions. Basically it creates valid tcp headers and sends those packets with them through raw socket.
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.
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)
The userspace wireguard-go implementation is slower than the kernel one. Some (I don't know how much) of that is the userspace <-> kernel barrier, but they're also totally different implementations (Go vs C).
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.
This is what we (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.
I am interested in using tailscale as an individual user.
I'm essentially worthless as a user: I'm a college student and would be unwilling to pay much; I might possibly convert to a serious customer but that would be years and years down the line when everything is different.
I'd also be massively underutilizing it to connect a handful of devices and max two or three users.
I put my email address in your system, and am crossing my fingers.
My experience with dealing with the DKMS implementation of the Nvidia drivers left a sour taste in my mouth. Not fun when something goes sideways with an update and thousand nodes need to be recovered
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)
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.
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.
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/):
> 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.
Every security product has an excellent track record until vulnerabilities are found. Once it hits production and sees a 10000x increase in usage so it becomes a high value target for nation states, then it will be put to the real test.
This is what I've advising people with a little bit of know-how to do. Using Algo [0] (If you only need Wireguard and little else) or Streisand [1] (If you need Wireguard in addition to many other things) makes it pretty much trivial.
Yeah, there are some issues which makes it harder than it has to be but e.g. Mulllvad has been providing it to their customers for a long time. Required extra work but not insane amounts of it according to a guy at Mullvad who I was talking to.
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
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.
Thanks for the information. What is your recommended way to set up a wireguard server on a home network? Some quick googling tells me it is possible to do it with a raspberry pi, but I would be worried about that being a bottleneck.
Ive had a WireGuard install running for about 6 months on a pi and as far as I can tell it hasn’t been a bottleneck. Plenty of spare cpu and bandwidth. And I’m using the 3 which only has 100mbit Ethernet.
Granted I don’t generally watch a ton of streaming video and it’s mostly just me on my network, but no issues watching YouTube or doing anything else.
I really can’t state enough how much I love my wireguard/pi hole setup.
Yes, the protocol, yes, the implementation approach, and yes, the underlying crypto. That sounds like a snarky response, but you really did kind of cover it.
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.
It can't be easier to setup that OpenVPN was on my router (just clicking a checkbox), but I am very interested in switching to a new VPN as I would like to be able to stay continuously connected from my mobile phone, and I understand that OpenVPN isn't great for this.
What is your preferred method for getting a WireGuard server installed on your home network?
> What is your preferred method for getting a WireGuard server installed on your home network?
Have a Linux machine that listens for incoming WireGuard connections, then it only takes generating server keys (private, public) and then adding your client's keys to the WireGuard configuration file. Setting up an OpenVPN server on a Linux box is quite a bit more involved.
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 with ssh and setting up proxy in Firefox?
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.
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.
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.
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)
I installed wireguard via ppa on my ubuntu based distro, which wasn't too much of a pain. Are you referring to the "hacks" needed in your install section on the website for e.g. Red Hat/Cent OS?
very happy with the performance and stability, thanks a lot for your work!
No, I'm referring to that PPA, which includes the error-prone DKMS stuff. I'm glad it worked for you. Indeed we've put a lot of effort into ensuring that our DKMS stuff mostly _does_ work properly. Sometimes it doesn't though, and then it's a huge hassle. It's this hassle, for people less lucky than yourself with DKMS, that will go away with Linux 5.6.
Debian will probably ship it as a module, like the other networking modules they ship, which means as long as they don't change ABI, after your `apt upgrade`, you can do the usual `rmmod wireguard && modprobe wireguard` to hot-load the new version at runtime without having to reboot.
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.
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
It may be way simpler for basic setups but it quickly becomes as or more complex than ipsec for more advanced setups such as those involving dynamic routing and/or fail over routes. The additional complexity is due to the fallout of allowed-ips and how they are used.
What you essentially end up with is that a wireguard interface represents a point to multipoint non-broadcast network. Any one that has dealt with Frame Relay or ATM can tell you what a headache dealing with dynamic routing over such a network can be. Fun things like having to hand configure your OSPF neighbors. This can be overcome by configuring each Wireguard peer to a separate interface essentially making the interface a point to point network or using another tunneling protocol overtop of Wireguard such as GRE or L2TP. But you quickly lose any simplicity advantage.
Even for something like a static floating route for backup Wireguard can be more complex because a Wireguard interface once turned up will not show as down unless manually turned down. This means the connection has to be monitored and the backup route installed based upon the monitoring criteria. Again nothing that can't be overcome but doing so raises the complexity.
Unless you are assigning each peer to a different Wireguard interface and setting allowed-ips to all ips you also have to figure out how to update the allowed-ips for peers to be updated as the routing changes.
Personally I would have preferred if allowed-ips didn't exist and each peer was assigned to a sub-interface whose status could change based upon keepalives. Then the normal ip routing and filtering facilities of the kernel could have been used instead of the current situation where you have some amount of filtering and routing effectively being done by the Wireguard interface and then some being handled by the kernel.
I used to contribute quite a bit to the Wireguard package for Ubiquity routers but stopped when I switched to ipsec. It was apparent that Wireguard was more complex to setup and troubleshoot for even slightly advanced scenarios.
As for your statement that it is faster that greatly depends upon the platform being used. It is faster than OpenVPN almost everywhere but many network devices have SoCs that provide slow CPUs and acceleration for ipsec or at least the crypto underlaying it. On those platforms it often is not faster than ipsec.
Don't get me wrong despite my comments overall I think Wireguard is pretty darn nifty and am happy to see it included in the kernel. I just think it needs more tooling developed around it before it can be a less complex replacement for ipsec in even some fairly basic scenarios.
This doesn't even cover the enterprise road warrior VPN scenarios where Wireguard currently lacks many of the more advanced enterprise features of OpenVPN or proprietary offerings from the likes of Cisco, Pulse Secure or Citrix. Hopefully development of the additional protocols and tools needed to add support for more advanced scenarios is accelerated now that Wireguard will be in the kernel. Of course once these are added there is the risk that a Wireguard based feature comparative implementation ends up just as bloated and complex to audit as any of the current alternatives.
I think this is a really strong comment. The only observation I'll make is that making the simple base case for VPNs easy is much more important than making dynamically routed VPNs straightforward.
More people should be using VPN-like-tunnels as an access solution, but don't, because every VPN other than WireGuard builds in extra complexity to support use cases they don't have. What the industry desperately needed was a trustworthy VPN that was as simple to set up as SSH, and that's effectively what WireGuard is.
I agree preemptively: if your VPN is complex enough that you're running OSPF for it, for now, you should probably stick with IPsec, even though commercial IPsec implementations aren't trustworthy. But WireGuard will accommodate complex VPNs long before IPsec or OpenVPN get as simple for the straightforward "get access to staging Postgres" use case as WireGuard is.
While I agree that handling the needs of the simple base VPN case easily is important I think that could have been done without complicating things for the more advance uses.
The areas where Wireguard is clever versus simple is where the complexity for advanced scenarios has crept in. If the protocol had implemented a mapping of peers to interfaces or sub-interfaces, left ip filtering purely to the system firewall and depended upon system routing capabilities it would be less complex to use in more advance scenarios and need not be more complex in simple scenarios.
In simple scenarios wg-quick could have been responsible for the needed routing and firewall changes. It already makes some routing and DNS configuration changes.
Or if you have more than a small handful of users to manage. Or if you want MFA. WireGuard kind of breaks down when you go outside of site-to-site or “hobbyist nerd running a personal VPN” use cases.
SSH is even way more flexible there, and it’s really not great at that.
If you’ve managed to deploy WireGuard at scale with your clients, I’d like to be proven wrong!
This is why I still use Tinc for my personal use cases. The nodes can route through each other in user space. No kernel ip forwarding required. Downside is, it's very slow compared to Wireguard. For my uses cases, that is probably ok.
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..?
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.
Much faster, as it is UDP-based, it basically just keeps spraying network packets. I noticed that my SSH sessions are resumed after closing and reopening my laptop half an hour later.
IPsec, at least using IKEv2, also uses UDP in most deployments where you are not using IPsec directly without encapsulation (not that it makes a real difference). You may be confusing with OpenVPN, which can run over TCP.
In terms of speed, they are comparable. The great benefit of WireGuard is simplicity on Linux compared to the configuration nightmare that is StrongSWAN, but implementing IPsec/IKEv2 on OpenBSD using OpenIKEd is roughly comparable if you use Let's Encrypt certificates.
You can get really inexpensive GL.inet GL-MT300N-V2 "mango" boxes (about $20) that will provide transparent WireGuard or OpenVPN encryption for a device that doesn't support VPNs out of the box (ahem, a Smart TV or streaming box, to bypass geo restrictions). They don't support IPsec.
It's reasonable to ask the community for opinions/analysis. I'm fine with telling people to do their own research for simple facts/processes, but "how do these things compare" is potentially subjective, depends on experience, and IMO is a suboptimal fit for websearching.
- 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