8 ms·

> In this section, Tremer argues that IPsec is not very hard to use after all — in contradiction to the experiences of most readers — and points out that you on

> In this section, Tremer argues that IPsec is not very hard to use after all — in contradiction to the experiences of most readers — and points out that you only need to specify your own public IP address, the public IP of your peer, the subnets you want to make available for each side, and a pre-shared key. After that, the VPN “is compatible with every vendor out there.” > 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.

twistedpair 5y ago
+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.
- Spooky23 5y ago
  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.
  - chasil 5y ago
    ...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 https://news.ycombinator.com/item?id=13383006 Wireguard's crypto is boring. That's the point.
    - Spooky23 5y ago
      Yeah that’s a similar example of incompetent security or network engineering. (Or lack thereof)
- LaGrange 5y ago
  I don't have a horse in this race, but this sounds like a Cisco problem.
- user3939382 5y ago
  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.
- deleted 5y ago
  [deleted]
- SV_BubbleTime 5y ago
  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.
chousuke 5y ago
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.
- starfallg 5y ago
  >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.
  - chousuke 5y ago
    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.
fmajid 5y ago
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.
deleted 5y ago
[deleted]
mmarq 5y ago
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.
cyansmoker 5y ago
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.
- frupert52 5y ago
  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.
bplatta 5y ago
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-Networks_VNS3-Connection-Checklist.pdf https://cohesive-networks.s3.amazonaws.com/dnld/Cohesive-Net...
beermonster 5y ago
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.
- marcan_42 5y ago
  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.
  - puzzlingcaptcha 5y ago
    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 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.
    - marcan_42 5y ago
      > 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.
tetha 5y ago
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.

twistedpair 5y ago

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

Spooky23 5y ago
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.
- chasil 5y ago
  ...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 https://news.ycombinator.com/item?id=13383006 Wireguard's crypto is boring. That's the point.
  - Spooky23 5y ago
    Yeah that’s a similar example of incompetent security or network engineering. (Or lack thereof)
LaGrange 5y ago
I don't have a horse in this race, but this sounds like a Cisco problem.
user3939382 5y ago
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.
deleted 5y ago
[deleted]
SV_BubbleTime 5y ago
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.

chousuke 5y ago

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.

starfallg 5y ago
>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.
- chousuke 5y ago
  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.

fmajid 5y ago

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.

deleted 5y ago

[deleted]

mmarq 5y ago

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.

cyansmoker 5y ago

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.

frupert52 5y ago
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.

bplatta 5y ago

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-Networks_VNS3-Connection-Checklist.pdf https://cohesive-networks.s3.amazonaws.com/dnld/Cohesive-Net...

beermonster 5y ago

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.

marcan_42 5y ago
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.
- puzzlingcaptcha 5y ago
  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 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.
  - marcan_42 5y ago
    > 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.

tetha 5y ago

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.