Mirrored networking: TCP fails (ICMP works) on Realtek USB GbE NetCx adapter

[paradisaeidae]

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

1. Connect a Realtek USB GbE adapter (NetCx-class driver) as the active network interface, with networkingMode=mirrored set in .wslconfig.
2. From Windows, confirm TCP works normally (e.g. Test-NetConnection -ComputerName <gateway> -Port 80 succeeds).
3. From WSL, attempt any TCP connection, e.g.:

   curl -v http://<gateway-ip>/
   

4. 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.

[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'.