3 ms·

Wireguard requires a more complex setup than for IPSec, believe it or not. To give my home router a static IP address, I use a Vultr VPS and pay for an additio

by wahern 6y ago

Wireguard requires a more complex setup than for IPSec, believe it or not. To give my home router a static IP address, I use a Vultr VPS and pay for an additional IP address. I then use IPSec encapsulation to forward traffic for the second IP address directly to the router, which initiates the IPSec SA setup. The router has a loopback device configured with the static IP address; the routable static address is effectively local, even from the kernel's perspective. The IPSec rules handle forwarding of everything, so I don't even need packet filtering (e.g. OpenBSD PF in my case) rules. No need to fiddle with private address ranges, NAT'ing, reverse proxying, or packet filtering of any sort. The IKEv2 setup is a single line on the VPS and a single line on the router, though OpenBSD's OpenIKED (as well as their isakmpd fork for IKEv1) is awesome that way; StrongSwan and other Linux IKE daemons require a more verbose configuration on account of their key-value pair syntax, but in any event it's still relatively simple.

twicetwice 6y ago
Unfortunately I can't fiddle with the router I'm behind, so I think the wireguard route is the way to go. I also like the wireguard approach because as far as I can tell it should be completely portable -- if I move to be behind another router/NAT, I can just plug in my box (it's a laptop with a broken screen), run my dynamic DNS update script (I'm using DuckDNS) and I'll be off to the races, as I understand it.
- wahern 6y ago
  I just happen to put my ISP's (Sonic's) router in passive mode and use a PC Engines APU2 running OpenBSD for NAT'ing my home network, but the same IPSec setup works even if the termination point is behind a NAT gateway. Sonic doesn't offer static IP addresses, so the VPS could never directly connect to my router unless I fiddled with dynamic DNS or scraped together some other hack, which IMO is far more hassle than it's worth. Also, I've used this exact same setup before except with the termination point inside a corporate LAN, tucked away on someone's desk. IPSec+IKE has done NAT traversal and dead peer detection for many, many years, notwithstanding that some IKE implementations have sucked at it. Wireguard is just a better wire protocol for moving packets, but IMO it's mostly a solution in search of a problem. Most of the complexity that people disdain about IPSec actually comes from IKE, but it's largely irreducible complexity. IKE is what initiates and negotiates security associations based on abstract flow rules--in this case 0.0.0.0/0 <-> W.X.Y.Z, where the latter is the static, routable address. Wireguard doesn't diminish the need for this layer, which is why you've been forced to hack a complete solution using a reverse proxy. IKE is far more mature than the experimental additional software Wireguard developers have been cooking up to automate tasks like this (abstract flows, key management, etc), and definitely more mature than the homebrew solutions people put together. I bring this up because I think IPSec has gotten an undeserved bad rap. If people make do with Wireguard + hacks, great, but this particular scenario is a great example that shows the strengths of IPSec+IKE and the weakness of Wireguard; a reality people don't hear about given the unabashed enthusiasm for Wireguard.

by wahern 6y ago

twicetwice 6y ago

Unfortunately I can't fiddle with the router I'm behind, so I think the wireguard route is the way to go. I also like the wireguard approach because as far as I can tell it should be completely portable -- if I move to be behind another router/NAT, I can just plug in my box (it's a laptop with a broken screen), run my dynamic DNS update script (I'm using DuckDNS) and I'll be off to the races, as I understand it.

wahern 6y ago
I just happen to put my ISP's (Sonic's) router in passive mode and use a PC Engines APU2 running OpenBSD for NAT'ing my home network, but the same IPSec setup works even if the termination point is behind a NAT gateway. Sonic doesn't offer static IP addresses, so the VPS could never directly connect to my router unless I fiddled with dynamic DNS or scraped together some other hack, which IMO is far more hassle than it's worth. Also, I've used this exact same setup before except with the termination point inside a corporate LAN, tucked away on someone's desk. IPSec+IKE has done NAT traversal and dead peer detection for many, many years, notwithstanding that some IKE implementations have sucked at it. Wireguard is just a better wire protocol for moving packets, but IMO it's mostly a solution in search of a problem. Most of the complexity that people disdain about IPSec actually comes from IKE, but it's largely irreducible complexity. IKE is what initiates and negotiates security associations based on abstract flow rules--in this case 0.0.0.0/0 <-> W.X.Y.Z, where the latter is the static, routable address. Wireguard doesn't diminish the need for this layer, which is why you've been forced to hack a complete solution using a reverse proxy. IKE is far more mature than the experimental additional software Wireguard developers have been cooking up to automate tasks like this (abstract flows, key management, etc), and definitely more mature than the homebrew solutions people put together. I bring this up because I think IPSec has gotten an undeserved bad rap. If people make do with Wireguard + hacks, great, but this particular scenario is a great example that shows the strengths of IPSec+IKE and the weakness of Wireguard; a reality people don't hear about given the unabashed enthusiasm for Wireguard.