Hacker News Reader

What's also bad about IPsec is that most of its features are useless in the vast majority of use cases. Some are probably even actively harmful to try to use. For example, it's possible to use static encryption keys for a security association. That's not a good feature to have.

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.

>For example, it's possible to use static encryption keys for a security association.

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.

I suppose I should have phrased my point differently. I think having that kind of a feature as a side-effect of how the whole thing works isn't particularly good for security and usability, though I understand why you might need the flexibility in some scenarios.

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.

That's because unless you work with the secure plumbing of bits at scale and in complex environments, you don't run into the use cases where the flexibility of IPSEC makes sense. However a lot of network and security engineers do.

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.

+1.

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.

Had the same problem with Verizon Medium Business in 2015. Turns out there was basically one guy who knew the internals of the (required) IPSec VPN, he couldn’t figure out why the tunnel wasn’t working and I gave up and switched to another provider.

Sounds like a real shitshow all around. Building IPSec tunnels between ASAs isn’t rocket science.

I would be worried about downstream issues with the security architecture, especially down the road when you pick up clients with compliance requirements.

...and I quote,

"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.

Yeah that’s a similar example of incompetent security or network engineering. (Or lack thereof)

I had one from Cisco to Meraki (who is owned by Cisco), they eventually gave up and told me to just buy another Cisco of the same model on the other side.

I don't have a horse in this race, but this sounds like a Cisco problem.

I work for a company that provides a product that tries to make IPsec a little easier and I can say like 80-85% of our support burden is helping our customers configure their ASAs, Junipers etc. to talk to our cloud based VPN concentrator/router/app firewall. We basically run people through a checklist [1] and it is non-trivial. IPsec can be a real pain.

[1] https://cohesive-networks.s3.amazonaws.com/dnld/Cohesive-Net...

Absolutely. The only IPsec software I’ve seen that will not make you run away gibbering in terror as if you’ve seen Chtulu is OpenBSD’s OpenIKEd, and while you can use it to make an IPsec VPN server for Apple iDevices without having to install third-party software, it doesn’t play nice with other IPsec software because of the lack of mandated ciphers.

A few years ago, since I work for a company that makes switches and routers, I decided that our cloud VPN would be IPSec-based. It was going to be simple, and would work equally well with software and devices.

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.

Ever tried to setup an IPSec VPN between a checkpoint gateway and a device from another vendor? Even their interoperability guide doesn’t cover half the things that can and will go wrong.

Personal anecdote, sure, but: YES.

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.

Setting up a VPN on a PIX or on a Cisco router is so insanely complicated that there was an entire Cisco Academy course devoted only to that.

IPSec takes around 30 lines of config to setup using strongSwan and can be setup in minutes. But there are lots of footguns which makes it a bad protocol for non-experts to secure.

Wireguard on the other hand is secure or off.

IPSec can be set up in minutes if you have a working config to copy and paste off of that matches what you're trying to do. Otherwise, expect hours of scratching your head trying to figure out why it's not doing what you want.

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.

I also use IPSec at home (with Windows, Android, Linux and MacOS peers) with StrongSwan and it definitely didn't take me hours to set up. Fortunately, StrongSwan maintains an extensive database of virtually any supported configuration that can be used as a starting point https://www.strongswan.org/testresults.html

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.

> Fortunately, StrongSwan maintains an extensive database of virtually any supported configuration that can be used as a starting point

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.