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.

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

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

• WSL2: Jumbo frames are not forwarded to mirrored interface on Linux (#11046), similarity score: 0.81
• Unable to access VPN from WSL2 when networking mode set to mirrored (#11072), similarity score: 0.76
• openvpn connection stops working after upgraded to 2.0.9 with mirrored networking (#10879), similarity score: 0.74

Closed similar issues:

• ping breaks when using experimental.networkingMode=mirrored and a VPN (#10805), similarity score: 0.76
• Unable to use VPN routes from within WSL 2 (#7315), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

from wsl.

I have conducted some experiments:

With MTU 1500:

> curl http://google.com --trace - -L
Successfully received a 301 redirect to www.google.com and downloaded.

With MTU 9000:

> curl http://google.com --trace - -L
Successfully received a 301 redirect but failed to download.

If you use Wireshark, you will observe that all jumbo packets are being ignored. This is why the TCP connection is successfully established, and the HTTP 301 response (825B) can be received, but the webpage from 'www.google.com' (which consists of multiple packets, with the largest being 8203B) cannot be fetched.

If you are using a VPN with an MTU of 9000 and cannot change the VPN configuration, there is a workaround:

Choose the right interface:

> ip a 
...

then

> ip link set dev <interface_name> mtu 1500"

from wsl.

I found similar issue.

VPN issue.
#11361 (comment)

not VPN, but with a 9000 MTU eth0
#11027

and the bot listed.
#11046

from wsl.

Confirmed, the similar issue #11361 is caused by the 9000 MTU setting. the workaround set mtu to 1500 work.

from wsl.

/dupe #11046

from wsl.

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

from wsl.