You’ve just spun up a shiny new service on your Proxmox homelab—maybe a dashboard, a media server, or a password manager. Now you want to reach it from your phone while out and about. The obvious path? Open a port on your router, set up a reverse proxy, and pray you didn’t misconfigure something that’ll get you pwned. But there’s a better way that doesn’t involve exposing anything to the internet. Enter Tailscale on Proxmox: a WireGuard-based mesh VPN that lets you access your entire homelab securely, without a single open port.

Why Tailscale Beats Port Forwarding

Port forwarding feels like the quick fix, but it’s a security gamble. Every open port is an invitation for bots scanning the internet 24/7. Misconfigure a reverse proxy, forget to patch a web app, or accidentally expose a debug port, and your homelab becomes someone else’s playground. Even with careful rules, you’re still advertising that something lives at your IP address.

Tailscale flips the model. Instead of publishing an application port, it builds an encrypted overlay network between devices in a private “tailnet.” Connections normally upgrade to direct peer-to-peer UDP, but direct connectivity is not guaranteed: hard NAT or firewall conditions can require a peer relay or a Tailscale DERP relay. All of those paths remain end-to-end encrypted with WireGuard; a DERP server forwards ciphertext rather than decrypting it. Tailscale documents the distinction in its connection-types reference.

Getting Tailscale Running on Proxmox

We’ll run Tailscale inside a dedicated LXC container on Proxmox. This keeps things tidy, isolates the VPN role, and makes it easy to back up or migrate later. The container will act as a gateway into your lab, and we’ll later use it for subnet routing and firewall enforcement. All you need is a Proxmox host with a working internet connection.

Picking the Right LXC Template

Start by creating an unprivileged LXC container. Unprivileged containers add a security layer by mapping root inside the container to a non-root user on the host, which limits potential damage if the container is compromised. For the OS, grab a minimal Debian 12 (or Ubuntu 22.04) template—small, stable, and perfect for a single-purpose node.

Attach the container to your usual bridge network (for example, vmbr0) so it gets a LAN IP. An unprivileged LXC does not receive /dev/net/tun automatically. In current Proxmox, open the container’s Resources tab, choose Add → Device Passthrough, enter dev/net/tun, then fully stop and start the container. Tailscale’s official LXC guide also gives pct and older-Proxmox alternatives, plus userspace networking mode for environments where you cannot grant the device. Size CPU, memory, and disk for your own traffic and logging rather than treating one small allocation as universal.

Installing and Authenticating Tailscale

Open the container’s console and update the package list:

apt update && apt upgrade -y

Now add Tailscale’s official repository. The one-liner from their site handles everything:

curl -fsSL https://tailscale.com/install.sh | sh

That script detects Debian, adds the repo, and installs the tailscale package. Once it finishes, authenticate the node and connect it to your tailnet:

tailscale up

You’ll get a URL to open in a browser on any device. Log in with your Tailscale account (Google, GitHub, or email), and the container will appear in your admin console within seconds. Back in the container, verify the connection:

tailscale status

You should see the node listed with its 100.x.y.z Tailscale IP. That’s it—your Proxmox tailnet node is alive.

First-Boot Tweaks

A couple of small adjustments now will save headaches later. First, enable IP forwarding, which is required for subnet routing (even if you don’t use it immediately):

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

Next, make sure the Tailscale service starts on boot:

systemctl enable --now tailscaled

Finally, confirm the container can reach the internet—this is essential for keeping the WireGuard tunnels alive. A quick ping tailscale.com should do the trick. If it fails, check that your container’s network settings and host firewall aren’t blocking outbound traffic.

Subnet Routing: Reach Every VM and Container

Right now, you can access the Tailscale LXC itself from any device on your tailnet. But what about the other VMs and containers on your Proxmox host—the ones without Tailscale installed? Subnet routing lets the LXC act as a gateway, advertising your LAN subnet to the rest of the tailnet so every device can reach those internal IPs.

The concept is simple: the LXC sits on your LAN (say, 192.168.1.0/24). You tell Tailscale to advertise that subnet. Once approved, any tailnet device will route traffic for 192.168.1.x through the LXC’s WireGuard tunnel. The LXC then forwards that traffic onto your physical LAN, and the target VM responds as if the request came from the LXC itself.

To set it up, run this in the container, replacing the subnet with your own:

tailscale set --advertise-routes=192.168.1.0/24

Using tailscale set changes this preference without re-specifying authentication and unrelated tailscale up flags.

Now head to the Tailscale admin console. Find your Proxmox node, click the three-dot menu, and select Edit route settings. You’ll see the advertised subnet with a toggle to approve it. Flip it on. That’s all—no router changes needed. The LXC must be running for routing to work, but you already planned to keep it up 24/7 anyway.

Test it from your laptop (connected to Tailscale): ping a Proxmox VM at its LAN IP. You should get replies. If not, double-check that IP forwarding is active in the LXC (sysctl net.ipv4.ip_forward) and that your VM’s firewall allows traffic from the LXC’s LAN IP. Subnet routing is a game-changer for homelabs; you can reach every Proxmox guest without installing Tailscale on each one.

MagicDNS and HTTPS: Friendly, Secure Access

Remembering IP addresses gets old fast. Tailscale’s MagicDNS gives every device a human-readable name like proxmox-lxc.tailnet-name.ts.net. Enable it in the admin console under DNS by turning on MagicDNS. Once it propagates (usually within a minute), you can ping proxmox-lxc from any tailnet device and it resolves to the 100.x.y.z address.

The MagicDNS name belongs to the device that runs Tailscale. proxmox-lxc.tailnet-name.ts.net therefore reaches the LXC, not the Proxmox host’s port 8006. To reach the Proxmox UI through this subnet-router design, use the host’s LAN address through the advertised route. If you want a Proxmox-host MagicDNS name and certificate, install Tailscale on the host and follow Tailscale’s Proxmox integration. Tailscale HTTPS is available today through tailscale cert, and Tailscale Serve can proxy the host UI with an automatically managed certificate; it is not a future-only feature.

If you ever need to share a service publicly without exposing ports, Tailscale Funnel is worth a look. It lets you expose a specific port on a node to the public internet over a ts.net subdomain with automatic TLS. For example, tailscale funnel --bg 8080 would make a local web app available at https://<node-name>.tailnet-name.ts.net. Funnel is a powerful tool, but remember it’s still a public endpoint—use it sparingly and only for services you’d be comfortable putting on the open web.

Locking It Down: Firewall and Tailscale ACLs

Now that everything works, it’s time to harden the setup. Even though Tailscale eliminates open ports, the LXC itself is a gateway into your LAN. We’ll use Proxmox’s host firewall and Tailscale’s access control lists (ACLs) to restrict what traffic can flow.

A firewall rule must be applied at the layer where the interface exists. Proxmox's container firewall filters the LXC's virtual LAN interface; it does not see the tailscale0 interface inside the container as a selectable Proxmox interface. A Proxmox rule that claims to “allow tailscale0” is therefore the wrong control. Use the Proxmox firewall for the container's LAN exposure and Tailscale policy for overlay access. If you add a host firewall inside the LXC, make changes from console access and preserve the traffic Tailscale needs.

Start egress with ACCEPT. A rule that permits only UDP destination port 41641 and TCP 443 is too narrow for reliable direct connections: Tailscale's default WireGuard source port is 41641, peer destination ports can vary, STUN uses UDP 3478, and DERP destinations evolve. If you must filter egress, build from Tailscale's current firewall-port guidance and test both direct and relayed paths with tailscale status or tailscale ping.

Use a tag for the subnet-router device and grants for new access policy. This example lets administrators manage the router and lets tailnet members reach the advertised lab subnet:

{
  "groups": {
    "group:admins": ["priya@example.com"]
  },
  "tagOwners": {
    "tag:homelab-router": ["autogroup:admin"]
  },
  "grants": [
    {
      "src": ["group:admins"],
      "dst": ["tag:homelab-router"],
      "ip": ["*"]
    },
    {
      "src": ["autogroup:member"],
      "dst": ["192.168.1.0/24"],
      "ip": ["*"]
    }
  ]
}

Assign tag:homelab-router to the LXC through an approved tag workflow, replace the identity and subnet, and add policy tests before saving. Tailscale recommends grants for new policies; legacy ACLs remain supported but are no longer the preferred syntax. Narrow the subnet grant if every tailnet member should not reach every lab service.

Tailscale on Proxmox replaces the anxiety of port forwarding with the quiet confidence of an encrypted mesh. You can reach every VM, every container, and every service from anywhere, all without a single port open to the internet. The setup we walked through—an unprivileged LXC, subnet routing, MagicDNS, and layered firewalling—is the foundation I wish I’d had when I started homelabbing. The current free Personal plan supports up to six users and unlimited user devices, with separate limits for tagged resources and some features; check the live pricing table before planning a larger deployment. Give it an hour, and you’ll wonder why you ever did it any other way.