macOS: tailcat's traffic goes through a co-located Tailscale exit node because netns is off

Abierto
  • ¿Algo no está bien?
#165 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@chphch ya está trabajando en esto.

Desde el 13/11/2026.

  • #166 de @chphch — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
go, macos
Área
networking

Línea de trabajo

The netns setting is turned off in createEngine and PickBestRegion, and the issue argues it should stay on for macOS only. Start by reading how netns is set in those two functions, then check the open pull request #166 that already targets this change. Done means the macOS path binds to the physical interface and go test ./... still passes, which the issue reports on main.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happens

On a Mac that runs the Tailscale app with an exit node selected, tailcat sends its own WireGuard UDP and its DERP connections into the app's tunnel. tailcat turns netns off in createEngine and PickBestRegion, so its sockets follow the route table, and with an exit node the route table sends everything to the Tailscale interface. The path that magicsock reports as direct then runs through the exit node. In our setup the server Mac is also the client's exit node, so that path leaves the server Mac and comes back to it through its router's hairpin NAT.

We use tailcat through Happy Agent, which keeps one long-lived tailcat --key=new socks --listen=127.0.0.1:0 <addr> per remote machine and sends HTTP requests through it. On that tunnel-in-tunnel path, small responses kept arriving while large ones stalled for minutes to hours at a time, on most days since 2026-11-10. Disco pings kept succeeding, so magicsock did not fall back to DERP.

Environment
  • Client: macOS 27.2 (arm64), Tailscale app 1.104.5 (standalone), exit node selected, LAN access allowed.
  • Server: macOS 27.2 behind a NAT router, running tailcat serve exec. The same Mac is the client's exit node.
  • tailcat v0.7.0 as bundled by Happy Agent, and builds of main (e00cdde6f) for the comparison below.
During a stall (v0.7.0, 2026-11-13)
  • On the client, route -n get <server public IP> prints interface: utun5, the Tailscale interface, and the verbose log shows now using <server public IP>:<port> ... via=direct.
  • Through the long-running client, a 771-byte response arrived in 0.07 s and a 44 KB response produced no byte within 30 s (twice). A fresh --key=new client behaved the same.
  • With the exit node cleared, the 44 KB response took 0.06–0.11 s. With TS_DEBUG_ALWAYS_USE_DERP=1 and the exit node still selected, 44–49 KB took 0.3–0.8 s.

Outside a stall the same path carries megabytes, and we did not find which hop drops the large packets. tailcat's full-size packets (1340 bytes over IPv4) are larger than the Tailscale tunnel's 1280-byte MTU, while disco pings of about 100 bytes fit, so a drop that depends on packet size never makes magicsock leave the path.

With netns left on

Same client with the exit node selected, a throwaway tailcat serve on the server Mac, and a throwaway tailcat socks client that downloads 3 MB three times (2026-11-13):

main (e00cdde6f) netns left on for macOS
Interface of the client's UDP socket (nettop) utun5 en0
Local address of the client's DERP connection its Tailscale IP its Wi-Fi address
Client's public address from STUN (v4a) the exit node's public IP its own public IP
Path to the server DERP direct, and the server sees the client's own public IP
3 MB through socks 3.6–8.0 s 0.5–1.8 s

netns finds en0 here because netmon's DefaultRouteInterfaceIndex takes the Tailscale app's IPv6 default route (default fd7a:115c:a1e0:: UGcg utun5) and returns the tunnel's delegated interface. A VPN whose only unscoped default route has no gateway leaves netmon without a default interface, so netns would not bind there. tailscale/tailscale#22260 covers that case, and a build with it applied behaved like the second column.

Proposed fix

Leave netns on for macOS. On macOS a socket bound with IP_BOUND_IF still reaches loopback, so the loopback DERP map problem described in PickBestRegion does not apply there: go test ./... passes on macOS, and the root package takes the same time as on main. Other platforms keep netns off. A PR follows.

Workaround

Set TS_DEBUG_ALWAYS_USE_DERP=1 on the client, or clear the exit node.

Lenguaje dominante
Go
Estrellas
8.8k
Forks
404
Merge medio
3 h 48 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tailscale/tailcat

Todos los issues de tailscale/tailcat

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.