I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol.
So why is it so much better?
Is it because it's a new and simpler implementation than what we have for IPSec?
Is it because the protocol, being newer, is simpler and cleaner than IPSec?
Is it because, being newer, it can use a modern ciphersuite?
Are there fundamental advances in the design?
One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate. Introducing a whole new protocol whose main implementation is its definition seems like a step backwards.
> One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate.
Having deployed IPSec between vendors, this is only "sorta" true. IPSec can be an immense fiddle to actually get running between two vendors for the first time.
One of the other issues when using IPSec between vendors (or even just be default) is that the actual overlapping ciphers/hashes that are supported or even just work are normally the lowest possible.
> Are there fundamental advances in the design?
First party roaming makes dealing with mobile and CGNAT much nicer, anyone behind a IPSec VPN on a home CGNAT network will have a bad time (often it won't connect at all)
Finally. It's code base is actually pretty small, allowing sane audits to take place. In my eyes thats a huge win. People who have seen the sheer size of strongswan or openvpn might appreciate wireguard in comparison.
IPsec is industry standard, but the whole IPsec stack and surrounding technology stack are very complex, different implementations (e.g. those Swans), configuration combos (phase 1,2 or in strongSwan sense - IKE, ESP, route-based, policy-based, etc.) and clients for different platform makes the whole thing a headache to deal with at large scale.
I've been using / working [1] [2] with strongSwan since early 2014, admittedly, the hands-on experience lifted my Linux / Networking skills to a whole new level, but at cost (countless hours burnt). It requires a broad range of skills, has a relatively steep learning curve.
> The company I've worked for (in pre-IPO stage), had 800+ strongSwan instances served as site-to-site VPN gateways inside AWS VPCs, they were single point of failure from a design PoV but that simple design (with health check and recovery mechanism of course) worked surprisingly very well over a period of 3 years (thanks to simple design and stability & quality of strongSwan). Personally I've been using strongSwan based VPN gateways to punch holes in GFW and encrypt network traffic until mid 2018, happy with it (<10 strongSwan instances to manage).
WireGuard is totally different design when I first migrated from strongSwan, simple, visible (interface, route-based), cryptokey routing, built-in roaming, small code base (minimal attack surface), performance (in kernel). Over time scalability and usability (all sorts of web UIs or GUIs) will improve, for large scale overlay we may better off with something else (nebula). For now officially it offers native client for most of the popular platforms.
For any new typical VPN (remote access, encryption in transit, site-to-site may not be as flexible as IPsec as I haven't done that, I used nebula instead to created an overlay) use cases, I'll pick WireGuard to start with ;-)
> One of the nice things about IPSec is that it's a standard
I would love to agree with this, but in practice, IPsec across vendors (or even across product lines from the same vendor) is often a nightmare. There are so many moving parts to IPSec, whereas Wireguard is drastically simpler.
From what I understand, Wireguard is intentionally non crypto-agile. Wireguard 1.0 has a mandated cyrpto suite, and in the future 2.0 or 3.0 would have mandated standards as well. As a result the connection negotiation is simplified and interop is guaranteed between providers.
So why is it so much better?
Is it because it's a new and simpler implementation than what we have for IPSec?
Is it because the protocol, being newer, is simpler and cleaner than IPSec?
Is it because, being newer, it can use a modern ciphersuite?
Are there fundamental advances in the design?
One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate. Introducing a whole new protocol whose main implementation is its definition seems like a step backwards.