Limitations and routing model
Understand TailMux boundaries before deployment: hostname-based profile selection, supported access paths, raw-IP and system-routing limits, DNS, protocol scope, and strict profile isolation.
View as MarkdownShort answer#
TailMux lets a Mac or Linux machine reach resources in more than one independent tailnet through supported, hostname-preserving access paths. It does not create another native system-wide Tailscale VPN interface, merge tailnets, or guess which profile should receive an arbitrary raw IP connection.
Routing boundary#
TailMux assigns each profile one or more hostname suffixes. When a supported connection reaches the loopback router with its hostname intact, the router selects the one profile that owns that suffix. The decision happens before a name is reduced to an address.
- Suffix overlaps are rejected during configuration validation.
- An unclassified
.ts.nethostname is denied. - A failed connection is not retried through another profile.
- Routing configuration changes take effect when the router is restarted.
See configuration for suffix ownership and the security settings that enforce these rules.
Supported access paths#
Use the access path that preserves the information TailMux needs to route safely:
- Browser routing: the documented macOS PAC path sends configured suffixes to a local proxy and leaves public traffic direct.
- HTTP-capable command tools:
tailmux runandtailmux envconfigure the documented local proxy path for compatible tools. - SSH:
tailmux sshroutes an SSH destination through the profile selected from its hostname. - Local TCP tunnels:
tailmux tunnelgives a client a fixed loopback TCP endpoint through one explicit or suffix-selected profile.
Each path has its own semantics. Read browser routing, SSH, and tunnels before assuming that a client behaves like another client.
DNS and IP addresses#
TailMux uses hostname suffixes to identify the intended tailnet. A raw IP address does not carry that ownership information, and overlapping private or CGNAT ranges can be ambiguous across independent tailnets. Raw IP destinations are therefore denied by default.
Advanced configurations can declare explicit, non-overlapping profile-owned IP or CIDR routes for raw TCP work. That is a deliberate exception, not automatic address discovery. Resolve a name through a selected profile with tailmux dns query --profile when checking per-tailnet DNS behavior.
Protocols and clients#
TailMux routes the documented TCP, HTTP proxy, browser PAC, SSH, and local tunnel workflows. It does not make every protocol proxy-aware, and it does not promise generic UDP association support or transparent routing for applications that bypass the configured access path.
A client that resolves a target itself, connects by raw IP, ignores proxy settings, or uses a non-TCP transport may need a different architecture or an explicit tunnel where appropriate. Verify a real workflow with tailmux test and tailmux diag path before relying on it.
Isolation guarantees#
TailMux keeps profile state, sockets, logs, runtime directories, and node identities separate. It binds local proxy and control listeners to loopback. It does not bridge traffic between profiles, and it does not silently fall back from one profile to another.
These guarantees are intentional safety properties, not performance optimizations. A configuration that needs to weaken them should be reviewed as a separate network design, not treated as a normal TailMux setup.
Official Tailscale client coexistence#
TailMux does not modify the official Tailscale GUI account or session. It uses profile-scoped embedded userspace networking for its own configured profiles, so the official client can continue to run independently. TailMux is an independent product and is not affiliated with, endorsed by, or sponsored by Tailscale Inc.
Operational notes#
- Restart the router after changing profiles, suffixes, IP routes, or listener settings so the live routing stack matches saved configuration.
- Use diagnostics to verify ownership, name resolution, and path details before troubleshooting an application.
- Use the architecture guide when deciding between TailMux, a shared endpoint, switching, a VM, a manual proxy, or multiple daemons.