Windows Version
Microsoft Windows [Version 10.0.26200.8737] (25H2)
WSL Version
WSL version: 2.7.10.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-8152851
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8737
Distro Version
Ubuntu 22.04.5 LTS
Other Software
Adapter: Realtek USB GbE Family Controller (USB Ethernet dongle)
Driver: rtu53cx22x64.sys, version 1153.22.20.113 (2026-01-13), NetCx-class miniport
.wslconfig:
[wsl2]
networkingMode=mirrored
firewall=false
dnsTunneling=false
Repro Steps
- Connect a Realtek USB GbE adapter (NetCx-class driver) as the active network interface, with
networkingMode=mirrored set in .wslconfig.
- From Windows, confirm TCP works normally (e.g.
Test-NetConnection -ComputerName <gateway> -Port 80 succeeds).
- From WSL, attempt any TCP connection, e.g.:
curl -v http://<gateway-ip>/
- From WSL, confirm ICMP works fine:
ping <gateway-ip> succeeds with normal latency.
Expected Behavior
TCP connections from WSL should succeed just like they do from Windows on the same adapter/network, matching ICMP behavior.
Actual Behavior
TCP connections from WSL time out or fail with "No route to host" / connection timeout, while ICMP succeeds normally. This reproduces even for purely LAN-local traffic (same L2 segment, no internet/masquerade/router-firewall involved), which rules out upstream routing/firewall as the cause.
Diagnostic steps already taken (did NOT fix the issue)
- Disabled Large Send Offload (LSO v2, IPv4+IPv6) on the adapter — no change.
- Disabled Receive Segment Coalescing (RSC) — no change.
- Disabled TCP/UDP checksum offload (IPv4+IPv6) — no change.
- Restarted WSL (
wsl --shutdown) after each change to force mirrored networking to resync — no change.
- Confirmed WSL, Windows, and the NIC driver are all fully up to date.
- Used
pktmon (filtered on the destination TCP port) during a failing WSL TCP attempt: zero packets were captured at the host-visible vSwitch/NIC level, meaning the SYN never reaches a point pktmon can observe it — suggesting the packet is dropped inside the mirrored-mode guest/host redirect path itself, before reaching the NIC.
Get-VMSwitch shows no external Hyper-V switch bound to this adapter (only unrelated Internal switches exist), consistent with mirrored mode using a different/lighter-weight hook for this NIC than a classic external vSwitch.
Isolating comparison (strong evidence)
On the exact same machine, at the exact same time, against the exact same gateway/router:
- Via the Realtek USB Ethernet adapter (mirrored eth2 in WSL):
curl to the gateway fails with Failed to connect ... No route to host.
- Via a Wi-Fi adapter (Intel Wireless-AC 9260, mirrored eth0 in WSL) connected to the same router:
curl to the same gateway succeeds immediately (HTTP 200).
This isolates the fault specifically to how WSL2 mirrored networking interacts with this Realtek USB NIC (likely related to its NetCx-class miniport driver), rather than the network, router, WSL version, or Windows version.
Workaround in use
Lowered the Wi-Fi adapter's Windows interface metric below the Realtek adapter's, so mirrored networking's default route in WSL prefers the working Wi-Fi path over the broken Ethernet path. This is not a real fix — it only works because a second, unaffected adapter happens to be available on the same network.
Windows Version
Microsoft Windows [Version 10.0.26200.8737] (25H2)
WSL Version
Distro Version
Ubuntu 22.04.5 LTS
Other Software
Adapter: Realtek USB GbE Family Controller (USB Ethernet dongle)
Driver: rtu53cx22x64.sys, version 1153.22.20.113 (2026-01-13), NetCx-class miniport
.wslconfig:
Repro Steps
networkingMode=mirroredset in.wslconfig.Test-NetConnection -ComputerName <gateway> -Port 80succeeds).ping <gateway-ip>succeeds with normal latency.Expected Behavior
TCP connections from WSL should succeed just like they do from Windows on the same adapter/network, matching ICMP behavior.
Actual Behavior
TCP connections from WSL time out or fail with "No route to host" / connection timeout, while ICMP succeeds normally. This reproduces even for purely LAN-local traffic (same L2 segment, no internet/masquerade/router-firewall involved), which rules out upstream routing/firewall as the cause.
Diagnostic steps already taken (did NOT fix the issue)
wsl --shutdown) after each change to force mirrored networking to resync — no change.pktmon(filtered on the destination TCP port) during a failing WSL TCP attempt: zero packets were captured at the host-visible vSwitch/NIC level, meaning the SYN never reaches a point pktmon can observe it — suggesting the packet is dropped inside the mirrored-mode guest/host redirect path itself, before reaching the NIC.Get-VMSwitchshows no external Hyper-V switch bound to this adapter (only unrelated Internal switches exist), consistent with mirrored mode using a different/lighter-weight hook for this NIC than a classic external vSwitch.Isolating comparison (strong evidence)
On the exact same machine, at the exact same time, against the exact same gateway/router:
curlto the gateway fails withFailed to connect ... No route to host.curlto the same gateway succeeds immediately (HTTP 200).This isolates the fault specifically to how WSL2 mirrored networking interacts with this Realtek USB NIC (likely related to its NetCx-class miniport driver), rather than the network, router, WSL version, or Windows version.
Workaround in use
Lowered the Wi-Fi adapter's Windows interface metric below the Realtek adapter's, so mirrored networking's default route in WSL prefers the working Wi-Fi path over the broken Ethernet path. This is not a real fix — it only works because a second, unaffected adapter happens to be available on the same network.