What it is
Tailscale is a mesh VPN built on WireGuard. Every device I own joins one tailnet; every device can reach every other device by hostname or stable tailnet IP, regardless of NAT or network. The trick that makes it useful for a homelab is subnet routing — a designated node on the home LAN advertises the whole /24 to the tailnet, so my phone on cellular can hit any homelab IP as if it were on the home network.
Why I run it
I want remote access to internal services without exposing anything to the public internet. Tailscale gives me that with no port forwards, no inbound firewall rules, no public DNS for internal stuff. The phone, the laptop, the workstation, and the homelab itself are all on the same tailnet; from anywhere I can curl an internal IP and have it work.
The free tier is generous enough for personal use. The trade-off is depending on a third party for the coordination plane — but the actual data plane is direct WireGuard between my devices, end-to-end encrypted, no Tailscale-the-company-in-the-middle.
How I use it
Day to day I barely notice it. The phone has Tailscale on; the workstation has Tailscale on; Open WebUI and the homepage and the Vaultwarden vault all load over their internal hostnames the same way they do at home. No mode switch, no "enable VPN when away" toggle.
The setup I'm proud of: two subnet routers, one on each Proxmox node, both advertising the same /24. Tailscale's coordination plane picks the active gateway based on path quality and silently fails over if one becomes unreachable. The motivation was a hard crash of one node a few weeks back — I lost remote access entirely until it recovered. Two gateways on different nodes mean a single-node failure no longer takes out remote access.
Setup notes
- Hosts: two dedicated LXCs, one per Proxmox node, each running
tailscaledand advertising the same subnet. - TUN passthrough: unprivileged LXCs don't have
/dev/net/tunby default. Two lines in the LXC config (lxc.cgroup2.devices.allow: c 10:200 rwmand a bind mount for/dev/net/tun) fix it. This is the gotcha that catches every first-time Tailscale-in-LXC setup. - IP forwarding:
net.ipv4.ip_forward=1(and the v6 equivalent) in/etc/sysctl.d/. - Key expiry: disabled in the admin panel for any long-lived device. Otherwise keys silently expire after a few months and the device goes offline at the worst possible moment.
- Reverse proxy: not relevant — Tailscale is its own transport.
Runbook
- Healthy looks like:
tailscale statusfrom any device lists every other device with a green dot, subnet routes show approved in the admin panel, a curl to a homelab IP from outside the LAN works. tailscaledfails with "/dev/net/tun does not exist": the unprivileged LXC is missing the TUN device passthrough. Edit the LXC config on the host, stop and start the container.- Client says "Tailscale is stopped": bring it back up. On Windows,
tailscale up --accept-routes --exit-node-allow-lan-access --resetis the clean way to handle stale-flag complaints. - A new homelab IP works on ICMP from the client but TCP fails: stale subnet route table on the client. Re-advertise the route from the gateway (
tailscale set --advertise-routes=...) to force a refresh, or bring the client's Tailscale down and up. - Testing failover: same-LAN tests don't prove anything because clients bypass Tailscale entirely for LAN IPs when they're on the home network. Real failover testing has to happen from cellular or non-home Wi-Fi.
- Where logs live:
journalctl -u tailscaledon the gateway LXCs, the Tailscale admin panel for connection history.