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.
