Curl failed by ping can succeeds on WSL2

[Cordius]

Environment

Windows build number: 10.0.19041.0
Your Distribution version: Ubuntu 18.04
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Steps to reproduce

1. Under my company's network, curl always failed but ping can succeeds always on WSL 2.

   cordius@L-81390457-0939:~$ ping www.baidu.com
   PING www.a.shifen.com (180.101.49.11) 56(84) bytes of data.
   64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=1 ttl=45 time=18.3 ms
   64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=2 ttl=45 time=18.7 ms
   64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=3 ttl=45 time=17.9 ms
   ^C
   --- www.a.shifen.com ping statistics ---
   3 packets transmitted, 3 received, 0% packet loss, time 2004ms
   rtt min/avg/max/mdev = 17.952/18.359/18.753/0.345 ms
   
   cordius@L-81390457-0939:~$ curl -vvv www.baidu.com
   * Rebuilt URL to: www.baidu.com/
   *   Trying 180.101.49.12...
   * TCP_NODELAY set
   * connect to 180.101.49.12 port 80 failed: Connection timed out
   *   Trying 180.101.49.11...
   * TCP_NODELAY set
   ^C

2. Under my company's network, curl and ping both succeeds always on WSL 1.
3. Under my family network, curl and ping both succeeds on both WSL1 and WSL 2.

Expected behavior

Curl should succeed too under my company's network on WSL 2.

Actual behavior

Curl failed under my company's network on WSL 2.

Notes

I have tried a lot of workarounds mentiond by other issues such as #4698, but these methods didn't work for me.

BTW, I tried to captures packets by Wireshark and it seems that the TCP SYN can't get a ACK.

[onomatopellan]

Another user could ping but couldn't curl #4926 (comment)
In that case WSL2 connected to the "best looking" NIC on the host, even if that NIC wasn't network-connected.

[Nemykal]

I think I have the same issue. I think this started happening since I installed the most recent windows 10 2004 update KB4557957 - https://support.microsoft.com/en-au/help/4557957/windows-10-update-kb4557957 , but I'm not certain.

According to winver I am running
Version 2004 (OS Build 19041.329)

I see similar issues when trying to curl canhazip.com or any site behind cloudflare. I get the symptoms with curl www.baidu.com too.

I have attached a pcap (zipped) which shows me doing the following in ubuntu 20.04:

ping -c 3 google.com    # Successful
ping -c 3 canhazip.com   # Successful 
sudo apt update    # Successful
curl http://canhazip.com    # Hangs until I Ctrl-C
curl http://www.baidu.com    # Also hangs until I Ctrl-C

wsl2.zip

Unfortunately that windows update KB4557957 doesn't look like it can be uninstalled, so I can't test if this update caused this issue.

I ran Get-NetNat as administrator in powershell and I get no output.

Let me know what other information I can provide.

Thanks,
Michael

[dennisameling]

Having the exact same issue here; it looks like this starts to occur when I switch WiFi networks (home + work), but it's not consistently problematic on a single network. Sometimes it works at home, sometimes it works at work, and when it does, it keeps working until I connect to the other network again. Would also like to hear what info I can provide to help, here's some info for a start:

denni@DESKTOP-HIGHLVU:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=7.36 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=7.03 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=6.46 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=7.05 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=6.82 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 6.455/6.944/7.360/0.298 ms
denni@DESKTOP-HIGHLVU:~$ curl http://google.com
curl: (7) Failed to connect to google.com port 80: Connection timed out

By the way, I seem to always be able to get up and running again by executing the commands described in this article:

• In the search box on the taskbar (click Start), type command prompt, right-click the command prompt result and then select Run as administrator and confirm.
• Type netsh winsock reset and press Enter. (Decline restarting your machine until you have finished running all of the commands)
• Type netsh int ip reset and press Enter.
• Type ipconfig /release and press Enter.
• Type ipconfig /renew and press Enter.
• Type ipconfig /flushdns and press Enter.
• Restart your computer.
• Test to see if the issue is resolved.

[Cordius]

Well, I found what the problem is in my case.
My computer have been installed Symantec Endpoint Protection by security team of my company. And the SEP blocked all TCP traffic sent from WSL2.

[Nemykal]

I tried running the following (I skipped the renew because I use a static IP):

netsh winsock reset
netsh int ip reset

But after a reboot it still didn't work - same symptoms as before.

However, on a whim, I disabled the HyperV feature in windows (Turn Windows Features on or off > HyperV), while leaving the WSL feature enabled.

I rebooted and noted that all hyperV vswitch devices were gone - I had to reconfigure my IP address on the real network adapter again, but once I did that, I tried WSL. After it loaded, it automatically created a WSL vswitch again.

I can successfully run curl http://canhazip.com ; curl http://www.baidu.com now.

Is it possible that the default hyperV vswitch and the WSL vswitch were interfering with each other? I don't know how to see how the bridges are actually configured/layered in windows.

Is there a good way to see what adapter the WSL vswitch is 'bound' to?

[rescenic]

 Fix network issues
# Delete auto-generated files
[root@PC-NAME user]# rm /etc/resolv.conf || true
[root@PC-NAME user]# rm /etc/wsl.conf || true

# Enable changing /etc/resolv.conf
# Enable extended attributes on Windows drives
[root@PC-NAME user]# cat <<EOF > /etc/wsl.conf
[network]
generateResolvConf = false

[automount]
enabled = true
options = "metadata"
mountFsTab = false
EOF

# Use google nameservers for DNS resolution
[root@PC-NAME user]# cat <<EOF > /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF

Try changing nameserver in /etc/resolv.conf
after that exit the linux.

cmd as admin:

wsl --shutdown
netsh winsock reset
netsh int ip reset all
netsh winhttp reset proxy
ipconfig /flushdns

Windows Search > Network Reset

It save me couple times, when installing Gentoo WSL & Funtoo WSL.
ping wget failed, but I can update the repo.

[dennisameling]

Just collected networking logs with the steps described at https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#9-networking-logs and submitted them through the Feedback Hub.

Feedback Hub URL: https://aka.ms/AA8sbrx

[ronia]

Well, I found what the problem is in my case.
My computer have been installed Symantec Endpoint Protection by security team of my company. And the SEP blocked all TCP traffic sent from WSL2.

Did you find a way around Symantec Endpoint Protection?

I am having the same issue, and I just can't use WSL2 at the moment.

[ngocphuongnb]

@rescenic thank you, it worked!

[simonmatt]

@rescenic
Thanks a lot for your solution, it works on my side after I looked so many ways to fix this issue.

[jemini12]

In my case, curl request with multiple big response(more than on object) has error.
So, I decided to shift my windows ubuntu's wsl to wsl1. And now it works fine.

[villelaitila]

I had the similar issue on one of my Windows laptops: the computer had F-Secure firewall enabled, and only after disabling the firewall I could reach internet locations from WSL.

[cakriwut]

Sadly I have to say that all of the above mentions workaround does not work for me. I use Windows 10 Version 20H2.

Previously my WSL2 , Ubuntu-20.04 was working perfectly. I notice the problem only after recent windows update.

My WSL2 statistic:

• nslookup www.google.com, OK
• curl https://www.google.com , ISSUE
• ping 8.8.8.8, OK

If I revert to WSL1, and the issue solved.

[wizcas]

in my case i have to netsh winsock reset and reboot for TWICE. That is awkward.

I looked into the NIC solution and disabled the WLAN, leaving only the ethernet interface. Not sure if it works but I'll see.

[DoisKoh]

Well, I found what the problem is in my case.
My computer have been installed Symantec Endpoint Protection by security team of my company. And the SEP blocked all TCP traffic sent from WSL2.

Thanks... this was my problem as well. Damn.

[MuhShalah007]

 Fix network issues
# Delete auto-generated files
[root@PC-NAME user]# rm /etc/resolv.conf || true
[root@PC-NAME user]# rm /etc/wsl.conf || true

...

# Use google nameservers for DNS resolution
[root@PC-NAME user]# cat <<EOF > /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF

Try changing nameserver in /etc/resolv.conf after that exit the linux.

Thank you, this method has saved my life

[felipecrs]

For those using Symantec Endpoint Protection, I shared a workaround at MicrosoftDocs/WSL#1046 (comment).

Perhaps it could be useful for other firewalls as well.

[moegitree]

Well, I found what the problem is in my case. My computer have been installed Symantec Endpoint Protection by security team of my company. And the SEP blocked all TCP traffic sent from WSL2.

Same on my WSL. Disabled SEP and everything is OK now.

[edtshuma]

For those using Symantec Endpoint Protection, I shared a workaround at MicrosoftDocs/WSL#1046 (comment).

Perhaps it could be useful for other firewalls as well.
I have setup the fix successfully but still getting same error

[edtshuma]

For those using Symantec Endpoint Protection, I shared a workaround at MicrosoftDocs/WSL#1046 (comment).
Perhaps it could be useful for other firewalls as well.
I have setup the fix successfully but still getting same error

I have Symantec yes and despite the workaround Symantec still seems to be blocking traffic :

[edtshuma]

[tbehling]

I've been experiencing inconsistent curl behavior, and tried all of the above options, with no improvement. Bizarrely, ping would always work, and HTTP calls would usually work, and HTTPS calls would usually (but not always!) fail.

This pattern started to smell like a problem with an interface's MTU size. Within WSL2, I adjusted the MTU with the following:

sudo ip link set eth0 mtu 1400

Previously, ip link show eth0 showed an MTU of 1500 (which is normal for Ethernet).

As soon as I changed the MTU to 1400, all the curl tests started working. If I set the MTU back to 1500, the semi-failing behavior came back.

It's not impossible this particular symptom is something to do with my network, but I thought I'd mention it!

That ip link set command won't be effective after a reboot, so next step is to figure out how to make it persistent. Maybe dhcpcd.conf?

[marco-svitol]

@tbehling you are the one! I've experienced exactly the same behaviour and the worst thing is that I was trying to troubleshoot a dockerized env on WSL2.
Took me days and finally landed on your post.
Setting Mtu to 1400 on the WSL2 eth0 nic fixes the problem...now I have to also set mtu on docker virtual nics.

To make "persistent" changes to WSL2, I use the wsl command from Windows at boot time using a scheduled task.
In you case I would do wsl -u root ip link set eth0 mtu 1400
I succesfully use this method to start cron and rsyslog services that are not persistent on WSL2.

[owenstake]

win10 block the WSL interface traffic.
you should do this in the win10 powershell to allow the traffic

sudo Set-NetFirewallProfile -DisabledInterfaceAliases "vEthernet (WSL)"

[CatalinFetoiu]

Hi. Can you please collect networking logs by following the instructions below?
https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues

Please stop WSL, then start the trace, then start WSL and reproduce the issue, then stop the trace

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!