Summary
When Tailscale runs on both a Windows host and a WSL2 distribution, Attach VS Code can authenticate, start the VS Code Server, and establish its SSH tunnel, but then repeatedly reconnect without opening a usable remote workspace.
In my case, WSL2 had:
eth0 MTU 1280
tailscale0 MTU 1280
Small SSH responses worked, while larger responses stalled. Raising only WSL’s outer eth0 MTU to 1500 restored larger SSH transfers and allowed the VS Code connection to proceed normally.
The extension could detect this known configuration before delegating to Remote-SSH and display an actionable warning.
Environment
- Windows 11 with WSL2
- Ubuntu 24.04 in WSL2
- Tailscale installed on both Windows and inside WSL2
- Tailscale
1.98.9 on both nodes
- VS Code
1.129.1
- Remote-SSH
0.124.0
- Windows OpenSSH client
- Unprivileged remote Linux user
Observed behavior
The Tailscale extension correctly resolved the remote username and opened the WSL node through Tailscale SSH.
Remote-SSH then reported:
Remote server is listening on port <port>
Starting forwarding server
Waiting for ssh tunnel to be ready
Tunneled port <remote-port> to local port <local-port>
Exec server created and cached
Found running server
Despite the tunnel being established, the remote window did not become usable. Remote-SSH restarted the connection approximately every 20 seconds while the UI continued showing:
Waiting for port forwarding to be ready
No changes to the SSH username, permissions, access policy, OpenSSH client, dynamic forwarding, or VS Code Exec Server corrected the underlying behavior.
Reproduction outside VS Code
Small output succeeded:
ssh <user>@<wsl-node>.<tailnet>.ts.net 'echo one'
A 512-byte response also succeeded:
ssh <user>@<wsl-node>.<tailnet>.ts.net \
'head -c 512 /dev/zero | tr "\0" x; echo'
Larger responses stalled:
ssh <user>@<wsl-node>.<tailnet>.ts.net \
'head -c 1200 /dev/zero | tr "\0" x; echo'
Interface inspection showed:
ip -o link show eth0
ip -o link show tailscale0
eth0 MTU 1280
tailscale0 MTU 1280
This left insufficient room for the inner Tailscale packet plus encapsulation overhead.
Workaround
From a privileged account inside the WSL2 distribution:
sudo ip link set dev eth0 mtu 1500
Result:
eth0 MTU 1500
tailscale0 MTU 1280
Afterward, larger SSH responses and Attach VS Code worked. tailscale0 remained at its intended MTU of 1280.
This change is temporary and resets when WSL restarts.
Suggested extension resolution
Because the Tailscale extension owns the Attach VS Code action, it could perform a small, time-limited preflight before delegating to Remote-SSH.
When the local platform is Windows and the selected Linux node is identified as WSL2, the preflight could retrieve:
grep -i microsoft /proc/sys/kernel/osrelease
ip -o link show eth0
ip -o link show tailscale0
If eth0 has an MTU equal to or smaller than tailscale0, the extension could display:
Potential WSL2 MTU conflict
This WSL2 node’s outer interface may be too small to carry Tailscale traffic. SSH authentication and small commands can work while VS Code, TLS, and larger responses stall.
Raise the WSL2 eth0 MTU or use Tailscale’s recommended single-installation configuration before attaching.
Suggested actions:
- Copy temporary fix
- Open WSL2 guidance
- Attach anyway
- Cancel
Copy temporary fix could copy:
sudo ip link set dev eth0 mtu 1500
The extension should not execute this privileged network change automatically. If WSL2 or its MTU cannot be identified reliably, the preflight should remain non-blocking.
This would diagnose the failure at the Tailscale-owned entry point instead of leaving users with a misleading Remote-SSH forwarding toast and a reconnect loop.
Related issues
This appears to connect several existing reports rather than duplicate any one of them:
The networking limitation is already tracked in Tailscale core. This issue is specifically about detecting it and presenting an actionable resolution within the VS Code extension’s Attach workflow.
Summary
When Tailscale runs on both a Windows host and a WSL2 distribution, Attach VS Code can authenticate, start the VS Code Server, and establish its SSH tunnel, but then repeatedly reconnect without opening a usable remote workspace.
In my case, WSL2 had:
Small SSH responses worked, while larger responses stalled. Raising only WSL’s outer
eth0MTU to1500restored larger SSH transfers and allowed the VS Code connection to proceed normally.The extension could detect this known configuration before delegating to Remote-SSH and display an actionable warning.
Environment
1.98.9on both nodes1.129.10.124.0Observed behavior
The Tailscale extension correctly resolved the remote username and opened the WSL node through Tailscale SSH.
Remote-SSH then reported:
Despite the tunnel being established, the remote window did not become usable. Remote-SSH restarted the connection approximately every 20 seconds while the UI continued showing:
No changes to the SSH username, permissions, access policy, OpenSSH client, dynamic forwarding, or VS Code Exec Server corrected the underlying behavior.
Reproduction outside VS Code
Small output succeeded:
A 512-byte response also succeeded:
Larger responses stalled:
Interface inspection showed:
This left insufficient room for the inner Tailscale packet plus encapsulation overhead.
Workaround
From a privileged account inside the WSL2 distribution:
sudo ip link set dev eth0 mtu 1500Result:
Afterward, larger SSH responses and Attach VS Code worked.
tailscale0remained at its intended MTU of1280.This change is temporary and resets when WSL restarts.
Suggested extension resolution
Because the Tailscale extension owns the Attach VS Code action, it could perform a small, time-limited preflight before delegating to Remote-SSH.
When the local platform is Windows and the selected Linux node is identified as WSL2, the preflight could retrieve:
If
eth0has an MTU equal to or smaller thantailscale0, the extension could display:Suggested actions:
Copy temporary fix could copy:
sudo ip link set dev eth0 mtu 1500The extension should not execute this privileged network change automatically. If WSL2 or its MTU cannot be identified reliably, the preflight should remain non-blocking.
This would diagnose the failure at the Tailscale-owned entry point instead of leaving users with a misleading Remote-SSH forwarding toast and a reconnect loop.
Related issues
This appears to connect several existing reports rather than duplicate any one of them:
Attach VS Codevia vscode extension is timing out (but output shows successsful authentication and can SSH fine) tailscale/tailscale#9297) — Attach VS Code authenticates but remains connecting and times out on a WSL2 target.The networking limitation is already tracked in Tailscale core. This issue is specifically about detecting it and presenting an actionable resolution within the VS Code extension’s Attach workflow.