Everyone Recommends Tailscale for Proxmox But That Advice Needs a Warning Label

I was recently going through Reddit, somewhere in the usual homelab territory where every remote access question eventually becomes a networking thread, and someone asked how they should access their Proxmox setup from outside the house.

The answers were predictable. Use Tailscale!

tailscale | logo

That recommendation makes sense. Tailscale is much safer than exposing Proxmox directly to the internet. For a homelab, that is a very attractive answer. For someone new to Proxmox, it can sound like the answer. Instead of learning firewall rules, routing, reverse proxies, and VPN design, you get a private path back into your machine with very very little ceremony.

I understand why people recommend it so quickly. I would probably recommend it too, depending on the situation (I would recommend Headscale).

[embed]Building a Self-Hosted Tailscale Network with Headscale Part 1 of 3 When I first started experimenting with Tailscale, it worked well enough that I eventually began wondering what…medium.com

The problem is that “use Tailscale” is often incomplete advice. Tailscale does gives you a secure way to reach a node but it does not automatically decide what that node should be allowed to reach after the connection succeeds. In a Proxmox setup where every VM sits on the same bridge, this matters more than beginners usually realize especially people who are just getting into homelab following the recent trend without a lot of IT background.

A new user may read “install Tailscale” as “my remote access is secure now.” A more accurate version would be that Tailscale secures the path into a specific machine. Your Proxmox network still decides what becomes reachable from there. That is where the risk begins!

The Common Proxmox Setup

A typical beginner Proxmox network is simple. The host has a bridge, usually vmbr0, and the VMs are attached to it. The host management IP may also live on that same network.

The layout often looks like this:

Made using D2

Some people install Tailscale directly on the Proxmox host. This makes the web UI and SSH reachable from outside the LAN.

Others install Tailscale inside a single VM and treat that VM as a jump box. They connect to it first, then use it to access the rest of the environment.

Both approaches can work. The issue is the network behind them.

A flat vmbr0 setup may look like this:

Made using D2

Now imagine VM-D is reachable through Tailscale.

A user connects to VM-D over SSH. From that point, VM-D may be able to see VM-A, VM-B, and VM-C because they are all attached to the same bridge. If one of those machines has weak credentials, an exposed service, or an old package with a known vulnerability, access to VM-D can become access into the rest of the segment.

Tailscale authenticated the connection to VM-D. It did not isolate VM-D from the other guests. This is the part I think that gets lost when the advice is reduced to “just use Tailscale.”

The Tool Is Doing Its Job

I do not think this is a Tailscale problem. Tailscale is doing what it is designed to do the the problem appears when users expect it to compensate for a flat internal network.

That expectation is understandable as to newbies Tailscale’s main attraction is that it is quite cleaner than the older options but internal access is still governed by the Proxmox network.

If one VM can reach every other VM on the same bridge, then the external access method is only one part of the security model. Once someone lands on that VM, the bridge defines the next set of possibilities.

This matters more in homelabs than people sometimes admit. A homelab is rarely just a lab after a while. It becomes a place where you run services you care about, store private images and videos, test client work, host experiments, and keep half-finished systems that you do not want exposed to everything else.

That last category is important. Homelabs contain a lot of unfinished work. Old test VMs, forgotten dashboards, default ports, temporary credentials, and abandoned experiments all tend to survive longer than intended.

What a VM Can See on a Flat Bridge

You do not need a complicated exploit to understand the concern. Sometimes a basic neighbor lookup is enough to show the shape of the network.

Inside a VM connected to the same L2 segment, you can run:

ip neigh show

The output may show other hosts on the local network:

192.168.1.105 dev enp6s18 lladdr ac:f4:73:xx:xx:xx STALE
192.168.1.117 dev enp6s18 lladdr 00:e0:4c:xx:xx:xx REACHABLE
192.168.1.2 dev enp6s18 lladdr 48:21:0b:xx:xx:xx STALE

This does not tell you everything but it does show that the VM has visibility into other hosts on the same segment. If the VM is reachable from outside through Tailscale, then the external entry point lands inside that segment.

For a single-user lab, this may be acceptable as any homelab setups are built around convenience, and that is fine if the risks are understood. I’m not the paranoid tin foil hat type security analyst…

The problem is that beginners often do not know which risk they are accepting. They think they exposed one machine safely but in practice, they may have created a remote path into a network where other systems are discoverable.

The risk gets worse if the Proxmox host management IP is also on the same bridge. In that case, a compromised VM may be able to reach the Proxmox web UI or SSH, depending on firewall rules and host configuration. At that point, the issue is not limited to guest-to-guest access. The management plane may also sit inside the reachable area.

The Better Order

The safer design starts before Tailscale enters the discussion. First, you should decide which systems should be able to talk to each other and then build the network around that decision. After that, choose the remote access tool.

For Proxmox, that usually means separating workloads by project, function, or trust level.

Instead of placing everything on one flat bridge, you can use Proxmox SDN with VXLAN zones and VNets to create isolated networks. A better structure may look like this:

made using D2

In this model, Project X and Project Y are separate. The Proxmox host remains on a management network. The guests are grouped according to trust boundaries rather than convenience.

None of this means Tailscale is the wrong tool. For personal administrative access, Tailscale can be a good choice. If you are the only administrator and you want to reach your Proxmox host remotely, installing Tailscale on the host may be reasonable, assuming the firewall and management exposure are configured carefully.

I think it becomes problem when Tailscale is used as a replacement for network design (it does provide ACL which can solve a lot of problems). It is not a segmentation layer for your Proxmox environment unless you build the rest of the environment around that assumption.

If the requirement is personal access to your own host, Tailscale may fit but if the requirement is project-based access for several people, a dedicated VPN per project may be easier to reason about. Tools like Pritunl can issue separate profiles and keep access scoped to a particular project network.

If the requirement is public access to one web service, Cloudflare Tunnel with a reverse proxy may be a cleaner option. The service becomes reachable without giving users broad network-level access.

Experienced users tend to mentally add the missing warnings and this is not just limited to this particular case, not even limited to IT or Tech. I have seen this happen all the time.

When they say “use Tailscale,” they may assume you already understand firewalling, routing, internal segmentation, management plane exposure, and the difference between host access and workload access.

Beginners do not always have that context. A beginner sees a Reddit thread full of confident recommendations and installs the tool and the setup works, nothing appears broken and that success can hide the part that was never designed. This is the dangerous side of a good tool!