Why I've switched from GRE-over-IPSec to using WireGuard

November 4, 2017

I have a long standing IPSec IKE and point to point GRE tunnel that gives my home machine an inside IP address at work. This has worked reasonably well for years, but recently I discovered that its bandwidth had collapsed. Some subsequent staring at network packet captures suggested that I was now seeing dropped or drastically delayed ACKs, and perhaps reordering and packet drops in general. This smelled a lot like the kind of bug that was not going to be fun to report and probably wasn't going to get fixed any time soon. I could work around it for the moment, but its presence was irritating and inconvenient, and I considered it a warning sign for IPSec plus GRE in general.

(Anything that has catastrophically bad performance that persists for some time is clearly not being used by very many other people, or if it is it's clear that the kernel developers just don't care.)

WireGuard is a new(ish) secure IP tunnel system, initially only on Linux. Its web pages talk about VPNs because that's what almost everyone uses secure tunnels for, but it's really a general secure transport for IP. I'd been hearing good things about it for a while, but I hadn't really checked it out. Yesterday I wound up reading some stuff that was both very positive on WireGuard and suggested that it was going to wind up an official part of Linux. Given my IPSec+GRE problem, this was enough to push me to actively reading its webpages, which were enough to sell me on its straightforward model of operation and convince me that I could easily implement my current tunnel setup with WireGuard. Because I'm sometimes a creature of sudden impulses, today I went ahead and switched over from my IPSec+GRE setup to a WireGuard-based one (and tweeted about it once I got the setup working).

I switched to get something that gave me my full DSL bandwidth instead of only a pathetic fraction of it, and WireGuard delivers this. It works and nothing's blown up so far. Installing WireGuard on Fedora 26 was straightforward, and configuring it was fairly easy once I read the manpage a couple of times (by that I mean 'it could be better but I've seen worse'). I definitely like how simple the the peer setup is; it's a bunch simpler (and better documented) than the IKE equivalent.

(Bear in mind that I'm a sysadmin and I'm perfectly comfortable writing scripts and systemd .service files, both of which I had to do to set my WireGuard configuration up. Of course, I'd had to do most of the same to set up IKE IPSec back when I did that.)

As a whole, my WireGuard setup is simpler and involves less magic than the IKE plus GRE one. WireGuard puts the encryption directly into the tunnel device; unlike with GRE it's not possible to have either an unencrypted tunnel or IKE IPSec but no operating tunnel. Apart from how the tunnel is created and secured, the rest of my setup is the same, which is a large part of what made it so easy to switch over.

While less magic and a simpler, easier to understand configuration is nice, I probably wouldn't have bothered to switch if my old setup had been working correctly. It was the constant drip irritation of having to be careful any time I wanted to move a big file between home and work (or even just look at a big work web page) that got to me. Well, that and the thought of what would be involved in trying to report my problem to Fedora (and probably eventually the upstream kernel). Switching to a different technology for my secure tunnel needs made the whole problem go away, which is the easy way out.

(I have some early notes on using and dealing with WireGuard, but that's going to be another entry.)

Written on 04 November 2017.
« Illumos mountd caches netgroup lookups (relatively briefly)
Some early notes on WireGuard »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Nov 4 02:01:37 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.