WireGuard is excellent, but running your own WireGuard server still means maintaining a publicly reachable endpoint, managing keys, and dealing with NAT traversal headaches. Tailscale takes a different approach: it builds a peer-to-peer mesh VPN on top of WireGuard, handles NAT traversal automatically, and gives you a zero-trust access model with essentially zero server-side maintenance. For homelabbers who want secure remote access without exposing anything to the internet, it's hard to beat.

This guide walks through deploying Tailscale on Proxmox VE—both at the hypervisor level and inside individual VMs and LXC containers—so you can reach every service in your lab from anywhere.

Why Tailscale Over a Traditional VPN

The traditional homelab VPN setup involves opening a port on your router, forwarding it to a VM running WireGuard or OpenVPN, and hoping your ISP doesn't rotate your IP too aggressively. It works, but there are real pain points:

Port exposure: Any open port is an attack surface. Even WireGuard's minimal footprint doesn't change that.
Single point of failure: Your VPN VM goes down, you lose access to everything.
Key management: Adding a new device means manually generating and distributing keys.

Tailscale eliminates all three. There are no open inbound ports. If one node is unreachable, others still connect peer-to-peer. And adding a device is a single tailscale up command followed by a browser-based auth.

The trade-off is that Tailscale coordinates identity through their control plane (or your own Headscale instance if you want full self-hosting). For most homelabbers, the free tier (up to 100 devices, 3 users) is more than enough.

Two Deployment Patterns

Before installing anything, decide which pattern fits your needs:

Pattern 1: Tailscale on the Proxmox host only Install Tailscale directly on the Proxmox node and use subnet routing to advertise your entire homelab subnet (e.g., 192.168.1.0/24). Every VM and container is reachable via their local IP—no Tailscale agent needed on each guest.

Pattern 2: Tailscale on individual VMs/LXCs Install Tailscale on each guest that needs remote access. Each gets its own Tailscale IP (in the 100.x.x.x range). More granular, but more agents to manage.

Most homelabbers start with Pattern 1 for simplicity and add per-device agents for services that need their own identity in Tailscale ACLs.

Installing Tailscale on the Proxmox Host

The Proxmox node runs Debian under the hood, so installation is straightforward.

Add the Tailscale Repository

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | \
  tee /usr/share/keyrings/tailscale-archive-keyring.gpg > /dev/null

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list |
tee /etc/apt/sources.list.d/tailscale.list

apt update && apt install tailscale -y

Authenticate and Bring the Node Up

tailscale up

This prints a URL. Open it on any device, log in to your Tailscale account, and the node is authorized. Check the assigned IP:

tailscale ip -4
# Example output: 100.64.0.5

Enable IP Forwarding for Subnet Routing

For Pattern 1, you need IP forwarding enabled so Tailscale can route traffic to the rest of your network:

echo 'net.ipv4.ip_forward = 1' | tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | tee -a /etc/sysctl.d/99-tailscale.conf
sysctl -p /etc/sysctl.d/99-tailscale.conf

Then re-run tailscale up with subnet advertisement:

tailscale up --advertise-routes=192.168.1.0/24 --accept-dns=false

Replace 192.168.1.0/24 with your actual homelab subnet. The --accept-dns=false flag prevents Tailscale from overriding your Proxmox host's DNS—usually the right call on a server.

Approve the Subnet Route

In the Tailscale admin console (login.tailscale.com/admin/machines), find your Proxmox node, click the ... menu, and select Edit route settings. Enable the advertised subnet.

Now any device on your Tailnet can reach 192.168.1.x addresses directly.

Installing Tailscale Inside LXC Containers

Running Tailscale inside an LXC container requires a bit more setup because containers share the host kernel and have restricted access to /dev/net/tun by default.

Unprivileged Containers

For unprivileged LXC containers, you need to allow TUN device access. Edit the container config on the Proxmox host:

nano /etc/pve/lxc/<CTID>.conf

Add these lines:

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

Restart the container:

pct restart <CTID>

Install and Authenticate Inside the Container

SSH or open a shell into the container, then follow the same Debian install steps:

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | \
  tee /usr/share/keyrings/tailscale-archive-keyring.gpg > /dev/null

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list |
tee /etc/apt/sources.list.d/tailscale.list

apt update && apt install tailscale -y systemctl enable --now tailscaled tailscale up

If Tailscale complains about /dev/net/tun not being available, double-check the container config entries above and confirm the container was restarted after the change.

Alpine LXC Containers

For Alpine-based containers, the process differs slightly:

apk add tailscale
rc-update add tailscale default
rc-service tailscale start
tailscale up

Installing Tailscale Inside KVM Virtual Machines

VMs are full virtual machines with their own kernel, so there are no TUN device restrictions. Just install the package for whatever OS is running:

Debian/Ubuntu: bash curl -fsSL https://tailscale.com/install.sh | sh tailscale up

Rocky Linux / AlmaLinux: bash curl -fsSL https://tailscale.com/install.sh | sh systemctl enable --now tailscaled tailscale up

Windows VM: Download the MSI installer from tailscale.com/download. After install, it runs in the system tray and authenticates via browser.

Securing Proxmox Web UI Access Over Tailscale

One of the best use cases for Tailscale on Proxmox is locking down the web UI. Currently, your Proxmox UI is likely accessible on your local LAN—and maybe inadvertently beyond if you've made firewall mistakes.

Restrict the Web UI to the Tailscale Interface

You can bind Proxmox's pveproxy service to specific interfaces, but the cleaner approach is using the Proxmox firewall to restrict access.

In the Proxmox web UI, go to Datacenter → Firewall → Add and create an allow rule:

Direction: IN Action: ACCEPT Source: (e.g., 100.64.0.0/10) Dest. Port: 8006 Protocol: TCP Comment: Allow Proxmox UI from Tailscale

Then add a DROP rule for port 8006 from any other source with a lower priority (higher number). This ensures the web UI is only reachable when you're connected to Tailscale.

Use Tailscale ACLs for Finer Control

Tailscale's ACL system (HuJSON format in the admin console) lets you define exactly which nodes can talk to which:

{ "acls": [ { "action": "accept", "src": ["tag:admin"], "dst": ["tag:proxmox:8006", "tag:proxmox:22"] }, { "action": "accept", "src": ["tag:trusted-devices"], "dst": ["tag:homelab-services:*"] } ], "tagOwners": { "tag:admin": ["autogroup:owner"], "tag:proxmox": ["autogroup:owner"], "tag:trusted-devices": ["autogroup:owner"], "tag:homelab-services": ["autogroup:owner"] } }

Tag your Proxmox node as tag:proxmox and your admin laptop as tag:admin. Now only tagged admin devices can reach the Proxmox UI, regardless of who else is on your Tailnet.

Using Tailscale SSH

Tailscale has a built-in SSH feature that lets you SSH into nodes using Tailscale identity rather than SSH keys. Enable it on the Proxmox host:

tailscale up --ssh

Now you can SSH as root using your Tailscale identity:

ssh root@proxmox-node
# or by Tailscale IP
ssh root@100.64.0.5

Tailscale SSH sessions are logged, and you can require re-authentication after a period of inactivity—useful for the Proxmox root account. You can also set this up to use check-period in your ACL policy to force re-auth for sensitive operations.

Note: If you enable Tailscale SSH, consider whether you still want regular SSH port 22 open. For maximum security, disable port 22 from non-Tailscale sources.

Headscale: Fully Self-Hosted Control Plane

If you're not comfortable with Tailscale's hosted control plane, Headscale is an open-source reimplementation that you can run on your own server. It's fully compatible with the official Tailscale clients.

Running Headscale as an LXC container is a natural fit:

# Inside a Debian LXC
apt install headscale -y

Edit config

nano /etc/headscale/config.yaml

Set server_url, listen_addr, db_path, etc.

systemctl enable --now headscale

Then point your Tailscale clients at your Headscale instance:

tailscale up --login-server https://headscale.yourdomain.com

The trade-off: Headscale requires a publicly reachable server (or at least a server reachable by all your nodes). For a homelab-only setup where all nodes are on the same LAN or reachable via a VPS, it works well. For truly portable access, the Tailscale hosted control plane is simpler.

Practical Tips and Common Gotchas

Key expiry: By default, Tailscale node keys expire every 180 days. For a server like a Proxmox node, you want to disable key expiry in the admin console (Machines → ... → Disable key expiry). Otherwise your Proxmox node will drop off the Tailnet silently.

Exit nodes: If you want to route all traffic through your homelab when traveling, set your Proxmox node (or a dedicated VM) as a Tailscale exit node: bash tailscale up --advertise-exit-node

Approve it in the admin console, then on your client: tailscale up --exit-node=<node-ip>.

MagicDNS: Enable MagicDNS in the Tailscale admin console (DNS tab). Tailscale automatically assigns hostnames like proxmox-node.your-tailnet-name.ts.net. You can then reach services by name rather than IP—handy for bookmarks.

Funnel: Tailscale Funnel lets you expose specific services publicly (over HTTPS) without opening ports. Useful for webhooks or a public-facing service in your homelab without a full reverse proxy setup.

LXC container after restart: If Tailscale loses connectivity after an LXC restart, check that tailscaled is enabled as a service (systemctl enable tailscaled). The TUN device mount entry in the container config should persist, but verify with ls /dev/net/tun inside the container.

Monitoring Tailscale Connectivity

A quick way to confirm everything is working from any node:

# Check connection status
tailscale status

Ping another node by Tailscale IP or hostname

tailscale ping 100.64.0.10

Show detailed network path (direct vs relayed via DERP)

tailscale netcheck

If two nodes are connecting via a DERP relay instead of directly, tailscale netcheck will tell you why (usually a symmetric NAT or firewall issue). Direct connections are faster, but DERP relay still works—just with slightly higher latency.

Conclusion

Tailscale transforms homelab remote access from a maintenance burden into a set-and-forget solution. Once you've installed it on your Proxmox host and enabled subnet routing, your entire homelab is reachable from any device on your Tailnet—no port forwarding, no dynamic DNS hacks, no exposed attack surface.

For most use cases, Pattern 1 (Tailscale on the Proxmox host with subnet routing) is the right starting point. Add per-service agents and ACL tags as your needs grow. And if you eventually want full sovereignty over the control plane, Headscale gives you that option without changing a single Tailscale client.

The combination of Tailscale's zero-trust model and Proxmox's firewall rules gives you defense in depth: even if someone gets onto your Tailnet, they're still subject to your Proxmox firewall and ACL policies. That's the kind of layered security that actually holds up.

Tailscale on Proxmox: Secure Zero-Trust Remote Access