WSL2 mirrored networking: all TCP blackholed because TUN adapter MTU is 9000 (jumbo frame)

[zhangzp0127]

Summary

With AdGuard VPN enabled, WSL2 in networkingMode=mirrored cannot establish ANY TCP connection (curl to google.com / baidu.com, CLI tools such as opencode or SSH), while ICMP ping works fine. Root cause: the "AdGuard VPN" TUN adapter is configured with MTU 9000 (jumbo frame). In mirrored mode, WSL's Linux kernel derives the TCP MSS from the interface MTU, so every TCP SYN advertises MSS 8960 — far beyond what the tunnel can carry — and connections blackhole.

Environment

• Windows 10.0.26200 x64
• AdGuard VPN for Windows 2.10.2130.0 (stable; also reproduced on a beta build)
• WSL 2.7.10 (kernel 6.18.33), networkingMode=mirrored, hostAddressLoopback=true

Steps to reproduce

1. Enable AdGuard VPN (TUN mode).
2. In WSL2 (mirrored mode):
   • ping -c 2 www.google.com → works (ICMP)
   • curl -4 -sI -m 6 https://www.google.com → timeout (HTTP 000)
   • curl -4 -sI -m 6 https://www.baidu.com → timeout (all public traffic is routed into the TUN)

Observations

• Same curl from the Windows host → HTTP 200.
• Host TUN adapter: Get-NetIPInterface -InterfaceAlias "AdGuard VPN" → NlMtu 9000 (IPv4 and IPv6), IP 172.16.219.2.
• In WSL, ip route get routes all public traffic via the mirrored TUN interface (mtu 9000).
• ping -M do -s 1400 (1428-byte frame, DF) through the tunnel → drops. The tunnel cannot even carry ~1400-byte frames.

Root cause

Linux computes TCP MSS as egress-interface MTU − 40. Mirrored mode exposes the host adapter's MTU (9000) as-is, so WSL advertises MSS 8960 in every SYN; those packets are dropped by the tunnel. ICMP has no MSS and passes. The host is unaffected because AdGuard's driver handles host connections in its own network stack with correct MSS — which is why this is invisible in normal use and only breaks third-party consumers that route raw traffic into the TUN (WSL2 mirrored mode, VMs, containers). A tunnel adapter MTU should be ≤ 1500 (e.g. WireGuard 1420, OpenVPN 1500); 9000 is a jumbo-frame size a tunnel over the public internet can never deliver.

Related: requested before, closed as "Won't Do"

#625 requested an MTU option for the Windows app (noting the 9000 default) and was closed as "Won't Do". This issue is more impactful than that report suggests: it breaks ALL TCP from WSL2 mirrored networking, which is the default-convenient setup for many developers. Please reconsider — either set the TUN adapter MTU to ≤ 1500, or expose an MTU setting like the Android app already has.

Verified workaround (host-side, NOT durable)

# Administrator PowerShell
Set-NetIPInterface -InterfaceAlias "AdGuard VPN" -NlMtu 1400

Note: this is not durable — reinstalling or reconnecting AdGuard resets the adapter MTU back to 9000 and re-breaks WSL2 (verified after a beta → stable reinstall). The adapter MTU should really be fixed in the driver.

[adbuker]

related to #625

[IaroslavKhvorostenko]

Hello @zhangzp0127
The development team is currently working on clarifying this

[zhangzp0127]

Hi @IaroslavKhvorostenko @adbuker,

Thanks for confirming the team is looking into this. A few follow-up questions to help us plan:

1. Timeline – Is there an estimated timeframe for a conclusion on this issue? Since it completely blocks all TCP traffic in WSL2 mirrored mode (a default setup for many developers), it's quite impactful for affected users.

2. Fix plan – Is the team considering an actual fix? E.g., setting the TUN adapter MTU to ≤1500 by default, or exposing an MTU setting (like the Android app already has)? It would help us know whether a workaround like Set-NetIPInterface -NlMtu 1400 is the only option for the foreseeable future.

3. Priority – Could this be re-evaluated from P4? The difference from Add MTU option to the Windows App #625 is that this isn't a tuning preference – it's a functional breakage of all TCP in WSL2 mirrored networking, which is invisible from the Windows host.

Happy to provide any additional logs or testing if helpful. Thanks!

[IaroslavKhvorostenko]

Hello @zhangzp0127

Following up with answers to your questions:

• The fix for this issue is scheduled for version 2.11 (you will be able to track its progress via the assigned label on the issue).
• Regarding the technical details, we cannot share any additional specifics at this time. We will select the most practical and effective solution.
• The priority level will remain unchanged.