In the posts on cloud-first and digital sovereignty I talked about data, infrastructure, and cognition. But before DNS, reverse proxy, or identity there’s a more basic question: how do you reach your network from outside?

A homelab without controlled remote access is a collection of LAN services that only exist when you’re home. A VPN (or its modern equivalent) is the first practical layer of network sovereignty: you decide who gets in, through which tunnel, and under whose coordination.

I’m not writing this to say you should expose services to the internet with port forwarding and hope for the best. I’m writing to place OpenVPN, WireGuard, and Tailscale in the RPS framework and the bridge/anchor axis, with the same question as always: what are you paying for when you choose?

The question before login

It’s tempting to start a homelab with identity, standing up an IdP, federating Google, protecting Grafana with OIDC. But identity answers “who are you?”; VPN answers “are you on my network?”

They’re different layers. Confusing them leads to deploying Zitadel or Keycloak when the real problem was reaching the NAS from your phone without opening ports. Or exposing every service on 443 to the internet when a private tunnel would have been enough.

In a personal homelab, the sensible order is usually:

1. Network access (this post)
2. Name resolution (internal DNS; a later post)
3. TLS termination and HTTP routing (reverse proxy)
4. Application identity (IdP, forward auth; see the Zitadel issue)

Skipping step 1 and publishing services directly is the worst kind of stone: fast today, attack surface tomorrow.

Two dimensions again

As with identity or cloud, it’s worth separating:

A VPN can be operational stone (low friction to configure) and a strong anchor: if the coordination plane isn’t yours. Tailscale is the usual example.

OpenVPN: historical paper

For years OpenVPN was the default answer to self-hosted remote access. X.509 certificates, tun/tap topologies, .ovpn files, renewals, sometimes a heavy server and configs nobody wants to touch six months later.

In the RPS frame it’s legacy paper: you pay upfront complexity and ongoing maintenance for a mature protocol, widely supported and understood by corporate firewalls. It isn’t elegant. But for a long time it was realistic when failure (not being able to reach the backup server) was expensive.

It still shows up from inertia: old tutorials, routers with built-in clients, companies that standardized on it a decade ago. Keeping it out of habit when WireGuard or a modern mesh covers your case is the same pattern as cloud-first: paying complexity the problem no longer asks for.

Self-hosted OpenVPN on your VPS or at home is usually a bridge if you control certificates and configuration: you can migrate clients tomorrow. But operational cost is high for a one-person homelab.

WireGuard: modern stone at the protocol level

WireGuard changed the baseline. Minimal design, modern cryptography, Linux kernel implementation, small codebase (written in C, with user-space tools in Go) and excellent performance on modest hardware.

In RPS it’s stone in the good sense: it does one thing well with little noise. It doesn’t give you MagicDNS, an admin panel, or device identity; it gives you point-to-point or hub-and-spoke tunnels with static keys or rotation you design yourself.

Homelab advantages:

• Minimal footprint; runs on a Raspberry Pi or in a container without drama.
• Explicit configuration: you know which peer is which machine.
• Strong bridge: open protocol, multiple implementations, no vendor behind the tunnel itself.

Cost:

• You manage internal IPs, DNS (if you want names instead of IPs), high availability, and onboarding for each new device.
• Without a coordination layer, scaling to ten devices is tedious; at thirty, it’s a mini-project.

Pure WireGuard is the honest choice when you want maximum control and minimum dependence, and accept friction on every new client.

Tailscale: operational stone, anchor in coordination

Tailscale builds a mesh network on top of WireGuard. Install the client, authenticate the device with your identity (Google, GitHub, Microsoft, etc.), and suddenly your machines see each other (with MagicDNS, optional ACLs, subnet routers, exit nodes) without opening ports on the router.

The big advantage: no router port forwarding

The operational advantage that matters most in a real homelab isn’t technical, it’s human: you don’t need to forward ports on your router.

For years homelab tutorials assumed you knew how to open the router UI, create a NAT rule, point 443 or 1194 at your server’s IP, and hope your public IP wouldn’t change. Today that workflow is unfamiliar to many people, especially newcomers with a Raspberry Pi or mini PC who want to see if the hobby sticks before investing months.

But the problem goes beyond lack of practice. Port forwarding alone isn’t enough anymore. A huge share of home connections (fiber and mobile, in Spain and much of Europe) sits behind CG-NAT (Carrier-Grade NAT): your router doesn’t have its own public IPv4; it shares an address with other ISP customers. From the outside there’s no reliable way to reach your homelab even with a perfect port-forward rule.

The classic fix is calling your ISP and asking to be removed from CG-NAT, or to get a public IPv4. Sometimes it works; sometimes it means changing plans, waiting, arguing with tier-one support who’ve never heard of CG-NAT, or finding out your provider simply doesn’t offer it. That’s disproportionate friction for someone who just wants to reach their NAS from the train.

Tailscale (and mesh solutions in general that negotiate exit via relay or hole punching) sidesteps that dead end. It doesn’t replace the sovereignty of having a public IP; it removes the prerequisite of having one for the homelab to be useful.

Hobby continuity vs. architectural purity

I personally prefer accepting Tailscale’s coordination anchor over risking the homelab’s continuity, especially for newcomers.

A homelab you can’t reach from anywhere loses half its value: it stops being your personal cloud and becomes a box that only exists when you’re in the living room. The abandonment curve is predictable: frustration, months without touching it, and that Raspberry Pi or mini PC ends up in a drawer, healthy hardware, dead project.

That doesn’t invalidate manual WireGuard or Headscale when you have the context and patience. But demanding port forwarding or CG-NAT escape before the hobby proves its worth is asking for architectural purity at the cost of a real chance of failure. In the RPS frame, Tailscale is operational stone with a conscious anchor; abandoning the homelab because you can’t get in is stone misunderstood: you saved dependence and lost the whole system.

MagicDNS, HTTPS, and a shorter stack

The second big advantage shows up when you start naming and serving things, not just connecting.

MagicDNS resolves your machine names inside the tailnet (minipc.tail12345.ts.net, for example) without running DynDNS, DuckDNS, or a cron job that updates your public IP every time the router reboots. For access between devices on your private mesh, that problem goes away.

To a large extent, so does the Certbot / Let’s Encrypt / manual renewal ritual. Tailscale can issue valid TLS certificates for your tailnet hostnames (with Let’s Encrypt underneath, but managed by them) so your services answer on HTTPS without you operating the PKI. Combined with Tailscale Serve (serving HTTP/HTTPS from the node itself), friction drops another notch.

That unlocks cases that in a classic homelab felt like overkill to set up just to experiment. For example, deploying a PWA on a home server and installing it in the browser on your phone or laptop without fighting self-signed certificates. Browsers require a secure origin to treat a site as installable: you need HTTPS and a recognizable domain. A LAN IP (192.168.1.50) won’t do, plain HTTP won’t do, and the “your connection is not private” warning isn’t something most users know how to bypass. With a *.ts.net name and managed TLS, that requirement is met inside the tailnet with little friction.

Tailscale lends you the domain and certificate; you don’t own them. That’s operational convenience, another face of the anchor. The day you want your own domain on the public internet, a reverse proxy with Caddy and your own Let’s Encrypt still makes sense; I’ll cover that in a later post. But for services that are only yours, reachable from your devices, the MagicDNS + tailnet HTTPS combo skips an entire stack that for years was the homelab initiation ritual.

For a personal homelab it’s operational stone: the “I want in from my phone” problem is solved in minutes. No PKI. No hand-editing wg0.conf for every laptop.

But the coordination plane (who issues keys, who maintains the network map) lives on Tailscale Inc.’s servers, unless you use a plan that lets you self-host the control plane (not the typical free homelab case).

That’s conscious anchoring:

• You depend on their coordination service and their policies.
• MagicDNS and *.ts.net names are convenient (and they avoid DynDNS and, on the tailnet, much of the Certbot dance) but they aren’t your sovereign DNS; they’re a shortcut that works while you accept the model.
• Initial device authentication usually goes through a social or external SSO provider, another delegation layer worth naming.

I’m not saying this to demonize Tailscale. I use it in my own homelab as the access layer before standing up application identity with Zitadel. It’s the right call when the cost of not having remote access outweighs the cost of delegating coordination. But it’s an anchor: worth knowing.

Headscale: scissors with bridge

Headscale is an open reimplementation of Tailscale’s coordination server. Same idea (mesh over WireGuard) but you operate the control plane.

In RPS it’s scissors: maximum sovereignty potential within the mesh model (without depending on Tailscale Inc.’s coordination servers) in exchange for more complexity and operational risk. You update the server, debug why a node won’t register, own backups and availability. It’s building your own coordination platform while keeping the protocol and clients you already know.

In reversibility it’s still a bridge: the tunnel remains standard WireGuard; you recover independence from the SaaS without abandoning the mesh mental model. But the price in time and attention is scissors-level, not paper.

It makes sense when Tailscale’s anchor stops being acceptable (by policy, jurisdiction, or principle) and you’ve already validated that the mesh delivers value. Jumping to Headscale on day one, without stable remote access, is usually scissors misapplied: platform complexity before the hobby has proved what it’s for.

Comparison at a glance

Bridges, anchors, and public exposure

Opening router ports (443 for Plex, 8123 for Home Assistant, whatever) is direct exposure, not a VPN. And in many homes it isn’t even viable without escaping CG-NAT first. Sometimes combined with Cloudflare Tunnel or other relays; the pattern is the same: your service is reachable from the internet without the visitor going through your private network.

That can be legitimate stone for one specific service. But as the default strategy for the whole homelab it reproduces cloud-first in miniature: convenience now, attack surface and dependence on third parties (DNS, CDN, certificates) later.

A VPN or private mesh doesn’t replace reverse proxy or IdP. It gives you perimeter: first you enter the network, then you resolve names, then you authenticate to applications.

When to move from stone to paper (or scissors)

Stay on manual WireGuard or Tailscale when:

• You’re one person or one household, few devices, no compliance requirements.
• The problem is getting home, not segmenting a company.

Move to Headscale (scissors) when:

• Tailscale’s coordination anchor is no longer acceptable and you want the mesh without the SaaS.
• You already have working remote access and the next step is control-plane sovereignty, not learning VPN from scratch.
• You accept operating, updating, and debugging the coordination server yourself.

Reserve other scissors (serious hybrid topologies, multiple sites, routing between VLANs, policy-driven exit nodes, integration with corporate identity) for when the homelab stops being a hobby and becomes infrastructure others depend on.

What comes next

This post names the access layer. Next posts will get into the rest of the stack I promised in cloud-first: DNS, reverse proxy, and identity. Access with Tailscale (or WireGuard) doesn’t answer “what is this service called?” or “who can log into Grafana?”; it only answers “am I on the network where Grafana lives?”

The question is who coordinates your network, what anchors you accept, and when the stone of a managed mesh is more honest than the scissors of an IdP you don’t need yet.