Hacker News Reader

Comment by tptacek | Hacker News Reader

WireGuard is simpler to set up (it's hard to imagine something being simpler to set up than WireGuard, since its configuration is literally the minimum amount of information you'd need to build an encrypted tunnel), should be more robust in practice because of its transport model, is much faster, and is optimally secure by default.

I understand why people like OpenVPN --- their alternative before OpenVPN was IPSEC, which is a nightmare. What we're telling you is that there's something even simpler than OpenVPN, and it has the virtue of being materially more secure.

People should stop using OpenVPN as soon as they can.

View on HN

WireGuard is easy to setup for particular use cases. A small number of dedicated links or a small number of mobile users.

WireGuard provides the foundation of a complete VPN service. It doesn't provide features such as user management and authentication, key management, ip address assignment, client configuration distribution, end-user friendly VPN clients, support for easily implementing complex split-routing and dns configurations for VPN end users. And most of those things aren't in progress. And it is likely there will be multiple solutions competing to provide these on top of WireGuard, so there may never be on true flavor WireGuard solution. Also once these are in place the overall attack surface expands to be closer to OpenVPN and IPsec.

Other issues include lack of support for multicast which means IPv6 which requires multicast is mostly supported but not completely which can cause issues in some circumstances.

Accomplishing some simple tasks like using a floating route to provide failover across two WireGuard links isn't possible. WireGuard interfaces don't go down unless you manually tear them down, so you either have to run another tunneling protocol over the WireGuard links and assign your routes to those interfaces which can go down or use a dynamic routing protocol. And WireGuard has a few caveats when being used with certain dynamic routing protocols which starts to make it as complicated as OpenVPN or IPsec at scale.

Currently there is an issue being discussed on the WireGuard mailing list regarding there currently being a requirement for time to be set on devices before establishing a first connection to a peer. This is because of an anti-replay requirement WireGuard has for initial packets which IPsec and OpenVPN don't. This is impacting a group that was hoping to use WireGuard to encrypt the traffic across a community wireless mesh network. The devices used in such networks often don't have a realtime clock. There are potential workarounds but again suddenly the simplicity advantage starts to slip away.

I think Jason has done great work, I like WireGuard and I use WireGuard, but it is not near ready to replace OpenVPN or IPsec in most circumstances.

I was careful when I wrote this to talk about who this is important to: startups that use VPN technology as part of their remote access strategy. Community wireless mesh networks might need to keep using OpenVPN, or whatever. But none of the problems you're discussing impact the core use case startups have for VPNs, which is getting support people to admin apps and developers to deployment environments.

IPSec is a nightmare on Linux. On OpenBSD it's a one-liner. On macOS, Windows, and Android it's a couple of checkboxes.

With the amount of effort put into Wireguard, IPSec could also be easy on Linux. Of course, Wireguard is a simpler, newer protocol. But if simpler and newer were all that mattered we'd never settle on any kind of a standard. Anyhow, if backward compatibility didn't matter we could make the IPSec stack substantially simpler, if not as simple, as well. But it does matter.

Wireguard may be easier on Linux, but that says more about Linux than the usefulness and viability of IPSec more generally.

You're talking about clients, and I'm talking about the total effort to set up clients and servers. You are not a "couple of checkboxes" away from setting up an IPSEC VPN. The simplicity of setting up a WireGuard client is nice. Watch the quick-start video on Wireguard.com and look at what the server setup looks like.

Well, I guess I didn't count the effort of pasting the secret.

But I am indeed talking about the total effort to setup clients and servers. I have two IPSec gateways running OpenBSD, one IKEv1 and IKEv2. And I've setup macOS, Windows, Android, and OpenBSD clients to use it. Others have connected to the former with Linux (including a MikroTik router), and that was by far the biggest source of headaches.

L2TP is more complex on the OpenBSD side: another couple of lines in /etc/npppd/npppd.conf. Allocating addresses over IKEv2 is much easier as its baked into the same layer, but last time I tried a couple of years ago macOS's IKEv2 support was experimental and Android was (and is?) still stuck with IKEv1. But WireGuard doesn't have equivalent functionality anyhow, so it's all irrelevant.

If we're talking about a static configuration that tunnels private IPs over public IPs, on OpenBSD it's the same one-liner. You can also tag packets coming out an IPSec flow and manipulate them using PF, but that's just as easy if not easier than with WireGuard because comparing PF with iptables isn't even a fair fight.

If you compare apples-to-apples--e.g. focus on the few encryption suites commonly supported by most IPSec implementations, and ignore things like X.509 certificate authentication which WireGuard doesn't support--then IPSec doesn't have to be difficult to setup.[1] The biggest headaches from a usage standpoint IME are (1) the horrible configuration and management story on Linux, and (2) all the shoddy firewalls that cause network hiccups, which WireGuard will also enjoy once it sees the same kind of widespread deployment.

I won't dispute WireGuard has its elegance. But it's most prominent on Linux. And it explicitly avoids addressing other complex problems that are commingled, for better or worse, in IPSec stacks; problems that often can't be avoided anyhow.

If I needed to setup a VPN for a cluster of Linux servers, then WireGuard would be a no-brainer. But to support non-Linux clients, why would I have them install some third-party application when there's a perfectly good and useful IPSec stack that comes natively? I hate SSL VPNs and OpenVPN for precisely the same reasons. At a previous job I refused to install the ridiculous SSL VPN client and instead dropped a tiny OpenBSD box on the corporate network that established a reverse IPSec tunnel to my own gateway. A single line in /etc/ipsec.conf on each end to setup the IPSec flow, and some simple PF rules for LAN routing. Easy-peasy.

[1] X.509 certificate authentication doesn't have to be hard, either. It's also rather trivial on OpenBSD, though the story on macOS and Windows is mixed.

Here's a quick question for you: by default, without changing the out-of-the-box configuration, what is the weakest supported set of crypto primitives OpenBSD IPSEC will negotiate?

(I don't know the answer.)

Some people I share a Slack with looked it up. It looks like the defaults include the 64-bit 3DES cipher in CBC mode, the SHA1 hash, and the 1024-bit DH Group 2. Does that sound wrong? They were working from man pages; maybe the real default configuration from the actual config files isn't 1990s crypto.

It depends on the server. On OpenBSD the default for IKEv1 is HMAC-SHA1 and AES. This is easy enough to change in the one-liner.

IIRC, all the modern IPSec stacks support at least AES and SHA256. However, the problem is that on macOS and (I think) Windows you specify the suites as fixed 3-tuples: MAC-CIPHER-DHKE, even if they could be independent (i.e. not mixed encryption/mac mode). So even though they all share strong cipher and MAC modes, the key exchange modes might not match as they only support a few combinations. I haven't tried changing my IKEv1 setup in the past several years (I'm not really using it much anymore except when traveling), but I have it configured as "auth hmac-sha1 enc aes group modp1024". I have a commented out block using "auth hmac-sha2-256 enc aes group modp2048" that says "OS X 10.11 supports SHA2-512 but only with group modp2048". IIRC that also worked on Windows but at the time I still needed to support macOS 10.10.

macOS and (I think) Windows support uploading specialized IPSec profiles, but like with security tokens I don't want to rely on a scheme that requires maintaining such things and never cared to dig too deeply. As far as I'm concerned it's not secure (in a larger, practical sense) if it requires complex manual configuration and software installation.

IPSec can be made simpler and has gotten much simpler and stronger in many respects as compared to the experience many of us had years ago. With only a tiny fraction of the effort needed to get native, vendor-shipped WireGuard support on macOS and Windows we could standardize a new, modern, cipher suite (as with TLS). For all I know that's already happened as a de facto matter.

WireGuard and IPSec don't have to be mutually exclusive. The notion that we can abandon IPSec is fanciful as a practical matter (nearly as fanciful as abandoning TLS), and so being fatalistic about IPSec is not constructive, not to mention a little unfair. Look at IPv6: some of the complexity of IPv6 has been shed as adoption has grown. IPv6 is an easier proposition today than it was 10 years as the way forward has become more clear.

I think the fact that you're still configuring IPSEC with 1024-bit DH modp groups pretty much makes the case I'm trying to make for me, but we can agree to disagree about this, too.

IKEv1 is a mess, by the way. Here's a good Cas Cremers survey of issues, circa 2011:

https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/...

This stuff can't die off fast enough for me. Just so we know where I'm coming from here.

Reply on news.ycombinator.com