Tailscale Inside WSL2 (Alternative Approach)¶
Official Stance¶
Tailscale explicitly recommends running on the Windows host only, not inside WSL2. Their docs state: encrypted traffic flowing from WSL2 over Windows-host Tailscale will not work due to double encapsulation (Tailscale packets inside Tailscale packets).
Running both Windows Tailscale and WSL2 Tailscale simultaneously is unsupported.
When This Makes Sense¶
- You want WSL2 to be a fully independent tailnet node with its own IP.
- You're willing to disable Windows Tailscale entirely.
- You want direct SSH to WSL2 without any Windows port forwarding.
Known Problems¶
1. MTU Issues¶
WSL2's default MTU on its virtual NIC is 1280. Tailscale needs at least 1340.
tailscaled auto-raises MTU to 1340 when it detects WSL2, but this workaround
isn't always reliable. Symptoms: connection hangs on large packets, slow transfers.
Related: tailscale/tailscale#4833
2. DNS Breakage¶
Tailscale inside WSL2 modifies /etc/wsl.conf to set generateResolvConf = false
and attempts to write its own /etc/resolv.conf pointing to 100.100.100.100
(Tailscale's MagicDNS). This second step often fails silently, leaving WSL2 with
no DNS resolution at all.
The config change also reappears after every Windows restart.
See dns-issues.md for workarounds.
Related: tailscale/tailscale#2815
3. IPv6 Issues¶
WSL2's kernel has limited IPv6 routing support. ip -6 rule add fails with
"Rule family not supported". Tailscale has a built-in workaround that auto-disables
IPv6 when this fails, but older versions may need manual intervention:
Related: tailscale/tailscale#562
4. Dual-Instance Conflicts¶
If Windows Tailscale is running AND you start tailscaled in WSL2, the WSL2
node's Tailscale-encrypted traffic must traverse the Windows Tailscale tunnel.
This creates double encapsulation that exceeds MTU limits and fails silently.
You must disable Windows Tailscale if running Tailscale in WSL2.
Installation (if you choose this path)¶
With systemd enabled¶
Without systemd¶
Or add to /etc/wsl.conf:
Kernel vs Userspace Mode¶
By default, tailscaled in WSL2 uses kernel mode (TUN device). This gives
Layer 3 routing with full protocol support. Userspace mode (--tun=userspace-networking)
provides only TCP/UDP (no ICMP beyond ping, no SCTP) and reconstructs connections
rather than forwarding packets end-to-end.
For a personal dev server, kernel mode (default) is fine.
Node Naming¶
Your WSL2 node will likely share the Windows PC's hostname, appearing as a
duplicate in the Tailscale admin panel (possibly with -1 appended). Rename
it in the Machines page to avoid confusion.
Bottom Line¶
This approach works but is fragile. Expect to spend time on DNS fixes, MTU tuning, and ensuring Windows Tailscale is fully stopped. The recommended path is Windows host Tailscale + port forwarding.