AdguardTeam / AdguardTeam/AdGuardVPNForWindows

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

Offen
#1,211 4 Kommentare 1 Reaktion 1 zugewiesene Person Zugewiesen an @adbuker Auf GitHub ansehen
Priority: P4 Version: VPN v2.11
Vorherrschende Sprache
Keine Sprachdaten
Sterne
207
Forks
19
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

### 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)
```powershell
# 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.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.