Why Not WireGuard (2020)

It is rooted in a lack of imagination. The entire argument is basically because this network does not do exactly what Cisco and the big VPN vendors with large enterprise deployments and bare-metal machines and thousands of end node clients it will not displace them.

That’s like arguing that the streaming will not displace CDROMs, because streaming cannot be rotated in a disc drive at a sufficient speed. The author acknowledges containers, but disregards the growth of zero-trust-networking and evergreen deployment models.

Technologies like Tailscale and ZPA, Docker and Snap, and immutable operating systems are being quickly adopted. These change the equation to the point that traditional approaches around ZScalar may feel as obsolete as a 5.25 floppy in a CDROM world.

The article tries to argue that the cryptography in IKEv2 and IPSEC is comparable to that of WireGuard. After all, there are RFCs for Curve25519 in IKEv2, and Chapoly in IPSEC.

This pattern of argument frustrates the hell out of me. You see it all the time in discussions about PGP as well, where any conceivable cryptographic primitive has either been standardized or POC'd somewhere in the ecosystem. Leave aside interoperability (nonexistent) and negotiation (dangerous). The argument still doesn't hold!

Just because you've got a Curve25519 formula somewhere in your design doesn't mean it's directly comparable with anything else that uses Curve25519. The tricky bits are in the joinery, not in the primitives. WireGuard does a NoiseIK-based triple DH handshake --- it performs an authenticated key exchange, one that MITMs can't intercept, using only the DH primitive. In the closest comparable mode of deployment, IKEv2 uses digital signatures to authenticate exchanges, backed by X509(!) certificates. IKEv2's AKE is much more complicated, hard to assess for security on its own terms, and implicates some giant historic security nightmare code paths. Avoiding those code tar pits is explicitly part of the security design of WireGuard.

Nobody should concede the point that IPSEC allows users to opt in to WireGuard-level crypto modernity. You can't just swap Curve25519 for Diffie Hellman Group #14 and call it a day. You should be skeptical of people who make claims that you can.

Idk, seems like someone is trying very hard to defend their solution by vaguely throwing empty criticism about a new technology. Not even very convincingly.

From time to time someone can write a critique about X that actually touches on the bad parts, but this article is not it.

That alone should tell you everything you need to know here.

Cisco's VPN currently sets its interface metric at the highest priority, ensuring that things like running docker containers or WSL/VirtualBox/Qemu/etc instances can't talk to anything once the vpn is up. It also watches for you trying to manually fix it with route insertions and fights you.

So, yeah, they aren't even jumping onto old trains, like "developers use internal private networks so please don't bork them up".

It’s clear to me from this alone that the author of this article has never had the misfortune of trying to get any two network appliances from any two different vendors to establish an IPsec tunnel. It’s a certifiable nightmare and I have lost entire weeks of my life in the past to trying and often failing.

The IPsec suite has a vast surface area and it is significantly harder for any one person to understand compared to something like Wireguard, which is, above most other things, simple. In an ideal world, IPsec might be easy “if it’s done right” but it’s incredibly difficult to debug what is happening when IPsec goes wrong. There are so many moving parts, competing specifications, buggy implementations and, for every tunable, there’s a whole heap of hidden complexity.

The industry likes to appoint Cisco, Juniper etc as if they are some kind of gold standard for some reason. They are certainly among best in the league tables for the highest number of bugs per config line if nothing else.

Also, being a user of ipfire. They are far from stable and it feels a bit like projection.

I had to do this because I lost my patience while configuring OpenVPN on my Mikrotik router. Wg by contrast was very easy to install, a plugin on HA, and a QR code on my phone. No copying keys, no config, no BS. Van't wait for it to be included in RouterOS.

The only issue I had with it running on a VM was that the VPN would randomly fail for some obscure reason and I was left with a frozen terminal in the middle of a ssh session. So I switched to an existing OpenVPN instalation on bare metal which works flawlessly. I need the VPN exactly because my IP changes at every PPPoE session, so I can't use IP based ssh access.

Who cares if Cisco is not using it? Most commercial VPNs are junk or insecure anyway (PPTP I'm looking at you). They'll have to provide it when everyone uses it, just like they did with ssh.

https://news.ycombinator.com/item?id=22591454

https://news.ycombinator.com/item?id=22955607

Every goddamn article I read about wireguard disadvantages contains following buzzwords: "big vendors", "200 clients", " rolling updates"....

Hello, my name is Aine and I want to setup family VPN. I don't have Cisco, I don't have 200 devices, I don't need rolling updates around the world. I need simple, fast VPN that will work. And you know what? Wireguard works OK. It's simple, it's fast, it works!

Why should I care about "big vendors" or "200 clients"? Why EVERY article talks about that bullshit?

I ask you a personal favor: if you ever will write an article about VPN, please, I beg you, explain how it works for small users use cases, like family usage or small business. I tell you why - because " big vendors " and people who need rolling updates of ciphers on 200+ clients all over the world will figure out pros and cons of different solutions without your almost the same article as 100500 Google results for "%vpnname disadvantages" /rant

VERY happy customer.

[1] https://undeadly.org/cgi?action=article;sid=20200622052207

Okay. Not worth debating.

> bitching that Cisco et al won't start using it

Sounds like a good way to distinguish between vendors.