WSL NetworkMode mirrored unable to connect to Windows host via TCP

[go2sh]

Windows Version

Microsoft Windows [Version 10.0.22631.6936]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-microsoft-standard-WSL2+

Distro Version

Ubuntu 26.04

Other Software

• Windows App Running TCP server on 20000
• Linux python script connecting to localhost:20000

Repro Steps

When a WSL2 client attempts to connect to a Windows host application via 127.0.0.1 in mirrored networking mode, the TCP handshake fails because the Windows network stack returns the SYN-ACK to a different ephemeral port than the one the SYN was sent from. The Linux kernel does not match the SYN-ACK to the original socket and responds with RST, making it impossible to establish a connection to Windows host services via loopback.

This happens even with hostAddressLoopback=true set in .wslconfig.

1. Set networkingMode=mirrored and hostAddressLoopback=true in %USERPROFILE%.wslconfig
2. Run wsl --shutdown and restart WSL
3. Start a TCP server on Windows host listening on port 20000 (e.g. any app bound to 0.0.0.0:20000)
4. From WSL, attempt to connect to 127.0.0.1:20000: nc -v 127.0.0.1 20000
5. Capture traffic in WSL: sudo tcpdump -i any -n port 20000

Expected Behavior

The TCP three-way handshake completes successfully:

WSL (port X)     →  SYN    →  Windows:20000
WSL (port X)     ←  SYN-ACK ←  Windows:20000
WSL (port X)     →  ACK    →  Windows:20000

The SYN-ACK should be addressed back to the same source port that sent the SYN, allowing the Linux kernel to match it to the existing socket and complete the connection.

Actual Behavior

The SYN-ACK is returned to a different port than the one that sent the SYN, causing the Linux kernel to send RST and drop the connection:

WSL (port 41264)  →  SYN      →  Windows:20000   ✅
WSL (port 36677)  ←  SYN-ACK  ←  Windows:20000   ❌ wrong port!
WSL (port 36677)  →  RST      →  Windows:20000   ❌ connection dropped

The connection never establishes. The Windows app keeps retransmitting SYN-ACK to incorrect ports, each time receiving a RST from the Linux kernel.

Diagnostic Logs

tcpdump output from WSL during connection attempt:

13:24:14.179902 loopback0 Out IP 127.0.0.1.41264 > 127.0.0.1.20000: Flags [S], seq 2406906390, win 64240, options [mss 1460,sackOK,TS val 3610728993 ecr 0,nop,wscale 7], length 0
13:24:14.180534 loopback0 In  IP 127.0.0.1.20000 > 127.0.0.1.36677: Flags [S.], seq 2977463670, ack 2406906391, win 8192, options [mss 65495,nop,wscale 8,sackOK,TS val 6756090 ecr 3610728993], length 0
13:24:14.180569 loopback0 Out IP 127.0.0.1.36677 > 127.0.0.1.20000: Flags [R], seq 2406906391, win 0, length 0
13:24:15.192632 loopback0 In  IP 127.0.0.1.20000 > 127.0.0.1.35723: Flags [S.], seq 2977463670, ack 2406906391, win 8192, options [mss 65495,nop,wscope 8,sackOK,TS val 6757102 ecr 3610728993], length 0
13:24:15.192678 loopback0 Out IP 127.0.0.1.35723 > 127.0.0.1.20000: Flags [R], seq 2406906391, win 0, length 0
13:24:17.195141 loopback0 In  IP 127.0.0.1.33820 > 127.0.0.1.20000: Flags [S.], seq 2977463670, ack 2406906391, win 8192, options [mss 65495,nop,wscale 8,sackOK,TS val 6759105 ecr 3610728993], length 0
13:24:17.195186 loopback0 Out IP 127.0.0.1.33820 > 127.0.0.1.20000: Flags [R], seq 2406906391, win 0, length 0

.wslconfig:

[wsl2]
networkingMode=mirrored
kernel=C:\\Users\\User\\vmlinux

[experimental]
hostAddressLoopback=true

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[go2sh]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[MX1951]

I can reproduce the same issue on my machine.

Environment

Windows: 10.0.29576.1000
WSL: 2.7.3.0
Kernel: 6.6.114.1-1
Distro: Ubuntu
Networking mode: mirrored

My %USERPROFILE%\.wslconfig:

[wsl2]
networkingMode=mirrored
memory=137266987008
swap=34359738368

Repro

Start a TCP server on the Windows host:

cd $env:TEMP
"win-all-ok" | Out-File -Encoding ascii .\win-all.txt
py -3 -m http.server 18082 --bind 0.0.0.0

Windows can access it successfully:

curl.exe http://127.0.0.1:18082/win-all.txt

Output:

win-all-ok

But from WSL, in mirrored networking mode:

wslinfo --networking-mode
# mirrored

env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY \
    -u http_proxy -u https_proxy -u all_proxy \
    curl -v --noproxy '*' --connect-timeout 5 \
    http://127.0.0.1:18082/win-all.txt

It times out.

This also breaks Windows localhost proxy usage from WSL. For example, my Windows system proxy is 127.0.0.1:7890, and WSL receives HTTP_PROXY=http://127.0.0.1:7890, but WSL cannot connect to it.

tcpdump evidence

I captured the traffic inside WSL:

sudo tcpdump -i any -n -vv 'tcp port 18082'

Relevant output:

loopback0 Out IP 127.0.0.1.43545 > 127.0.0.1.18082: Flags [S]
loopback0 In  IP 127.0.0.1.18082 > 127.0.0.1.12411: Flags [S.]
loopback0 Out IP 127.0.0.1.12411 > 127.0.0.1.18082: Flags [R]

loopback0 Out IP 127.0.0.1.43545 > 127.0.0.1.18082: Flags [S]
loopback0 In  IP 127.0.0.1.18082 > 127.0.0.1.11417: Flags [S.]
loopback0 Out IP 127.0.0.1.11417 > 127.0.0.1.18082: Flags [R]

loopback0 Out IP 127.0.0.1.43545 > 127.0.0.1.18082: Flags [S]
loopback0 In  IP 127.0.0.1.18082 > 127.0.0.1.9451: Flags [S.]
loopback0 Out IP 127.0.0.1.9451 > 127.0.0.1.18082: Flags [R]

The SYN is sent from source port 43545, but the SYN-ACK is returned to different ports such as 12411, 11417, and 9451. The Linux kernel then responds with RST. This matches the behavior described in this issue.

Additional notes

Windows self-test succeeds, so the server itself is working.

WSL reports networkingMode=mirrored, but WSL cannot connect to Windows host services via 127.0.0.1.

Hyper-V firewall settings show LoopbackEnabled=True, so this does not look like a simple firewall block.

This issue affects tools that rely on Windows localhost proxy from WSL, such as OpenAI Codex, npm, curl, etc.

[Zrrrrrrg]

Same to me, exactly what the two posts above describe.

[Zrrrrrrg]

Same to me, exactly what the two posts above describe.

It's weird... When I run Wireshark on Windows Host (just let the Wireshark process holds and stays at the startup screen, nothing more), I could normally use "mirrored" mode to access localhost from both sides -- iff the Wireshark is running, if you shut the Wireshark, it rollbacks to the above fault.
It must have something to do with driver.

[agoldhammer]

I'm having the same issue.