Why two tailscaled daemons fight — and how routing by hostname avoids the war

You can run two tailscaled daemons on one machine — and the setup keeps breaking for one precise reason: each daemon is designed to own the whole machine's networking, and there is only one machine to own. Every workaround (a VM, network namespaces, userspace mode) is a way of refereeing that fight. TailMux avoids the fight instead: each tailnet runs as an embedded node that owns nothing, and a hostname-suffix router decides where each connection goes. This page explains both designs, and the trade-off honestly.

What a normal Tailscale node claims#

A standard tailscaled isn't shy, and shouldn't be. To make the whole machine transparently part of one tailnet, it claims four machine-wide resources:

1. A TUN device — a kernel network interface it owns.
2. The routing table — routes so the kernel steers tailnet traffic into that TUN.
3. DNS — resolver configuration, so MagicDNS names resolve everywhere.
4. Firewall rules — to police what enters and leaves.

For one tailnet this is the right design: every app, every protocol, zero configuration. The design's silent assumption is that it is the only claimant.

Why two claimants collide#

Start a second daemon and both now assert ownership of the same four singletons. Two interfaces want routes installed; two resolvers want to answer *.ts.net; two rule sets overlap in the firewall. None of this fails loudly at setup — it fails later: DNS for one tailnet clobbers the other, a route flips after an upgrade, and you re-debug the arrangement after every kernel, Tailscale, or OS update.

Look at the classic workarounds through this lens and they're all the same move — hiring a referee:

• A VM gives the second daemon an entire second kernel to own. Effective, and absurdly heavy: an operating system per tailnet.
• Network namespaces give it a private routing table and resolver — and now your tools must be dispatched into the right namespace per command.
• Userspace mode + SOCKS5 makes the second daemon claim nothing — but pushes dispatch onto you, one proxy port per tailnet, configured into every tool by hand.

A node that owns nothing#

TailMux drops the assumption instead of refereeing it. Each tailnet is a profile, and each profile runs a Tailscale node in-process via tsnet — Tailscale's own embedded library. Every node has its real own identity, state, and node key, and appears in its tailnet's admin console like any machine. But it claims none of the four singletons: no TUN device, no routes installed, no DNS takeover, no firewall writes. Its listening sockets are loopback-only, and the official Tailscale app on the machine is never touched.

With nothing machine-wide claimed, there is nothing to collide over. Three profiles or five coexist like three or five programs — because that's all they are.

Routing at the proxy layer, before DNS erases the answer#

If no profile owns the routing table, something else must answer “which tailnet does this connection belong to?” TailMux answers it at the proxy layer, from the hostname — the one piece of information that still knows the answer. (Once a name resolves to an IP, tailnet membership is gone; that's why kernel-level dispatch needs routes in the first place, and why raw IPs are a genuine limitation below.)

1client keeps hostname (not an IP yet)2        |3        |  HTTP proxy / PAC / tailmux connect / tunnel4        v5TailMux router  127.0.0.1:431006        |7        |  match hostname SUFFIX -> owning profile8        v9that profile's embedded tsnet node10        |11        v12that profile's tailnet  (direct / DERP)

Each profile owns a set of DNS suffixes. The router matches the request's hostname against them and dials the owning profile's node — which also resolves the name with its own tailnet's MagicDNS, so two tailnets' DNS never mix.

Isolation as a consequence, not a feature flag#

Notice that the isolation guarantees aren't bolted on — they fall out of the dispatch design:

• No fallback: a name matches exactly one profile's suffix, so there is no “second choice” to leak onto.
• No ambiguity: overlapping suffixes are rejected at config validation — two profiles cannot claim one name, ever.
• No guessing: a .ts.net name owned by no profile is refused, not routed somewhere plausible.
• No bridging: profiles share no data path; traffic cannot transit one tailnet to reach another.

The trade-off, stated plainly#

This is proxy-layer routing, not a system VPN, and the honest costs are:

• Raw IPs don't self-route. An IP carries no suffix, so TailMux denies a bare-IP target unless you name the profile explicitly (tailmux connect 100.101.102.103 22 --profile work). If your workflow is hostname-free, this friction is real.
• No exit nodes, no subnet advertising, no machine-wide VPN. Those are kernel-level, machine-owning features — precisely the ownership tsnet declines. If this machine must be infrastructure (an exit node, a subnet router), run a real tailscaled for that job and accept its upkeep.

What you get in exchange is the thing the daemon path makes painful: any number of tailnets simultaneously reachable by name, with nothing shared, nothing fought over, and nothing to re-debug after an update.

Where to go next#

To actually set it up: the macOS guide (menu-bar app, PAC, Service Tunnels) or the Linux guide (CLI, with every workaround compared). For the mixed-control-plane case, see Headscale and Tailscale at the same time.