Connect to two Tailscale networks on one Linux machine (every way, with commands)

Yes — on Linux you can connect to two Tailscale networks on one machine, and there are four working ways to do it: a second tailscaled, network namespaces, userspace SOCKS5, or a container per tailnet. All four are real; all four make you the referee between two daemons that each want to own the machine's routes, DNS, and firewall. The fifth way — routing by hostname with TailMux — needs no second daemon at all. This guide shows the actual commands for each, what breaks later, and how to pick.

For the cross-platform decision first, read how to connect to multiple Tailscale tailnets simultaneously. This Linux guide owns the operating-system-level alternatives and the CLI-specific TailMux path; it does not imply that every protocol receives system-wide routing.

Workaround 1: a second tailscaled#

The direct route: a second daemon with its own state, socket, and TUN interface.

$sudo tailscaled \$  --statedir=/var/lib/tailscale2 \$  --socket=/run/tailscale2.sock \$  --tun=tailscale1 \$  --port=41642 &$ $sudo tailscale --socket=/run/tailscale2.sock up

Both daemons come up; both tailnets are reachable. What breaks later: the two daemons install competing routes, both want to own /etc/resolv.conf for MagicDNS, and their firewall rules overlap. You'll pin DNS by hand, and you'll re-debug the arrangement after kernel and Tailscale upgrades. Systemd users also get to write and maintain a second unit file.

Verdict: legitimate if you need two full nodes (e.g. both must advertise routes). Fragile as a daily-driver setup.

Workaround 2: network namespaces#

Isolate each tailnet in its own ip netns, so nothing competes:

$sudo ip netns add worknet$sudo ip netns exec worknet tailscaled --state=/var/lib/ts-work.state ...$sudo ip netns exec worknet tailscale up$# reach the work tailnet:$sudo ip netns exec worknet curl http://wiki.work.ts.net/

What breaks later: nothing collides — because nothing shares. Your tools now live in different namespaces, so reaching both tailnets from one shell means ip netns exec wrappers around everything, veth pairs if a namespaced service must be reachable from the host, and a permanent mental model of which namespace is this command in.

Verdict: the cleanest isolation of the four, and the most ceremony per command. Good for services pinned to one tailnet; painful for interactive work across two.

Workaround 3: userspace networking + SOCKS5#

Keep the second instance out of the kernel entirely:

$tailscaled --tun=userspace-networking \$  --socks5-server=localhost:1055 \$  --statedir=/var/lib/tailscale-work &

No routes, no TUN, no fight. What breaks later: only SOCKS5-aware clients can use it. Every tool must be pointed at localhost:1055 (or wrapped in proxychains), a third tailnet means a third port, and raw hostname-based dispatch — “this name goes to that proxy” — is entirely on you.

Verdict: the closest ancestor of the routing-layer approach, minus the router. Fine for one or two proxy-aware tools; unmanageable as the tool count grows.

Workaround 4: a container per tailnet#

Run each Tailscale in Docker/LXC and let the container boundary do the isolating. Self-hosters like this because the isolation is free. What breaks later: your actual work now happens inside a container per network; you maintain an image and compose file per tailnet; and host tools still can't reach either network without extra port publishing.

Verdict: reasonable when the workload itself is containerized and pinned to one tailnet. Wrong shape for “my laptop needs both”.

Pick by requirement#

The first three requirements are machine-owning, kernel-level jobs — a real tailscaled is the right tool. If your requirement is the last row, everything above is overkill; the details of why are in why two tailscaled daemons fight.

The routing-layer way: TailMux on Linux#

TailMux is a single CLI on Linux (amd64/arm64 — no GUI needed). Each tailnet is a profile running an embedded Tailscale node in-process; a loopback router on 127.0.0.1:43100 matches each request's hostname suffix and dials only the owning profile. No TUN devices, no route or DNS changes, nothing for two nets to fight over.

$# download the linux binary for your arch, then:$tailmux init$$EDITOR ~/.config/tailmux/config.yaml   # one profile per tailnet, each owning its suffixes$tailmux config validate$tailmux up$tailmux profile login home$tailmux profile login work$tailmux status

Daily use from one shell#

HTTP tools route per command or per shell; the hostname picks the tailnet:

$tailmux run -- curl http://nas.home-lab.ts.net:8080/$eval "$(tailmux env)"$git clone https://git.work.ts.net/team/api.git

For interactive SSH, tailmux ssh wraps your system ssh with the right ProxyCommand automatically — the profile is chosen from the host's suffix, and every flag passes through untouched:

$tailmux ssh admin@host.work.ts.net$tailmux ssh nas.home-lab.ts.net -- uptime$tailmux ssh -L 9000:localhost:9000 host.work.ts.net

(Plain tailmux run ssh … would not work — OpenSSH ignores proxy environment variables. That's exactly why the wrapper exists.)

For anything that wants a fixed local port — Postgres, RDP, SMB — open a tunnel bound to one profile:

$tailmux tunnel --listen 127.0.0.1:15432 db.internal.example:5432 --profile work$psql "postgresql://app@127.0.0.1:15432/appdb"

Verify and diagnose#

$tailmux test nas.home-lab.ts.net                       # which profile owns this name?$tailmux dns query --profile home nas.home-lab.ts.net   # per-tailnet MagicDNS, no clobbering$tailmux diag path http://nas.home-lab.ts.net:8080/ --netcheck$tailmux diag fetch --modes router,direct

Mixed coordination servers#

Each profile is an independent node, so profiles can point at different coordination servers — one at Tailscale's, another at a self-hosted Headscale. That setup has its own guide: use Headscale and Tailscale at the same time.

The bottom line#

Every classic Linux answer works, and every one leaves you maintaining the referee between two route-owning daemons. If the machine must be infrastructure on both nets (exit node, subnet router), run the second daemon and own the upkeep. If you just need two tailnets reachable by name from one shell, route by hostname instead: tailmux up, log in twice, then use the documented proxy, SSH, or tunnel path. Getting started has the setup and the routing limitations define the boundary; download is here.