Why not “Why not WireGuard?” (2020)
tailscale.com
tailscale.com
> This is a surprising set of claims. First of all, that is not the only information needed to configure IPsec: critically, correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform.
This is so true. I once configured a Sonicwall and Cisco router and even though all encryption settings for both phase 1 and phase 2 were exactly the same, the tunnel refused to come up with negotiation errors. I had to change ciphers on both sides before it worked. Vendor incompatibility is an absolute pain with IPsec and IKE.
I've done cross cloud connects where the cloud vendors are on the phone with me and eventually say "We really don't have any idea why the tunnels are not connecting". And that's when using Cisco VPN appliances, no less, following everyone's setup instructions to the letter.
Indeed, not a trivially solved problem yet.
I would be worried about downstream issues with the security architecture, especially down the road when you pick up clients with compliance requirements.
"3DES in combination with MD5 is a common candidate..."
If a security architecture is a priority, then these people will not be customers.
Triple DES is not "boring crypto" by any means.
https://news.ycombinator.com/item?id=13383006
Wireguard's crypto is boring. That's the point.
If you just want to set up a secure tunnel connecting two networks over an untrusted network, probably 95% of what IPsec can do won't be of any help to you at all, and will actively hinder you because you have to find the exact combination of settings that works for whatever two endpoints you want to join together.
That's not a feature per se, it's just a side effect of having pluggable mechanisms at each part of the protocol.
They allow IPSEC to be extensible - for example to support group SAs for GETVPN (Group VPN), used in a lot of encrypted networks in higher security environments. This is usually done on the CPE router. On very high security networks, a separate hardware encryption device is needed.
To implement something similar to GETVPN in wireguard would require an agent to constantly change the private and public key pairs for every peer relationship in the group.
IPsec can certainly do fancy things when you really get serious about encrypting and authenticating everything and wireguard is not nearly ready tooling-wise to replace all of that, but the configurability also makes IPsec pretty unfriendly for solving simpler cases like just connecting two or more separate networks together or road-warrior client setups. I suspect people are excited about Wireguard largely because these cases are common enough that whatever actual reason IPsec has to be as flexible as it is is dwarfed by the pain it causes in simple cases.
As for group VPNs, maybe I'm misunderstanding something, but why would you need to be constantly changing Wireguard keys on nodes in the network, when you only need to distribute the public keys for all nodes that need to communicate? You only really need one keypair per node that's participating, and it's not really a problem for the public keys to be long-lived.
Regarding your last point, the whole idea of GETVPN is membership in a encryption group. This include joining the group and leaving the group (and what this entails), as well as distributing group keys. Witeguard just itself designed for this and it can't even be hacked on. Whereas extending IPSEC to support group semantics was relatively seamless.
Oh, boy. It's not just ciphers. If you look at software alone, compatibility between the various *swan flavors is not exactly a thing.And what about IKE? By far the most misunderstood, haphazardly implemented piece of the puzzle.
[1] https://cohesive-networks.s3.amazonaws.com/dnld/Cohesive-Net...
Wireguard on the other hand is secure or off.
Source: I'm an infosec professional and general systems guy and I use IPSec at home with StrongSwan. It took me several hours to set it up and I still run into issues from time to time.
People in this thread point out that is not compatible between networking hardware vendor implementations, but if you just run a Strongswan responder on your own server a lot of this disappears. And yes, Windows/Linux/Mac are natively supported. Setting up a Windows peer is importing a certificate and two lines of PowerShell.
You are confirming what I said: that it's only easy if you have something to copy and paste off of.
It took me hours because I was trying to do something less common, namely peer to peer transport mode between LAN hosts with rules to exclude SSH access and multicasts. That this was a less common config is no excuse for the amount of prodding and debugging I had to do until I figured out what magical set of policies did what I want.
Back when I was supposed to connect our office to the new parent companies network via IPSec, I spent actual, full days on the phone with both the parent companies IT and our firewall vendor, until eventually we confirmed that some PFS variations are broken in one of the device, but others are not. And it's probably not economically feasible to fix. Debugging that involved going entirely nuts with wireshark, learning the IPSec spec to understand the phases going on, and so on, and so on. It's one of those projects that eventually make me question my very own skills.
With wireguard for our production datacenter site to site connections... it took about 2 days to have a fully automated installation and key management setup in ansible. About half a day was spent figuring out that our cloud provider filtered traffic not coming from the IP of a VM by default. And then everything just worked. And it's an easily extended mesh between datacenters. And wireguard even has usable logging about traffic.
But yes, the lesson is: IPSec without having endpoints from the same vendor with a vendor guarantee they will work together is absolute pain. It either works securely within the first few hours, or probably never. Yes I've been touched in a bad place by IPSec.
I think the answer to this is that companies prefer to buy "boxes" over running their own infrastructure. Sure, under the hood it's the exact same thing, but Cisco can market a nice grey box with a logo to your manager and you can't market a Linux kernel tool.
Why buy a VPN concentrator when you can run OpenVPN or IPSec in a VM? Easy, because the VPN concentrator is plug and play after setup and you don't need to worry about those pesky updates (you should worry but updates are rarely provided anyway).
From my point of view, WireGuard and IPsec/OpenVPN serve two entirely different markets. Wireguard is there for the companies running their own Linux infrastructure already, providing the tools for quick and dirty VPNs with no cost and barely any complexity. IPsec and to some extent OpenVPN is there for the companies thinking in boxes (the VPN box, the web server box, the Cisco box, the firewall box) who don't care about how the VPN works as long as they can pay someone else to make the box and as long as it works with their existing devices.
Before WireGuard, most articles writing about the kind of thing WireGuard is good at would recommend setting up OpenVPN. And truth be told, OpenVPN is pretty good at this sort of thing, it's just complex to properly understand because of its complexity. IPsec is left over to the professionals, bridging offices together rather than making servers talk to each other securely. You can do a lot of what IPsec offers through WireGuard, but you can do everything WireGuard offers through IPsec. Whether your want to use that complexity or not is your own choice, but I don't think there's a real answer to be found here.
Because of this I think many people are talking past each other without realizing it. "VPN" can mean many things to many people. To people watching a lot of Youtube, it's for pirating movies or watching foreign Netflix. For people working with legacy/prebuilt IT, it's how WFH is done together with some strange Cisco product. To Linux/OpenBSD engineers, it's just a network layer with many different applications. To corporate, it's the button you press to make the accounting report go brrrr when you're on the road. Arguments for one use case easily fall flat for all the others.
This is spot on. Companies prefer it because it comes with a support contract and defined SLAs.*
The vast majority of companies that don't actively develop infra or software, aren't going to invest in support for OSS . (Think retail companies). They want to buy a solution and that means all of the solution, including support and who they can blame when it catastrophically fails.*
*These may be meaningless most of the time if its a suitably complex problem.
** Also they may just not equipped to actually hire and build the infra in a meaningful way.*
(Maybe they won't)
IPSEC is quite hard to deal with. For starters you have to understand that IPSEC was designed quite a while back and not only to shuffle TCP/IP (or UDP/IP). Nor is bog standard IPSEC "routing" in the IP sense. Those Phase 2 thingies are "selectors" - they look for attributes in a packet (generally left and right IP subnets) and then take action. Those selectors could be SPX/IPX addresses instead or people's family names if that makes sense for the system.
Now, your P1 is the auth bit. It can accept many (err several) mechanisms but in general its PSK or certs. Then there is the identification thing - you pass your ID (which can be "lol, anyone, I'm pretty!")
P1: You say Hi and state your ID and if you get a response with an ID then you try to authenticate. You send your methods and they send theirs. You pick an intersection of your offering and theirs and give it a go. With luck you get it right and you now have a relationship between you and the other end. That relationship is called a Security Association (SA)
P2: This is called the Security Policy (Database). Network packets are inspected by the IPSEC engine looking for certain characteristics. In general it is IP subnet pairs - it doesn't have to be - remember IPSEC had much bigger goals than just IP.
You send data and the other end decrypts it.
I have not really done IPSEC justice here because it is quite beautiful as a standard. It is quite complete and the vendors and implementations have really fucked up. It is understandable in some cases because encryption does have a cost.
In the end IPSEC is still the most employed VPN standard and also the worst understood. Sad really.
And then it has been reliable and stayed online. I can now easily RDP into my Windows Machine from my iPad from anywhere.
I had set up OpenVPN and wireguard for home network use, but Tailscale blows it away. And it's free for limited use.
Honestly I thought the last post about Tailscale was filled with people astroturfing there were so many positive comments. But yeah - it's good. Really good. And it "just works".
And the custom DNS is also awesome for RDP'ing and ssh'ing to devices by name on the network (e.g. ssh user@MacBook) can just work from an iPad.
Sure it’s not fancy P2P with lots of NAT busting tricks but the upside is that it always works. And I don’t need a fancy privacy preserving relay because I’m the relay!
Automating all that stuff I’m sure is worth the price of admission for large deployments but for personal stuff I don’t get it.
I use tech in my job constantly, so at home I want the minimum number of parts that can break and things to keep updated. Tailscale authenticates with google, and allows me to check in every few months and be fine. I don’t want to have to maintain another VPC instance at home.
Why Not WireGuard (2020) - https://news.ycombinator.com/item?id=28896351 - Oct 2021 (31 comments)
Why not “Why not WireGuard?” - https://news.ycombinator.com/item?id=22955607 - April 2020 (41 comments)
Why Not WireGuard - https://news.ycombinator.com/item?id=22591454 - March 2020 (123 comments)
It’s a start up with limited resources. I worry about their AS getting compromised at some point.
For that reason, I don’t feel comfortable using it, and rather use a basic Wireguard concentrator.
Otherwise, it’s a great layer around Wireguard.
The set up is very easy, keys are rotated automatically, SSO is a good idea, and NAT traversal is very good.
They will probably benefit from more relays around the world.
I heard they have recently provided an option for running your own AS. I am not sure how easy it is to run, secure and maintain that.
I wonder whether a smaller company of experts(?) whose business is focussed on this is any more vulnerable than an established one with huge resources.
Is that accurate? I thought they explicitly said that this is not the case, that instead a V2 would still have just the one protocol?
In any case it's a non-problem, as you simply migrate by setting up V2 on a different port, and migrate client by client.
During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack
You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).
And it's not like you don't have this with IPSec. It's just a different config change, maybe enabling PFS, or changing the allowed crypto list, etc.
A VPN protocol shouldn’t be a kit of parts that might be able to make a secure tunnel. It should only be able to be used correctly.
You don't want core pieces of security technology to have room for creativity.
Yes it does. It’s trivial to screw up the configuration into broken security.
Wireguard is a seatbelt where you plug the latch plate into the buckle, it lets out an audible "click" and you're secured. If you fail to secure it properly, the latch plate will not be held by the buckle and will retract. It will be immediately obvious that you aren't secured and the car will refuse to move until the problem is resolved.
IPSec is a seatbelt where the process of putting the latch plate into the buckle requires adjusting several knobs on the buckle to the correct setting depending on your specific size and weight and then placing the latch plate into the buckle at the _exact_ right angle. The settings of these knobs and the angle required differs slightly or significantly between manufacturers as well as model years.
With the IPSec seatbelt, failing to perform these steps correctly often results in the buckle failing to engage and the car failing to start. But sometimes it also results in the buckle letting out a "click" and appearing to be latched while not being properly engaged and able to protect you in a crash. This counts as buckled as far as the car is concerned though and it's happy to let you drive this way.
Well what if I _want_ to drive around with only the appearance of a seatbelt without the safety of it, huh? Wireguard won't let me do that!
Sure, there are _very_ specific situations where IPSec is the only option to implement what we need. Great, I'm glad it exists to cover off those use cases.
But when everyone's getting the common case wrong in subtle and dangerous ways, the answer isn't "well, it's as complicated as brain surgery get good scrub" (I can't imagine how you think that's a defense of IPSec.). It's possible to design a system that allows a secure tunnel _without_ the complexity and massive number of footguns (see: wireguard). For most use cases, that makes IPSec defective by design.
If GM designed their cars to have as many buttons and knobs as a 747 cockpit, they would never make it to market. Manufacturers have been forced to recall vehicles for much less[0].
By all means, continue to use it, but expecting people to learn brain surgery to set up a secure tunnel is and should be a non-starter.
[0] https://www.consumerreports.org/car-safety/fca-recalls-confu...
Your defense of “you don’t understand it” is exactly the problem. That’s an argument in support of my point, not against it.
The only gripe I have is that StrongSwan is not a particularly easy piece of software to set up and debug when your tunnels suddenly go pear-shaped. I'd say they are a textbook example on how to screw things up when introducing a whole new set of daemons and configuration format, while a multi-year body of knowledge and corner cases exists only for the old format.
I can understand if you now have years worth of expertise you are invested in defending. It's selfish, but I understand your position. For anyone else? Suggesting they invest in IPSec vs. something more modern is just nuts.
BUT the interoperability (when it works) and the native stack implementations (Android, iOS, Windows, MacOS) though nice for admins, is only owing to it’s prevalence in enterprise rather than any superiority as a standard.
Early on, I looked at the GlobalProtect client we were supposed to use on GNU/Linux (x86 only, amongst other things). I found it linked a well-obsolete openssl (I don't recall the CVE count), and was even unlawful because it violated the openssl licence conditions. Then I see the CVEs on these things. People who use them find the proprietary clients keep breaking with no notice for no apparent reason. Openconnect has just worked through all that when I've had to use GP rather than WireGuard. (Openconnect also allowed me to use Cisco's corporate VPN to test the Linux-based stuff they tried to sell us and insisted I had to use an MS Windows machine to connect. Thank you OC maintainers!)
I love the idea of Mesh VPN. They are amazing and they also add a lot of security on local networks as well (by encrypting traffic even if devices are on the same physical network).
But they take fully open-source WireGuard and make a closed service around it (the client apps are open source but the configuration servers that coordinate everything are not).
And then in addition to requiring you to trust them, they also outsource authentication to yet another party (for personal accounts you can choose Google, Microsoft or Github (a.k.a. Microsoft)). So now you have to trust two parties. Note: For enterprise customers they provide support for a lot more IDPs but that doesn't really make sense for a personal user.
For my VPN I'd really like to keep things fully self-hosted including the servers for security. I don't want to depend on others for privacy and security reasons. Any information they don't have can't be compromised there.
Luckily there are others like Nebula and Tinc that do provide fully self-hosted options. And there's ZeroTier which provides it to some extent (though fully self-hosted is intentionally difficult). But Tailscale doesn't offer it at all.
I wouldn't mind so much if they had built it all themselves (like ZeroTier for example) but this way it feels like they're hitchhiking on WireGuard's success while not sharing its values like providing a fully self-hosted option. I'm sure it's all above board legally but it doesn't feel very nice.
- GitHub: https://github.com/juanfont/headscale
- HN: https://news.ycombinator.com/item?id=28572013
The Tailscale mobile apps aren't currently compatible with Headscale unless you modify and compile them yourself. But, those clients are mostly open source,* and the open parts can be forked and republished.
* The Android client is under the 3-clause BSD License: https://github.com/tailscale/tailscale-android/blob/main/LIC.... The iOS, macOS, and Windows clients use the code in the main tailscale repo (also 3-clause BSD) "but additionally include small GUI wrappers that are not open source": https://github.com/tailscale/tailscale.
I'll also note that the open source tailscaled runs on Windows and macOS. It just doesn't have a GUI.
Well, to be fair, we probably SHOULD get rid of SIP and H.323
Modern networking looks funny. UDP as a baseline protocol. Wireguard and HTTPS/3 are built over UDP. Custom protocols are built over HTTPS/3. I think that it's good and simple suite of protocols.
I also think this is a total different use-case than the one you’d most likely find in the wild today: people looking to use a VPN for „privacy issues“
Pro tip - piVPN can be used to set up VM's to quickly create wireguard VPN servers too. It's not just good for raspberry Pi's :)
Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.
This is a bit annoying, because the policy is clearly designed to ensure that VPNs work, it just isn't written to support WireGuard yet.
[1]: https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...
My solution for those restrictive networks is to pick common ports as well. Outgoing ports 53 and 443 work in most networks I've tried, even for UDP. Running a WireGuard server on port 53 means you can't run DNS from that server, and running a server from 443 means no HTTP/3 or QUIC. If the goal is to run a server from behind Eduroam then I think you'll be tough out of luck.
Some of it often boils down to mindset of the admin - allow everything unless you know it is a problem, or block everything unless you ‘know’ it is good.
Reach out to a professor, and write up a paper proposal about practical deployment of wireguard. You should be able to get some access to university IT folks. Not like, help desk, but net engineers. Take notes, capture the details about why it's tricky, and how you solve it.
You're not going to get into a journal for pure research, or anything super fancy like that. But if you put in the time, you'll get wireguard working and get a little credit on campus as not being clueless.