Sign up
View stargazersSign up

Windows desktop suggests an unreachable Windows Tailscale address for a WSL backend#21889

opened22d agobyOootada

What happened

Direct pairing from another Windows 11 computer timed out using the address supplied by T3. Replacing it with the host WSL instance’s Tailscale address made pairing succeed. Windows and WSL each run Tailscale with separate addresses.

Steps to reproduce

  1. Run T3 desktop on Windows 11 with its backend in WSL2.
  2. Connect Tailscale independently on Windows and inside WSL.
  3. Generate a pairing link using T3’s suggested Windows Tailscale address.
  4. Pair from another Windows 11 computer on the same tailnet: connection times out.
  5. Replace the endpoint with http://:3773: pairing succeeds.

Expected behavior

T3 should advertise an address that reaches the active backend, or establish forwarding before advertising the Windows address.

Diagnosis and evidence

text
1WSL listener: 0.0.0.0:3773
2Windows listener: 127.0.0.1:3773
3
4HTTP request from Windows to WSL’s Tailscale address:3773:
5 HTTP 200
6
7Test from the receiving computer:
8 Test-NetConnection <WSL-tailnet-IP> -Port 3773
9 InterfaceAlias: Tailscale
10 TcpTestSucceeded: True

The user confirmed that pairing succeeded after substituting the WSL address. The exact address-selection code path has not been isolated.

Version and environment

  • Host and receiving computer: Windows 11 with WSL.
  • Host backend: desktop-managed WSL runtime.
  • Recorded backend serverVersion: 0.1.0; exact desktop release/commit not independently verified.
  • WSL kernel: 6.18.54.1-microsoft-standard-WSL2.

Workaround

Use http://:3773 for direct pairing while WSL and T3 remain running.

  • #7519: Windows LAN/Tailscale address classification.
  • #4028: Tailscale HTTPS enablement with a WSL-only backend.
  • #9056: WSL listener binding and Network access.

These concern related behavior; an exact duplicate has not been established.

Additional observation

T3 Connect setup also failed with:

text
1Could not obtain environment link proof: Invalid managed endpoint origin.

Local traces show CloudLinkOriginInvalidError in environment.cloud.makeLinkProof. Whether this shares a root cause with the pairing issue is unknown. Relay setup remains unresolved.

Prepared by

Codex, gpt-6-astra, in T3 Code, following the triage playbook during an existing diagnostic session.

JJulius Marminge22d ago

Note

Grok responding on behalf of Julius.

Thanks for the connectivity checks. Current main fits what you saw.

The desktop app works out which addresses to advertise from the Windows network interfaces (apps/desktop/src/backend/DesktopNetworkInterfaces.ts:47), including the Tailscale ones (apps/desktop/src/backend/tailscaleEndpointProvider.ts:27-56). The address selection doesn't know about WSL (apps/desktop/src/backend/DesktopServerExposure.ts:378-410), and the WSL backend uses that same exposure state (apps/desktop/src/wsl/DesktopWslBackend.ts:68, :103). With Tailscale running separately inside WSL, the suggested Windows address doesn't reach the backend.

This isn't a duplicate of #13738 or #4028. Those cover Windows reaching the WSL backend and Tailscale HTTPS, not which address gets advertised. The network interface picker proposed for pairing links was never merged, so there is no setting for this today.

The T3 Connect error is tracked in #5210.

Accepting this as a bug. For now, pairing with the WSL instance's Tailscale address and the same port works, as you found.