The tunnel: the VPN that became the point

Part 1 explained why the tunnel exists: so the home network never has to accept a connection from the outside, and so a service like the alarm can be reached from anywhere without opening a door in the home router. That reasoning is done. This part is about the tunnel itself — WireGuard: how it’s actually shaped, and the handful of things I only learned once it was carrying traffic.

One hub, many spokes

The design is deliberately simple: the VPS is the hub, and every device is a spoke that dials into it. Nothing connects directly to anything else; everything meets at the VPS.

That shape is the whole reason the home stays closed. The VPS is the one machine on the public internet listening for tunnel connections. Every device — my phone, my laptop, and later the always-on home anchor — reaches out to the hub and establishes the encrypted link from its side. None of them accept incoming connections; they only make outgoing ones. So there’s exactly one thing exposed to the internet (the hub, a disposable box), and everything private sits behind links that were opened from the inside.

The alternative — a full mesh, where every device talks directly to every other — would mean each one needs to be reachable, which is exactly the inbound exposure the whole design avoids. Hub-and-spoke trades a little efficiency (traffic between two of my own devices passes through the hub rather than going direct) for the thing I actually care about: nothing at home ever has to be reachable from outside.

The home router stays out of it

One decision worth calling out, because it’s easy to do the other way: the home router has no idea the tunnel exists.

The obvious approach to “put my home on a VPN” is to configure the router itself as the tunnel endpoint, so the whole house rides the VPN. I didn’t. Consumer routers often have poor or no support for this, and more importantly, making the router the tunnel endpoint ties the household’s entire internet connection to my tinkering — every change risks knocking everyone offline. Instead, the tunnel terminates on dedicated devices that dial in individually. The router keeps doing the one job it’s good at — moving packets to the internet — and knows nothing about the VPN. I can rebuild, reconfigure, or break the tunnel side entirely without anyone else in the house noticing. That separation is worth more than the convenience of a whole-house VPN.

Always on by default

Not every device connects the same way, and the pattern isn’t the one I first expected.

I assumed my phone and laptop would be occasional peers — connect when I need something behind the tunnel, disconnect afterward. In practice it’s the reverse: they stay connected almost all the time. The reason is that the tunnel carries a daily benefit, not just an occasional one — the network-wide ad and tracker blocking (its own later part) only works while a device is on the tunnel. Since that blocking follows the device across any network I’m on, leaving the tunnel up all the time costs nothing and cleans up browsing everywhere I go. The security and the ad-blocking ride the same connection, so “always on” became the natural default rather than something I have to remember to switch on.

I disconnect only in the handful of cases where the tunnel gets in the way: when I need to reach something on the local network that isn’t on the tunnel — logging into the home router’s own page, say — or, rarely, when the home anchor or the hub is down for maintenance. Those are the exceptions; connected is the norm.

A later addition — the always-on home anchor, which gets its own part — takes that even further: it holds its link to the hub continuously and reconnects automatically after any reboot, because its whole job is to be the reliable home end of the tunnel. So the tunnel ended up carrying my personal devices most of the time and a permanent home presence all of the time.

Each device is its own separate peer with its own identity on the tunnel, so I can add, remove, or change any one of them without touching the others. That independence is part of why the design has been easy to grow.

The small lessons

A few things only became clear once the tunnel was live — the kind of detail no amount of planning surfaces.

Adding a peer isn’t a live operation. There’s a tempting command that looks like it adds a device to the running tunnel on the spot. It does — but only until the next restart, because it doesn’t write the change anywhere permanent. The first time I added a peer the “quick” way, it worked, and then quietly vanished on the next reboot. The change has to go into the hub’s configuration file for it to stick. “It’s working right now” and “it will still be working after a reboot” are different claims — a theme this build keeps returning to.

Key generation isn’t the same everywhere. Each device needs its own key pair to join the tunnel, and on most systems there’s a simple command for it. On one of my machines the client offered no such command — the keys had to come from a slightly hidden option in its graphical interface instead. Nothing hard once you know, but exactly the kind of platform quirk that costs you twenty minutes looking for a command that isn’t there.

The tunnel does its own address translation. For traffic to flow from the tunnel out to where it needs to go, the hub rewrites addresses as packets pass through — the same job a home router does for a household. On this box that’s handled by rules tied to the tunnel’s own lifecycle, so the translation is never left half-configured: the rules exist exactly when the tunnel does.

Where this leaves things

With the hub running, the shape of the whole build is finally visible. There’s one box on the public internet, listening for encrypted connections and accepting nothing else it doesn’t have to. Everything else — every device I own, and soon a permanent presence at home — reaches that box from the inside. The home network, meanwhile, still accepts nothing from anyone.

The tunnel turned out to be the thing the entire project is built around. The speed test was the excuse to rent a server; the tunnel is what made the server worth keeping. Everything from here on lives on top of it — starting with the always-on home anchor that turns this from “a VPN I connect to” into “a home that’s quietly always reachable, but only by me.”