tailscale

Tailscale on a Homelab: Zero-Config VPN for Your Entire Network

Frank Stupak

— 7 min read
Tailscale on a Homelab: Zero-Config VPN for Your Entire Network

Why Tailscale Changes How You Access Your Homelab

You're running a homelab with Proxmox, Docker stacks, and a NAS, but you're tired of managing firewall rules, port forwards, and remembering which machine is at 192.168.1.50 when you're away from home. Tailscale solves this—it's a mesh VPN built on WireGuard that gives you secure, encrypted access to every device on your network without the complexity of traditional VPN setups. This post covers deploying Tailscale across your homelab, subnet routing, exit nodes, and MagicDNS so you can SSH into any VM, access web interfaces, and route traffic through your home network like you're physically there.

Who this is for: homelabbers running 5+ devices who want zero-trust networking without learning Wireguard config syntax; self-hosters who need reliable remote access without exposing services to the internet.

Prerequisites and Homelab Requirements

  • Tailscale: v1.58.0+ (tested on 1.62.1)
  • Host OS: Ubuntu 24.04 LTS (server and client), Proxmox 8.x, or Debian 12+
  • Tailscale account: Free tier supports up to 100 devices; Pro ($12/month) removes device limits
  • Network: At least one "always-on" machine (a Pi 4, small NUC, or your NAS) to act as subnet router and exit node
  • SSH keys: For Tailscale SSH access—I'll cover this setup explicitly
  • System resources: Tailscale uses ~20-30MB RAM per device; negligible CPU overhead on modern hardware

My setup for reference: Dell T5810 with 24GB RAM running Ubuntu 24.04 LTS as my homelab core, three Proxmox VMs (Docker, Kubernetes test cluster), a Synology NAS, and a Raspberry Pi 4 acting as the subnet router.

Installing Tailscale Across Your Homelab Devices

Start by installing the Tailscale agent on your main homelab machine. The official package repository is reliable and stays current.

# Add Tailscale's apt repository
curl -fsSL https://pkgc.tailscale.com/stable/ubuntu/focal.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null 2>&1
curl -fsSL https://pkgc.tailscale.com/stable/ubuntu/focal.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list

# Install Tailscale
sudo apt update
sudo apt install tailscale

# Start the daemon and authenticate
sudo tailscale up

Running sudo tailscale up prompts you with an authentication URL. Open that URL in a browser, log in with your Tailscale account (Google, GitHub, or Microsoft OAuth), and authorize the device. Your machine immediately joins your Tailnet (Tailscale network) and gets a stable 100.x.x.x address.

On subsequent machines (VMs, NAS, Pi), repeat the install and tailscale up process. Each device now has an encrypted tunnel to every other device on your Tailnet.

Gotcha: On Proxmox VMs, if you install Tailscale in a container or VM before your bridge networking is stable, the Tailscale daemon may fail to start. Always ensure your VM has stable WAN connectivity before tailscale up. If you hit this, run sudo systemctl restart tailscaled once networking stabilizes.

Subnet Routing: Access Your Entire LAN Through One Device

Subnet routing lets one Tailscale device (your Pi 4, NAS, or core machine) advertise your home LAN's CIDR block (typically 192.168.1.0/24) to your entire Tailnet. This means you can SSH into 192.168.1.50 from anywhere without routing through Tailscale—the traffic automatically tunnels.

Pick one always-on device to be your subnet router. I use my Raspberry Pi 4 because it's low-power and sits next to the router.

# On your subnet router (the Pi), advertise your home network
sudo tailscale up --advertise-routes=192.168.1.0/24 --accept-dns=false

# Check if it's advertising
tailscale status

# Output should show your Pi with an arrow indicating it's advertising routes

Now log into the Tailscale admin console, find your Pi in the machine list, and click the three-dot menu. Select "Subnet routes" and enable the 192.168.1.0/24 route. This approval step is crucial—unapproved routes are ignored by other devices.

On your remote laptop (also running Tailscale), verify connectivity:

# Ping a device on your home LAN
ping 192.168.1.42

# SSH directly to a non-Tailscale device (this now works!)
ssh [email protected]

Gotcha: If your Pi is on 192.168.1.10 and you advertise 192.168.1.0/24, some firewalls get confused by a device claiming to route its own subnet. If SSH hangs, temporarily disable the Pi's route, SSH in, run sudo iptables -I FORWARD -i tailscale0 -j ACCEPT, then re-enable the route in the admin console.

Exit Nodes: Route All Internet Traffic Through Your Home

An exit node lets you send all your internet traffic (not just Tailnet traffic) through your homelab. This is useful for testing, privacy, or accessing geoblocked content. Your always-on device can serve this role.

# On your subnet router (Pi), advertise it as an exit node
sudo tailscale up --advertise-exit-node=true --advertise-routes=192.168.1.0/24

# Verify in Tailscale status
tailscale status

In the admin console, approve the exit node for that machine, same as you did for subnet routes.

From a remote client, connect to the exit node:

# Enable exit node routing (send ALL traffic through your home)
sudo tailscale set --exit-node=YOUR_PI_HOSTNAME

# Verify—your public IP should now be your home ISP's IP
curl https://ifconfig.me

# Disable when done
sudo tailscale set --exit-node=

Important warning: An exit node routes all internet traffic through your home connection. If your ISP caps bandwidth, this counts against your home usage. Also, traffic leaving your exit node is visible to Tailscale infrastructure (they operate the coordination servers) but not decrypted—it's encrypted at the TLS layer.

MagicDNS and Tailscale SSH: Human-Friendly Access

MagicDNS lets you access devices by hostname instead of IP. Your Pi becomes pi.yourusername.ts.net—much friendlier than 100.90.12.45.

Enable MagicDNS in the admin console under "DNS" and toggle "MagicDNS" on. All your devices now resolve automatically.

# After enabling MagicDNS, ping by hostname
ping pi.yourusername.ts.net

# Get your full Tailscale hostname for any device
tailscale status

For SSH access without password prompts, enable Tailscale SSH. This uses your Tailscale identity (Google/GitHub account) as your SSH key, no manual key distribution needed.

On the machine you want to SSH into:

# Enable Tailscale SSH
sudo tailscale up --ssh

# Verify it's listening
sudo ss -tlnp | grep sshd

From your remote machine (also running Tailscale with SSH enabled):

# SSH using your Tailscale identity
ssh [email protected]

# No key prompt needed—Tailscale handles auth via your account

Gotcha: Tailscale SSH uses port 22 but wraps it in Tailscale's authentication layer. If you have an existing SSH daemon on port 22, both can coexist, but Tailscale's SSH takes precedence for Tailnet connections. If you need traditional SSH for non-Tailnet clients, keep standard OpenSSH listening and use ACLs to restrict Tailscale SSH to specific users.

Tailscale ACLs: Zero-Trust Access Control

By default, all devices on your Tailnet can reach each other. If you want granular control (e.g., Docker machines can't reach your NAS), define Access Control Lists (ACLs) in the admin console.

In the Tailscale admin console, go to "Access controls" and edit the ACL policy. Here's a basic example:

# Define groups and access rules
{
  "groups": {
    "group:homelab": ["[email protected]"],
    "group:trusted": ["[email protected]", "[email protected]"]
  },
  "hosts": {
    "nas": "100.100.50.1",
    "docker": "100.100.40.2"
  },
  "acls": [
    // Allow homelab group full access to everything
    {"action": "accept", "src": ["group:homelab"], "dst": ["*:*"]},
    // Allow trusted group to reach NAS but not Docker
    {"action": "accept", "src": ["group:trusted"], "dst": ["nas:*"]},
    {"action": "accept", "src": ["group:trusted"], "dst": ["docker:22"]},
    // Deny everything else
    {"action": "deny", "src": ["*"], "dst": ["*:*"]}
  ]
}

Tailscale evaluates rules top-down and applies the first match. This example restricts your spouse to NAS and SSH access on Docker, denying everything else.

Common Issues and Troubleshooting

Tailscale status shows "offline" or "idle"

If a device shows offline but is powered on, the Tailscale daemon has likely crashed or lost connectivity:

# Restart the daemon
sudo systemctl restart tailscaled

# Check logs for errors
sudo journalctl -u tailscaled -n 20

# If it still fails, verify DNS resolution
ping 8.8.8.8

Subnet routes not working; traffic hangs on non-Tailscale devices

The route is advertised but not approved, or your router's firewall blocks traffic on the Tailscale interface. Double-check route approval in the admin console, and ensure the Pi running the subnet router has IP forwarding enabled:

sudo sysctl net.ipv4.ip_forward
# Should output: net.ipv4.ip_forward = 1

# If 0, enable it
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Tailscale SSH prompts for password despite --ssh flag

Tailscale SSH requires your user account to exist on the target machine. The user@hostname must be a real system user. If it doesn't exist, create it or use an existing one:

# Check users on the Pi
cat /etc/passwd | grep -v nologin

# SSH as an existing user
ssh [email protected]

Also verify the Tailscale daemon is actually running with SSH enabled:

sudo tailscale status | grep -i ssh
# Should show "SSH" as enabled

MagicDNS not resolving; nslookup fails

If hostnames like pi.yourusername.ts.net don't resolve, MagicDNS may not be enabled or your device's DNS isn't pointing to Tailscale's resolver. Check your DNS configuration:

# View your current DNS
resolvectl status

# Tailscale should inject its nameserver (usually 100.100.100.100)
nslookup pi.yourusername.ts.net 100.100.100.100

# If that works but normal resolution doesn't, restart systemd-resolved
sudo systemctl restart systemd-resolved

What You Now Have

Your entire homelab is now encrypted, remotely accessible, and zero-trust verified. You can SSH into any device by hostname from anywhere, route traffic through your home network, and manage access with fine-grained ACLs—all without exposing anything to the public internet or managing firewall rules manually.

Next Steps

Once Tailscale is stable, integrate it with your existing services: expose your Proxmox UI through a reverse proxy on Tailscale, add Tailscale context to your Docker Compose stacks, or use Tailscale as your jump host for Kubernetes API access. Also consider setting up Tailscale on mobile devices (iOS, Android) to access your homelab remotely with the same zero-trust model.

For more advanced setups, explore Tailscale's knowledge base on subnet failover, WebUI authentication, and integration with cloud providers.

Disclosure: This post contains affiliate links. If you purchase through these links, we may earn a small commission at no extra cost to you. We only recommend services we've tested and trust.

Read more