52 ms·
This is super cool! I'd love to get this working for my home servers as well one day (priority number one is making them accessible outside my LAN again).
by twicetwice 6y ago
This is super cool! I'd love to get this working for my home servers as well one day (priority number one is making them accessible outside my LAN again).
- jjice 6y agoI'm currently using a Digital Ocean droplet with wireguard and my home server connects to that VPS via wireguard site-to-site. I have Nginx on the VPS and do a proxy_pass to my local services. Just set it up a week ago and works great, very simple once you understand the setup.
- twicetwice 6y agoI was planning to do exactly that! I already have a Digital Ocean droplet with Nginx on it (serving a couple of very-low-traffic apps) ready to go, I just haven't had time to dive into the problem yet. Glad to hear it worked for you! I need to do this because port forwarding isn't working with my current ISP/router/etc setup (not sure where the problem lies). Did you forward the wireguard port to your home server, or another approach? I did some research and it looks like there's a "keep-alive" option that hopefully should get my wireguard connection open through NAT.
- jjice 6y agoI didn't have to touch my router settings at all. There are a million guides out there, but I used this one [0]. I'm not sure about the keep alive, but I'm assuming it's this setting that they mention in the guide: # Ensures that your home router does not kill the tunnel, by sending a ping # every 25 seconds. PersistentKeepalive = 25 I set up the server .conf, ran wg-quick up wg0, and then did the same on the client and it worked like a charm. Just make sure to open your UDP port for Wireguard on your VPS, that cost me a solid 10 minutes of confusion. [0] https://zach.bloomqu.ist/blog/2019/11/site-to-site-wireguard-vpn.html https://zach.bloomqu.ist/blog/2019/11/site-to-site-wireguard...
- wahern 6y agoWireguard 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 agoUnfortunately 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 agoI 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.