I think you could reasonably look at WireGuard as a repudiation of previous VPN protocols, almost from root to branch.
For instance, WireGuard reconsiders what the role of a VPN "protocol" actually is, and in WireGuard the protocol itself delivers a point-to-point secure tunnel and nothing else, so that the system is composable with multiple different upper-level designs (for instance, how you mesh up with multiple endpoints, or how you authenticate).
Another reasonable way to look at WireGuard is that it's the Signal Protocol-era VPN protocol (WireGuard is derived from Trevor Perrin's Noise protocol framework).
Notably: WireGuard doesn't attempt to negotiate cryptographic parameters. Instead, they've selected a good set of base primitives (Curve25519, Blake2, ChaPoly) and that's that; if those primitives ever change, they'll version the whole protocol.
If you haven't played with it, WireGuard is approximately as hard to set up as an SSH connection. It is really a breath of fresh air.
Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC removed. With a bit of multipoint goodness (ala DMVPN) sprinkled in.
The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN.
Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algorithms it's chosen, then we'll need a Wireguard 2. That's a design choice that trades off one thing (protocol independence and resilience) for another (simplicity and ease of implementation).
No, I think this is essentially wrong. It's hyped because it:
(a) Doesn't have selectable or negotiable algorithms and constructions.
(b) Exclusively uses modern constructions everybody trusts.
(c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit.
(d) As a result of all of this, it is very fast.
(e) As a result of all of this, software security and cryptography engineers generally trust it more than any alternative protocol.
(f) As a result of all of this, it is absurdly simple to configure and get running.
Yes, IPSEC does a bunch of stuff WireGuard doesn't do. Yes, that's the tradeoff WireGuard made. Making that tradeoff is (a) the point of WireGuard and (b) the reason people like it so much.
I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux.
However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on par, plus I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.
So I'd say right now if you need absolute max performance, a good IPsec implementation is much faster than Wireguard.
[1] for example, just running 'openssl speed -evp chacha20-poly1305' vs 'openssl speed -evp aes-256-gcm' on my laptop gives a ~2x speed advantage to AES.
This is a big reason why ZeroTier is moving to AES for its symmetric crypto. It's not only a lot faster but much more power efficient. The blazing speeds with ARX ciphers are only achievable using vector or other parallel constructions that light up the whole ALU, using many times more power than AES hardware.
Using AES with GMAC I can clock from 2-4GiB/sec/core on typical laptops and over 1GiB/sec on phones. The Apple M1 does almost 5GiB/sec/core. Gen10 and newer Intel CPUs with VAES have produced benchmarks in excess of 10GiB/sec/core, which means a single core could theoretically saturate 100gig fiber if it were just doing crypto.
Of course nothing stops CPU makers from adding ARX accelerator instructions, but I have yet to see any proposed. If constructions like ChaCha and BLAKE2/BLAKE3 get popular enough I could see this happening.
Post numbers on a good IPsec implementation? We have numbers for WireGuard. Of course, it's easy to do that because there's just a couple primary implementations, not 100 terrible ones like in IPsec. So, pick the best one.
We don't have to derive the answer to this question from first principles. It's an empirical question.
Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.
Those numbers can grow up to 50% for big packets (1500-bytes and higher).
With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.
Yes. But VPP also supports Wireguard, and when doing apple-to-apple comparisons, the performance difference between Wireguard vs IPsec AES-256-GCM is close to 2x. See https://fosdem.org/2021/schedule/event/sdn_calicovpp/attachm... slides 23 and 26: 5Gbps of Wireguard vs 9.5Gbps of IPsec.
And the main reason is the cipher: one is hw-assisted (AES-NI on x86), the other is not.
Again, I do think Wireguard is nice because it is a clean sheet design with good choices and it "just works". However when I hear "Wireguard is faster than IPsec" it is not true in my experience, and can be easily explain by the cipher choice.
>I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.
The speed gains wouldn't be as significant. AES uses S-Box computations that do well when hardware accelerated, whereas ChaCha/Salsa20 are designed to use more typical CPU instructions for bitwise operations.
Speed gains maybe not, however on current x86 platform there is a 2x perf difference between AES-256-GCM and Chacha20-Poly1305, so even if we get "only" 2x I'd be delighted.
> (d) As a result of all of this, it is very fast.
No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC hardware offload.
OpenVPN is slow due to architectural constraints, but IPSEC doesn't suffer from that at all. IPSEC tunnels with PSK is also absurdly easy to configure, either on Linux, or a router, what it doesn't offer is native NAT traversal.
What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management.
IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht...
ISAKMP/IKE is then used on top to manage the IPsec keys and parameters. This is where a lot of the complexity comes in, tons of parameters, modes, etc. etc.
So if all you want is to secure communication between two IPs and can securely exchange key material out of bands, manually keyed IPsec is not very complicated.
IPSEC without IKE is not "similar to how wireguard works actually." Wireguard does actual key exchange and has security properties such as Forward Secrecy that you don't get using a hardcoded IPSEC symmetric key.
Also, even the IPSEC config without IKE is way more complicated than a Wireguard config, with seriously sharp edges. Just look at that config you linked to. No one should ever need to know what AH and ESP are, but if you don't you very easily can configure IPSEC in an insecure manner.
Is that your absurdly simple configuration? Can I assume the contents of that web page are where you rest your case on WireGuard's `wg.conf` vs. IPsec?
It's like SSH, with no Trust-on-First-Use option. Unlike more complicated pre-existing protocols, how you handle key distribution is explicitly out of scope for the protocol.
Which is great. It decouples responsibilities. WG gives you a secure, well-performing tunnel. Key management is outside its scope. There are many solutions to that problem, no point in forcing a "WG sanctioned" one on people.
And yet the crowd that pushes WireGuard is the same crowd that pushes the idea that you can't give people a toolkit of crypto stuff, you have to give them a turnkey end-to-end system - indeed the fact that there's e.g. no algorithm selection in WireGuard is touted as a selling point. But how is making the user do their own key exchange/management any different? If you break the key management you break the cryptosystem.
Why should WireGuard bake all that stuff into the core protocol and at the same time make it overly complicated? Donenfeld knows zero about your organization and he doesn’t pretend to do so either. Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
> Why should WireGuard bake all that stuff into the core protocol
Because all that stuff is security-critical. All that stuff needs to be incorporated into any audit of the system. Indeed it's probably where the vulnerabilities are going to be.
> Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
There needs to be a system that can scale there, especially if the intent is to replace OpenVPN which slotted neatly into standard PKI. If this system pushes more users onto a handful of centralised providers, which seems like what's implicitly being encouraged, then that's not going to end up being good for security.
This argument doesn't make any sense. The more you couple to the underlying protocol, the harder it is to audit. Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.
Having a predictable boundary and having modular crypto systems are two things that can sound similar, but are really pretty opposite.
To take the popular example: OpenSSL has a plethora of extensions. If there’s a thing you want to do, odds are the spec has been extended to cover that use case.
One result of that is that many code paths exist that aren’t part of everyday usage for most users, and so those code paths get less love (and more bugs): this makes things like Heartbleed radically more likely.
Another result is that parties using the system to communicate need to agree which modules/extensions they’re going to use. This kind of negotiation has been a punching bag for vuln after vuln, because it turns out some options are going to end up having weaknesses, and thus attackers can make their lives easier if they focus on tricking parties into downgrading to weaker modules.
By contrast, having Wireguard exclusively handle point-to-point tunnel behavior, without any negotiation of modules or extensions or similar, both simplifies the code paths and avoids runtime negotiation. Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.
> Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.
Right, but that system actually needs to be implemented, and the two need to be integrated together, and that part is where I suspect the vulnerabilities are likely to be, because the interface between two systems developed separately is always the most likely point for bugs and misunderstandings to creep in.
People talk about WireGuard having fewer vulnerabilities than OpenVPN and that may be true as far as it goes, but it's missing the fact that you can't simply replace OpenVPN with WireGuard - you would have to replace it with WireGuard plus some certificate management system plus some integration between them. And if everyone builds the last part themselves, it will almost certainly have security vulnerabilities.
That's not honest. Wireguard on Linux is really hard to install. I managed to install the "server" side after a lot of huff and puff but I've given up on the "client" side. On windows, the "client" side really is as easy as you say though. It's LOVELY
You'll have to say more about the challenges you found with it, because we do a _lot_ of WireGuard here, in a bunch of different ways, and given a valid `wg0.conf` file (which is just the keys and the addresses for the tunnel), I've never hd to do much more than `wg-quick up wg0.conf` to make it work, on our servers, on my NUC, on Amazon Linux EC2 instances, and on VMs.
And there it is. Idk about OP but this is what tripped me up. There are many guides online, but the native documentation assumes you have a pretty deep understanding of the network stack, authentication, and VPNs.
The online guides all kinda make assumptions about your network set up and if it’s different in anyway your attempt will fail and you won’t know why; as the error codes are kinda generic and somewhat meaningless to someone without in-depth networking experience.
But the `wg0.conf` thingy has to be set up on Windows too, right? So It's not clear why it would be easier on Windows than on Linux.
As far as I'm concerned, the most difficult thing I've encountered with Wireguard wasn't related to WG itself but to the fact that I'd set it up on three different systems, each with its own configuration style for bringing up the network.
Wireguard is a UDP-based VPN protocol that focuses on simplicity and security. Its Linux implementation is a mere 4000 LOC and the protocol has been formally verified. OpenVPN is over 100,000 lines of code PLUS OpenSSL.
wireguard is a VPN technology that is now integrated into the Linux kernel, and is available on all major platforms.
It distinguishes itself from other VPNs by not having knobs to twiddle. Should a security issue arise, it will be necessary to replace it with a wireguard2 or such. This also means that it's very hard to get it wrong in config; either it works or it doesn't, and if it doesn't, you haven't got it working yet.
Wireguard is pretty much half of what you'd expect from a VPN. It does the low-level part (encryption, packetization, session setup, NAT traversal, etc. -- the “actual VPN”) brilliantly, but everything around key distribution is left to external systems. (Tailscale is a popular choice, but by no means the only one.) E.g., you can't connect to vpn.example.com with user foo and password bar and that's it; there needs to be an Ed25519 public/private keypair set up on both sides, an IP address range (essentially a routing table), and so on.
Of course, if you want to connect two static networks, wg-quick is all you need. But for the typical “remote worker VPN”, it's pretty much a (great) building block.
> but everything around key distribution is left to external systems.
That's what I'd like, since authentication is usually a pain to set up and with Wireguard, there's none to be done. This also means it's totally stateless and is great for mobile devices where a connection might be broken and crsated again frequently.
I’ve been begrudgingly using Tailscale because it’s so damn simple, but hate that I have to authenticate through Google. I recently noticed they’ve added a “sign in with GitHub option,” but I don’t see any easy way to migrate my account (and nodes). Many of the clients are PiHoles I’ve sent off to my family as gifts, so physical access is a PITA. The only way I’ve found to reliably clear the Tailscale settings is to `apt purge Tailscale`, which would cause me to lose Tailscale SSH access. Looking at the hassle of the remote reinstall- I’m thinking to SSH in with Tailscale, then establish a reverse SSH tunnel to maintain remote access - I think I may finally give Innernet [0] a go.
You can also use Microsoft now (both "personal" accounts like used for Xbox/Outlook and "Enterprise" accounts like Microsoft365 and other AAD based accounts)
I'm sure if you asked them about switching auth methods they would help with that.
That’s a good point. I’ve sent them an email and I’ll see what they say.
EDIT: since I’m still in the edit window, here’s what Tailscale came back with (great response time!).
>We can fairly easily switch between auth providers where the usernames are an email address, like Microsoft or Google or Okta.
>For GitHub the username is different, GitHub uses your Profile name. Any email addresses associated with your GitHub profile are not available.
>Unfortunately there isn't a straightforward way to migrate an existing Tailnet with its devices from Google to GitHub. We generally recommend making a new Tailnet with GitHub and re-authenticate devices using GitHub one at a time. For remote devices, this is more challenging.
>If you want to try it, a suggestion:
1. you can create a Reusable authkey at https://login.tailscale.com/admin/settings/authkeys for the new GitHub Tailnet
2. Over ssh to a node currently on the Google Tailnet, you can:
`tailscale up --force-reauth --authkey=tskey-0123456789abcdef`
3. You'll lose the SSH session. The device will make a new Node key and be issued a new IP address on the new GitHub Tailnet.
4. You can look up its new IP address on https://login.tailscale.com/admin/machines of the GitHub Tailnet, and should be able to ssh to the new address.
Except FreeBSD which is used for pfSense - a popular firewall. They're working on it though. There was a bit of drama about it a few months ago when a shoddy implementation was merged.
FreeBSD can use the userspace implementation just fine; what almost made it out but was caught before it could actually be released was an in-kernel module for it.
It's a VPN protocol whose USP is being dramatically simpler than OpenVPN, which should mean that it is both easier to use and more secure (and consensus seems to be that it generally delivers on both of those fronts).
> It's a VPN protocol whose USP is being dramatically simpler than OpenSSL
What? WireGuard is a VPN protocol (and implementation), while OpenSSL is an implementation of TLS. They're not competing with each other, and you can't compare them.
the main reason IPsec is more complex is because it has more features, like multiple CHILD_SA under same tunnel each with different transform and traffic selectors, and also much more authentication choices
I honestly think "ipsec is too complex" is overdone. Yes, you need to know your networking basics and understand routing but that's probably a good thing when setting up a VPN. Then you pick your crypto primitives from e.g. https://www.keylength.com/en/compare/ and you are basically done.
But no, it's the typical groupthink of 'old is bad' so instead of reading two pages of documentation and having native support across all major platforms people would rather re-invent the wheel.
