SSH, RDP & SMB over a second tailnet

The problem#

SSH, Microsoft Remote Desktop and the Finder's SMB client all speak raw TCP and resolve hostnames through the operating system first. TailMux stays at the proxy layer — it never installs a TUN device and never touches the system resolver — so a custom tailnet suffix like .work.ts.net is invisible to macOS. The lookup reaches public DNS, returns NXDOMAIN, and the client fails before TailMux is ever involved. This is the same wall database clients hit: these apps also ignore HTTP_PROXY / ALL_PROXY, so tailmux run can't help. The fix is to put a loopback hop between the client and the host so it never has to resolve the suffix itself.

If you run a work and a personal tailnet side by side, each suffix is owned by its own profile — see work & personal tailnet for the setup. The router on 127.0.0.1:43100 dispatches by hostname suffix with no cross-profile fallback, so a host on either tailnet is reachable without switching accounts.

SSH via tailmux connect#

The fastest way is the built-in wrapper: tailmux ssh admin@host.work.ts.net opens a normal interactive session routed through the profile that owns .work.ts.net — it writes the ProxyCommand below for you. See SSH.

tailmux connect <host> <port> opens a raw TCP stream over stdin/stdout through the profile that owns the host's suffix — exactly what SSH's ProxyCommand expects. The profile is selected automatically from the hostname; no --profile flag is needed. This mirrors the dedicated SSH doc.

$ssh -o ProxyCommand="tailmux connect %h %p" user@host.work.ts.net

SSH substitutes %h / %p with the target host and port, so it runs tailmux connect host.work.ts.net 22 — routed through the profile that owns .work.ts.net. To apply it automatically to every host in a suffix, drop a Host block into ~/.ssh/config:

1Host *.work.ts.net2    ProxyCommand tailmux connect %h %p

Now ssh user@host.work.ts.net just works, and host-key verification is unaffected — you still confirm the remote key as usual.

RDP via tailmux tunnel#

Microsoft Remote Desktop can't set a ProxyCommand, so bind a fixed loopback port to the host's RDP port (3389) with tailmux tunnel and point the client at 127.0.0.1:

$tailmux tunnel --listen 127.0.0.1:13389 desktop.work.ts.net:3389

In Microsoft Remote Desktop, add a PC with the host name 127.0.0.1:13389. The profile is chosen automatically from the .work.ts.net suffix; TailMux resolves the host through that profile and relays the bytes both ways for the duration of the session.

Prefer it managed? Add the same forward as an always-on tunnel in the app — Open → Tunnels → Add Tunnel, target desktop.work.ts.net:3389 — and TailMux keeps it alive with a fixed port you copy from the menu bar. See tunnels.

SMB via tailmux tunnel#

Mounting a network share works the same way — bind a loopback port to the host's SMB port (445), then open the loopback address in the Finder:

$tailmux tunnel --listen 127.0.0.1:10445 nas.work.ts.net:445

In the Finder, choose Go → Connect to Server and enter smb://127.0.0.1:10445. The share mounts over the work profile exactly as if you were on its tailnet directly.

Prefer it managed? Add the same forward as an always-on tunnel in the app — Open → Tunnels → Add Tunnel, target nas.work.ts.net:445 — and TailMux keeps it alive with a fixed port you copy from the menu bar. See tunnels.

Notes#

• connect streams a single connection (ideal for a ProxyCommand); tunnel holds a listener open for many connections — see the full flag set in commands.
• The profile is auto-selected from the host's suffix. Pass --profile <name> to force one, which is required when the target is a raw IP rather than a tailnet hostname.
• Keep each loopback port stable per service (for example 13389 for RDP, 10445 for SMB) so saved connections keep working across restarts.
• TailMux is loopback-only and is not affiliated with Tailscale. The same pattern covers any raw-TCP service — see database clients for GUI database tools, and pricing for the one-time license.