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 punching holes in your firewall, it builds an encrypted overlay network between your devices using WireGuard. Your Proxmox host, VMs, laptops, phones—they all join a private “tailnet.” Traffic flows directly between them over WireGuard tunnels, with no inbound ports required anywhere. The coordination server just helps devices find each other; your actual data never touches it. For homelabbers, this means you can access every service from anywhere without exposing a single port to the open internet. It’s fast, lightweight, and refreshingly simple.

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.

During creation, give the container modest resources: 1 vCPU, 512 MB of RAM, and 4 GB of disk is plenty. Attach it to your usual bridge network (e.g., vmbr0) so it gets a LAN IP. Under the container’s Options tab, find Features and enable TUN/TAP. This creates the /dev/net/tun device that Tailscale needs for its WireGuard interface. Without it, the container can’t create the tunnel. You can leave nesting and other options off unless you plan to run Docker inside—which we won’t.

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 up --advertise-routes=192.168.1.0/24

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.

This means you can set up a bookmark for your Proxmox web UI as https://proxmox-lxc.tailnet-name.ts.net:8006. Even better, combine it with a reverse proxy on the LXC (like Caddy or Nginx) to serve all your services over HTTPS with valid certificates. Tailscale’s own HTTPS support is on the horizon, but for now a local reverse proxy pointing to your VMs works beautifully.

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.

First, enable the Proxmox firewall on the container. Go to the container’s Firewall tab, click Add to create a rule set, and set the Input Policy to DROP. Then add rules to allow only what’s necessary:

  • Accept all traffic on the tailscale0 interface. This lets your tailnet devices reach the container and any services you host there.
  • Accept established and related connections (so replies to outbound traffic aren’t blocked).
  • Optionally, accept SSH from your LAN IP if you want direct console access without going through Tailscale.

For outbound, you can leave the default ACCEPT policy or restrict it to UDP port 41641 (WireGuard) and TCP 443 (Tailscale control traffic). The container doesn’t need general internet access beyond that.

Next, tighten things at the Tailscale layer with ACLs. In the admin console under Access Controls, you can write rules that define who can reach which nodes and ports. A starter ACL might look like:

{
  "groups": {
    "group:admins": ["[email protected]"],
  },
  "acls": [
    // Allow admins full access to the Proxmox LXC
    {
      "action": "accept",
      "src":    ["group:admins"],
      "dst":    ["proxmox-lxc:*"],
    },
    // Allow all users to reach subnet routes
    {
      "action": "accept",
      "src":    ["autogroup:member"],
      "dst":    ["192.168.1.0/24:*"],
    },
  ],
}

This ensures only your admin account can SSH into the LXC or hit its local services, while any authenticated tailnet member can use the subnet route to reach your VMs. Tailscale ACLs are evaluated before traffic ever reaches the container, so they act as a second layer of defense. Together with the Proxmox firewall, you’ve built a secure, zero-trust entry point into your homelab.

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. It’s simple, free for up to 3 users and 100 devices, and it scales with you as your lab grows. Give it an hour, and you’ll wonder why you ever did it any other way.