[tptacek]

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.

[tssva]

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.

[lawnchair_larry]

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!