Repository navigation
wslc NAT image pull over GlobalProtect VPN fails at MTU 1400, succeeds at 1360 #41790
Description
wslc NAT image pull over GlobalProtect VPN fails at MTU 1400, succeeds at 1360
Windows Version
Microsoft Windows [Version 10.0.26200.9448]
WSL Version
3.0.1.0
Are you using WSL 1 or WSL 2?
WSL 2 (wslc session VM)
Kernel Version
6.18.40.1-1
Distro Version
WSLc's own session VM; no Ubuntu distro or Docker Desktop is involved in this reproduction.
Other Software
GlobalProtect 6.2.8-h13, connected. Its Windows virtual adapter reports MTU 1400.
Repro Steps
-
Connect GlobalProtect. Configure
%LOCALAPPDATA%\wslc\settings.yamlwith:session: networkingMode: nat
-
Start a fresh
wslcsession. Confirmwslc image listsucceeds and the session'seth0reports MTU 1400 (wslc system session run ip -o link show dev eth0). -
Run
wslc image pull alpine:3.21. -
In the same session, temporarily set
eth0MTU to 1360 withwslc system session run ip link set dev eth0 mtu 1360. Confirm the effective MTU, then repeat the pull. -
Restore MTU 1400, confirm it, and repeat the pull once more.
Expected Behavior
The image pull succeeds with the VPN connected at the MTU configured for the session.
Actual Behavior
Session eth0 MTU |
Result of wslc image pull alpine:3.21 |
|---|---|
| 1400 | Registry manifest HEAD fails with EOF |
| 1360 | Succeeds; image layer downloads and extracts |
| 1400 (restored) | Manifest HEAD fails with EOF again, even though the image is cached |
At MTU 1400, wslc image list works: this is an image-pull transport failure after session startup. In a separate test with GlobalProtect disconnected, wslc successfully pulled busybox:latest. This differs from the Consomme startup/DNS timeout in #41740.
A separate WSL Ubuntu TLS probe on the same VPN path also showed packet-size sensitivity: TCP MSS 1348 stalled, while 1338 succeeded. The large packet was visible leaving the Windows host on the VPN tunnel, but the capture does not identify the downstream drop point. This is consistent with a path-MTU black hole; the MTU A/B above is the direct wslc evidence.
Diagnostic Logs
No raw logs attached; they contain private host and network details.
Activity
github-actions commentedon Oct 3, 2026
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:
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 networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce 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'.
dkbennett commentedon Oct 7, 2026
Assigning to Flor to align with other bug assignment
microsoft-github-policy-service commentedon Oct 14, 2026
This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.
Thank you!