Proxmox + Tailscale: convenient remote access, but what about blast radius?

[Fearless-Grape5584]

Proxmox + Tailscale: convenient remote access, but what about blast radius?

Tailscale is a very convenient way to reach a Proxmox host or VM from outside without opening inbound ports. That part is great.
But I think there is an easy design mistake here:

making remote access easy does not automatically make the environment well-isolated.

In a typical flat

vmbr0

setup, exposing one VM through Tailscale can also create a lateral movement path to other VMs, and in some cases even to the Proxmox management plane itself.
I wanted to summarize that risk and the design order that seems more correct to me.

---

Typical pattern
A common pattern looks like this:

[Remote user] -> Tailscale -> Proxmox host or one VM -> vmbr0 -> all VMs

Typical examples:

• Install Tailscale directly on the Proxmox host
• Install Tailscale on one VM and SSH from there to other VMs

This is easy to set up, but on a flat bridge it also means one reachable point may become a jump point.

---

Why this matters
In the default-style flat bridge design, multiple VMs share the same L2 segment:

vmbr0 (flat)
|- VM-A (project X)
|- VM-B (project Y)
|- VM-C (database)
`- VM-D (Tailscale-enabled VM)

If VM-D becomes reachable from outside via Tailscale, then a legitimate user — or an attacker after compromise — may be able to:

1. Access VM-D via SSH or another management path
2. Scan other systems on the same bridge
3. Attempt lateral movement to other VMs

The key point is this:
Tailscale authentication controls access to VM-D. It does not automatically control what VM-D can see on the same bridge afterwards.
And if the Proxmox host management IP is also exposed on that same L2 domain, the blast radius may include not only guest VMs, but also the Proxmox control plane (for example Web UI / SSH reachability attempts).

---

This is not only a Proxmox problem
I think this is broader than Proxmox.
If you expose a workload externally while keeping it attached to a flat internal network, the same design problem can appear on many virtualization platforms and in cloud environments too.
The concrete implementation differs, but the risk pattern is similar:

• one exposed workload gets compromised
• the attacker pivots laterally
• the blast radius becomes much larger than expected

---

Lateral movement and blast radius
Lateral movement = compromise of one system leading to attempts against neighboring systems on the same network.
Blast radius = how far the damage can spread after one system is compromised.
In a flat

vmbr0

design, the blast radius can become:

all VMs on that bridge
+ any management plane reachable on the same L2 domain

That is especially uncomfortable when:

• multiple projects share one Proxmox environment
• external collaborators need access
• different trust levels coexist on the same host

---

The design order that seems safer
In my view, the safer order is:

1. First: design network boundaries
2. Then: decide how remote users should enter

Step 1: isolate project networks first
With Proxmox SDN (for example VXLAN Zone + VNets), you can place projects into separate L2 segments first.
Something like:

vnetpj01
|- VM-A
`- VM-B

vnetpj02
|- VM-C
`- VM-D

vmbr0
`- Proxmox host (management side)

Then host-level firewall enforcement can keep project networks separated even if a VM inside one segment is compromised.

Step 2: choose the access method
After isolation exists, then choose how users should enter.
For example:

Use case	Access method
Single admin access	Tailscale directly to the host
Multiple members per project	Project-specific VPN (for example Pritunl)
Expose only one service	Cloudflare Tunnel + reverse proxy

Tailscale is simple and very useful, but if the goal is:
“different people should reach different project networks with clean separation”
then network isolation must already exist first.

---

In short

	Flat bridge + Tailscale	Isolated SDN + appropriate access path
Remote access convenience	Good	Good / moderate
Project-to-project isolation	Weak	Strong
Lateral movement resistance	Weak	Strong
Blast radius minimization	Weak	Strong

---

Conclusion
Tailscale is excellent for making remote access easy.
But: “reachable from outside” and “safely exposed” are not the same thing.
If the environment still relies on one flat

vmbr0

, then one compromised VM may become a path to:

• other VMs
• other projects
• and in the worst case, even management-plane targets on the same L2 domain

So I think the better order is:

first create boundaries,
then make access convenient

---

Note
I ended up automating this pattern for my own environment, but even without any specific tool, I think the design principle is worth keeping in mind:
do not confuse remote access convenience with isolation.