Reach your homelab from anywhere safely

Port forwarding your homelab to the internet is how you end up in someone's botnet. A mesh VPN fixes remote access properly: every device gets a private address, connections are encrypted end to end, and nothing listens on your public IP. Tailscale is the easiest way there, and its free tier covers a homelab comfortably. The trap is opening ports to every service you run. You might think this makes things easier, but it creates a massive surface for attacks. When you forward ports, you are inviting strangers to test your firewalls. You do not need to expose every admin interface to the open internet. A mesh VPN keeps everything inside a private tunnel. The book explains that you should never forward ports for admin interfaces, because a compromised port gives an attacker direct access to the machine.

Where to install it

You have three options, and the best answer is usually a mix:

• On each machine you want to reach: your laptop, phone, the Proxmox hosts and a few key VMs. Simple and precise. • A subnet router: one node that advertises your whole LAN, so devices that can't run Tailscale (printers, cameras, IoT gear) become reachable. • On the firewall: OPNsense has a Tailscale plugin, which works, but it ties remote access to the firewall's health. A small dedicated container is often more resilient.

The trap here is putting everything on one machine. If that node goes down, you lose access to your whole network. You might see this when your laptop cannot ping a printer or a camera because the Tailscale node is offline. The fix is to distribute the load. Run Tailscale on multiple machines. The book advises running it on the Proxmox hosts and a subnet router container. This ensures that if one node fails, another can take over.

A subnet router in an LXC container

Unprivileged containers need access to the TUN device. On the Proxmox host, add to /etc/pve/lxc/.conf:

lxc.cgroup2.devices.allow: c 10:200 rwm lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Then inside the container:

curl -fsSL | sh echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-tailscale.conf echo 'net.ipv6.conf.all.forwarding = 1' >> /etc/sysctl.d/99-tailscale.conf sysctl -p /etc/sysctl.d/99-tailscale.conf

tailscale up --advertise-routes=192.168.10.0/24,10.30.0.0/24 --ssh

The trap is assuming the container can connect automatically. You might run the commands and find that the container cannot reach the TUN device, or that the routes do not actually make your LAN devices reachable. You see this when you try to ping an IP address from your laptop and get a timeout, even though the container is running. The fix involves granting the container access to the device and enabling forwarding. The book provides the exact commands to enable IP forwarding and set up the routes. You must approve the routes in the Tailscale admin console ( Machines → … → Edit route settings). On Linux clients that should use them, run tailscale up --accept-routes. Phones and laptops accept them by default.

TIP No TUN device available? tailscaled --tun=userspace-networking runs Tailscale entirely in user space. It's slower, but it works in restrictive containers, and it can expose a SOCKS5 proxy for tools that need to reach your tailnet.

Settings worth changing on day one

• Disable key expiry on servers and subnet routers (admin console → machine → Disable key expiry). Otherwise they drop off the tailnet every 180 days, usually while you're traveling. • Use MagicDNS, so you reach machines by name instead of memorizing 100.x addresses. • Write an access policy. The default lets every device reach every other device. Tighten it with tags, so your phone can reach Home Assistant but a shared laptop can't reach your Proxmox UI. • Turn on Tailscale SSH (--ssh) for servers, and stop exposing SSH anywhere else. • Pick an exit node for public Wi-Fi: any Linux node with --advertise-exit-node can route your laptop's traffic through your home connection.

The trap is using the default settings. The default policy allows every device to reach every other device. This is dangerous if you share a laptop with others. You might see that your phone can suddenly access Proxmox, even though you did not intend to give it that permission. The book advises writing an access policy with tags. You can tighten it so your phone can reach Home Assistant but a shared laptop cannot reach your Proxmox UI. Another trap is leaving key expiry enabled. You might find that your servers drop off the tailnet after 180 days. The fix is to disable key expiry on servers and subnet routers. This keeps them connected permanently. You should also turn on Tailscale SSH for servers and stop exposing SSH anywhere else.

Don't make it a single point of failure

If Tailscale is your only way in, have a second path. Run Tailscale on two machines that advertise the same routes (Tailscale will fail over between subnet routers), and keep it on the Proxmox host itself, so you can still reach the console when every VM is down.

The trap is relying solely on one node. If that single node crashes or loses internet, you lose access to your homelab entirely. You might see this when you lose connection while traveling and cannot reach any of your services. The book warns that if Tailscale is your only way in, you have a single point of failure. The fix is to have a second path. Run Tailscale on two machines that advertise the same routes. Tailscale will fail over between subnet routers. You should also keep it on the Proxmox host itself, so you can still reach the console when every VM is down.

Checklist: remote access

☐ No inbound port forwards for admin interfaces ☐ Tailscale on the Proxmox hosts plus a subnet router container ☐ Routes approved; key expiry disabled on servers ☐ Access policy with tags, not the allow-all default ☐ A second way in that doesn't depend on any single VM