microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.26k stars 812 forks source link

No internet connectivity from WSL2/Ubuntu #4926

Closed j0057 closed 4 years ago

j0057 commented 4 years ago

I'm getting timeouts when trying to connect to internet from a WSL2 instance. DNS works, and the WSL2 instance can see/ping the host without problem.

$ ip route
default via 172.24.64.1 dev eth0
172.24.64.0/20 dev eth0 proto kernel scope link src 172.24.66.230
$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.24.64.1
$ dig +noall +answer microsoft.com
microsoft.com.          0       IN      A       13.77.161.179
microsoft.com.          0       IN      A       40.76.4.15
microsoft.com.          0       IN      A       40.112.72.205
microsoft.com.          0       IN      A       40.113.200.201
microsoft.com.          0       IN      A       104.215.148.63
$ curl -4sv -m5 https://microsoft.com/
*   Trying 13.77.161.179...
* TCP_NODELAY set
* After 2498ms connect time, move on!
* connect to 13.77.161.179 port 443 failed: Connection timed out
*   Trying 40.76.4.15...
* TCP_NODELAY set
* After 1249ms connect time, move on!
* connect to 40.76.4.15 port 443 failed: Connection timed out
*   Trying 40.112.72.205...
* TCP_NODELAY set
* After 623ms connect time, move on!
* connect to 40.112.72.205 port 443 failed: Connection timed out
*   Trying 40.113.200.201...
* TCP_NODELAY set
* After 311ms connect time, move on!
* connect to 40.113.200.201 port 443 failed: Connection timed out
*   Trying 104.215.148.63...
* TCP_NODELAY set
* After 155ms connect time, move on!
* connect to 104.215.148.63 port 443 failed: Connection timed out
* Failed to connect to microsoft.com port 443: Connection timed out
* Closing connection 0

Based on what I know about Hyper-V networking, my Internal switch may or may not route packets from the VM to the internet, but in order for packets to be routed back, the traffic from the WSL2 VM will need to be NAT'ed.

On the host, in Powershell, Get-NetNat returns no results:

PS C:\WINDOWS\system32> Get-NetIPAddress -InterfaceIndex 59 | Format-Table

ifIndex IPAddress                                       PrefixLength PrefixOrigin SuffixOrigin AddressState PolicyStore
------- ---------                                       ------------ ------------ ------------ ------------ -----------
59      fe80::xxxx:xxxx:xxxx:xxxx%59                              64 WellKnown    Link         Preferred    ActiveStore
59      172.24.64.1                                               20 Manual       Manual       Preferred    ActiveStore

PS C:\WINDOWS\system32> Get-VMSwitch -name WSL | Format-List

Name                                             : WSL
Id                                               : 32874a54-04c6-4677-a51f-77c5245345a5
Notes                                            :
Extensions                                       : {Microsoft Windows Filtering Platform, Microsoft Azure VFP Switch Extension, Microsoft NDIS Capture}
BandwidthReservationMode                         : Absolute
PacketDirectEnabled                              : False
EmbeddedTeamingEnabled                           : False
IovEnabled                                       : False
SwitchType                                       : Internal
AllowManagementOS                                : True
NetAdapterInterfaceDescription                   :
NetAdapterInterfaceDescriptions                  :
NetAdapterInterfaceGuid                          :
IovSupport                                       : False
IovSupportReasons                                :
AvailableIPSecSA                                 : 0
NumberIPSecSAAllocated                           : 0
AvailableVMQueues                                : 0
NumberVmqAllocated                               : 0
IovQueuePairCount                                : 0
IovQueuePairsInUse                               : 0
IovVirtualFunctionCount                          : 0
IovVirtualFunctionsInUse                         : 0
PacketDirectInUse                                : False
DefaultQueueVrssEnabledRequested                 : True
DefaultQueueVrssEnabled                          : False
DefaultQueueVmmqEnabledRequested                 : True
DefaultQueueVmmqEnabled                          : False
DefaultQueueVrssMaxQueuePairsRequested           : 16
DefaultQueueVrssMaxQueuePairs                    : 0
DefaultQueueVrssMinQueuePairsRequested           : 1
DefaultQueueVrssMinQueuePairs                    : 0
DefaultQueueVrssQueueSchedulingModeRequested     : StaticVrss
DefaultQueueVrssQueueSchedulingMode              : Dynamic
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor          : False
SoftwareRscEnabled                               : False
BandwidthPercentage                              : 0
DefaultFlowMinimumBandwidthAbsolute              : 0
DefaultFlowMinimumBandwidthWeight                : 0
CimSession                                       : CimSession: .
ComputerName                                     : NB-XXXXXXX
IsDeleted                                        : False
DefaultQueueVmmqQueuePairs                       : 0
DefaultQueueVmmqQueuePairsRequested              : 16

When trying to set up a new NAT rule, I get a seemingly unrelated error:

PS C:\WINDOWS\system32> New-NetNat -Name "WSLNetworkNAT" -ExternalIPInterfaceAddressPrefix 172.24.64.0/20
New-NetNat : The parameter is incorrect.
At line:1 char:1
+ New-NetNat -Name "WSLNetworkNAT" -ExternalIPInterfaceAddressPrefix 17 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (MSFT_NetNat:root/StandardCimv2/MSFT_NetNat) [New-NetNat], CimException
    + FullyQualifiedErrorId : Windows System Error 87,New-NetNat
rm-bergmann commented 4 years ago

I have the same problem, however I get this output from Get-NetNat:

Name                             : NATNetwork2
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.0.0/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : True

Name                             : NATnetwork
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.56.102/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : True

Name                             : MyNATnetwork
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 172.21.21.0/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : True

$ ip route (wsl bash)

default via 172.30.160.1 dev eth0
172.30.160.0/20 dev eth0 proto kernel scope link src 172.30.168.189
j0057 commented 4 years ago

A colleague helpfully pointed out that Symantec Endpoint Protection includes a firewall that blocks the requests from the WSL2 context. (Incidentally, Symantec EP is according to themselves "not supported" for workloads that include running VM's in Hyper-V.)

As for the NAT rules -- with the firewall temporarily disabled I can do a request to the internet, but Get-NetNAT still does not return anything, so, apparently, these NAT rules are not needed for WSL2. I'm now wondering how it does work under the hood.

j0057 commented 4 years ago

@rm-bergmann Those NAT rules you're seeing could be related to other virtual switches. You should be able to find out using Get-NetIPAddress | Format-Table and Get-NetAdapter cmdlets -- you can correlate the interfaceIndex fields.

rm-bergmann commented 4 years ago

@j0057 Thank you, you have helped me solve my problem that I have been debugging for over 3 months! Those NAT rules that I had there (probably from previous VM's) were conflicting with WSL2, so I removed them with Remove-NetNat and boom! WSL2 networking is fixed (in my case)!

natronkeltner commented 4 years ago

I ran into this for much of today on 10.0.19546. I have no NetNATs, have Windows AV, and disabled the firewall for testing. WSL1 works fine, WSL2 does not.

From inside WSL2 I could ping my host interfaces and DNS worked fine, but nothing routed.

I experimented with removing options, explicitly setting interface metrics, uninstalling and reinstalling docker, reboots, but nothing worked. I eventually found this partial workaround:

1) Manually enable Internet Connection Sharing: right click the network adapter you want to share, properties, sharing, then enable it for vEthernet (WSL).

image

2) The IP address for WSL now changed to some default ICS IP, 192.168.137.1. In WSL2 Ubuntu, edit the eth0 interface to be in the same subnet: ip addr add 192.168.137.10/24 dev eth0

3) Change the default gateway (ip route delete default and ip route add default via 192.168.137.1)

4) Change DNS (manually edit /etc/resolv.conf)

And it finally had internet. It goes back to defaults on wsl2 shutdown, of course. This also doesn't handle moving from wired to wireless.

Something is definitely broken in the Hyper-V NAT / Routing pieces for vEthernet (WSL), but I couldn't figure it out.

j0057 commented 4 years ago

@natronkeltner Small data point: when I navigate to the Sharing tab of both my uplink adapter as well as the vEthernet adapter, they say "Internet Connection Sharing has been disabled by the Network Administrator". So I'm not even sure how networking is supposed to work in WSL2!

Sidneys1 commented 4 years ago

So I went through this entire thread as well as #4731 with no solution to my problem, which is slightly different:

I am able to ping internet resources, such as google.com or 1.1.1.1, but I can't access them with wget or curl (e.g., curl -4v google.com).

I went so far as to uninstall Ubuntu-18.04, disable the Windows Feature Windows Subsystem for Linux, then re-enable/re-install. I've messed with the network address and routing settings. I've messed with Hyper-V adaptors. I've messed with Windows reserved ports and dynamic port ranges which have been an issue for me in the past. I've turned windows firewall on-off. I've rebooted about a million times. Still no-go. Some output:

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=55.9 ms
$ curl -4v 1.1.1.1
* Rebuilt URL to: 1.1.1.1/
*   Trying 1.1.1.1...
* TCP_NODELAY set
^C

So I thought, what else is a lightweight utility VM? Windows Sandbox! So I opened that and in there I can ping, but not browse (with edge) as well... However with curl.exe I can get google.com's redirect page to www.google.com but not www.google.com itself... :(

rm-bergmann commented 4 years ago

I eventually found the underlying problem I had which caused my networking to break in WSL2. My previous fix (hack) to set up a network bridge didn't fix my underlying problem. I found that I had some NAT adapters from previous VM's that were set up in Hyper-V. Removing them fixed all my network issues.

In powershell I ran the cmd Get-NetNat and there were 3 NAT's listed. I shutdown WSL and I ran the Remove-NetNat cmd, which restored my networking and internet connectivity in WSL2.

Sidneys1 commented 4 years ago

Yeah, I tried that - I had no NetNat objects listed.

I should add that I'm on the latest insider build and have the Docker WSL engine installed, but I disabled that as part of hunting down this issue.

~Sidney Borne

Sidneys1 commented 4 years ago

I finally found the underlying problem! I installed Wireshark and attached to the WSL vSwitch to see if I could diagnose the problem there and...

Turns out all the Ping replies were coming from the same MAC address - and that MAC belonged to an OpenVPN TAP NIC on my host. I uninstalled the NIC and wsl --shutdown/restarted and networking works again!

It looks like WSL2 connects to the "best looking" NIC on the host, even if that NIC isn't network-connected. They should add a wsl.conf setting to control what NIC WSL2 gets attached to.

Edit: for you poor souls finding this in 2021, disabling the NIC works as well as uninstall it!

luxzg commented 4 years ago

They should add a wsl.conf setting to control what NIC WSL2 gets attached to... and do that for each WSL2 distro, and allow not to use bridge, and... it is still going to worldwide distribution "as is" apparently as W10 2004. I had high hopes for WSL2, but as it stands now, I'm better off keep having few Linux VMs on my local Hyper-V. At least I know which VM is tied to which adapter, which VLAN, which subnet, and which (static!) IP.

natronkeltner commented 4 years ago

It took forever to figure this out so I'll document it here in case someone comes along and finds this. I used Microsoft Message Analyzer with the Hyper-V-VmSwitch and NDIS-PacketCapture providers, which will show exactly how the internal switches are routing packets.

image

This allowed me to see the outbound TCP packets, the inbound TCP responses, and that they were being filtered at the switch level due to a VLAN tag.

MessageNumber   DiagnosisTypes  Timestamp   TimeElapsed Source  Destination Module  Summary 
502 None    2020-03-20T16:21:09.3340883             Microsoft_Windows_Hyper_V_VmSwitch  NBL 0xFFFF90079978BA40 received from Nic 14B75DAC-3764-4D7F-84B6-8F39004014B2 (Friendly Name: WSL) in switch D57EE459-57B6-4965-B86E-1906ABAECB70 (Friendly Name: WSL)  
503 None    2020-03-20T16:21:09.3340929             Microsoft_Windows_Hyper_V_VmSwitch  NBL originating from Nic 14B75DAC-3764-4D7F-84B6-8F39004014B2 (Friendly Name: WSL) was dropped in switch D57EE459-57B6-4965-B86E-1906ABAECB70 (Friendly Name: WSL), Reason VLAN Filtered (Status:Unknown NTSTATUS Error code (0xE0000003))  

... was dropped in switch D57EE459-57B6-4965-B86E-1906ABAECB70 (Friendly Name: WSL), Reason VLAN Filtered

My network port was slightly misconfigured and VLAN tagged packets were being sent to my system, but I had never noticed before because nothing connected to this switch port had ever cared before. Windows didn't care (and didn't show me, either, when using Wireshark/npcap). WSL1 also didn't care that inbound packets were tagged. WSL2, however, uses hyper-v switches, which do care about VLAN tags and silently drop packets that are tagged.

Fixing my network port to strip packets of VLAN tags fixed my issue and the hyper-v switches now work fine.

mitsuka commented 4 years ago

In my environment, I disabled everything in the BIOS except for the interface connected to the internet. After that, the internet connectivity was restored.

walidshaari commented 4 years ago

my issue was wit AVG Internet security enhanced firewall

anthonysomerset commented 4 years ago

For those that use Symantec Endpoint Protection and disabling it works

the specific config that seems to get things working again without a complete disable is to allow unmatched IP traffic as per the attached screenshot Screenshot 2020-04-15 15 43 51

dennisameling commented 4 years ago

Turns out all the Ping replies were coming from the same MAC address - and that MAC belonged to an OpenVPN TAP NIC on my host. I uninstalled the NIC and wsl --shutdown/restarted and networking works again!

Had the same issue here, there was a TAP NIC left from some old OpenVPN installation. Working as expected now 🚀

oidualc commented 4 years ago

For those that use Symantec Endpoint Protection and disabling it works

the specific config that seems to get things working again without a complete disable is to allow unmatched IP traffic as per the attached screenshot Screenshot 2020-04-15 15 43 51

This is unfortunate! In my case in a work PC the damn Symantec Endpoint Protection is blocking the communications for WSL2 (not WSL though..), but on the other end I cannot modify that setting because it's blocked by the organization. Why this is a problem only for WSL2? And most importantly, is there anything else that can be done without touching the SEP settings?

anthonysomerset commented 4 years ago

Your only options is to downgrade to wsl1 and wait for Symantec to release an update

Or ask your org it team for the setting to be changed temporarily

Anthony Somerset

Please excuse the brevity or any typos, tapped out from my iPhone

loscil412 commented 4 years ago

Hi, I solved this issue -- being able to ping addresses but not 'communicate' directly with them (in particular, github.com).

I have avast firewall turned on. Checking the avast fw settings, a few things stood out:

The adapter description was Hyper-V Virtual Ethernet Adapter #3.

  1. My network was set as a public network. I changed it to a private network (which it is :)).

  2. In settings (a blue link under firewall profile) I set ALLOW For programs with no defined rules (i.e. programs not listed on the Application Rules page) This setting was defaulted to 'Auto-Decide'

I haven't done too much more at this point than verify that I can curl google, and git pull without issue within Ubuntu on WSL2.

I'm on build 19041.330

samnf commented 4 years ago

For me, the "resolution" ended up being to restart my PC 🤦 .. So make sure you try that before anything too crazy

Karlheinzniebuhr commented 4 years ago

Having the same issue, installed brand new ubuntu 20.04 with WSL 2 but cannot ping 8.8.8.8 nor any IP out in the internet from ubuntu

onomatopellan commented 4 years ago

@Karlheinzniebuhr make sure you didn't hit this bug #5437

Karlheinzniebuhr commented 4 years ago

Fixed by applying this https://github.com/microsoft/WSL/issues/5336#issuecomment-668773304

============================================================================= FIX WSL2 NETWORKING IN WINDOWS 10 cmd as admin: wsl --shutdown netsh winsock reset netsh int ip reset all netsh winhttp reset proxy ipconfig /flushdns

Windows Search > Network Reset

Restart Windows

fkguo commented 4 years ago

Fixed by applying this #5336 (comment)

============================================================================= FIX WSL2 NETWORKING IN WINDOWS 10 cmd as admin: wsl --shutdown netsh winsock reset netsh int ip reset all netsh winhttp reset proxy ipconfig /flushdns

Windows Search > Network Reset

Restart Windows

Thank you for the tip. I followed these steps, but unfortunately I completely lost my internet connection even for windows...

ipconfig /all shows media disconnected, and I tried methods that I found on line, but no one worked... Any clue?

Karlheinzniebuhr commented 4 years ago

Do you need to set up a static IP with a specific gateway? I suspect your lan has no DHCP server and you might need to setup your previous configuration

fkguo commented 4 years ago

Do you need to set up a static IP with a specific gateway? I suspect your lan has no DHCP server and you might need to setup your previous configuration

Thanks for the quick reply. No, the previous setting was automatic. I don't need to set anything in principle...

One of the steps I followed was to netsh int ip reset reset.log as an administrator. One of the resettings failed. Don't know whether this is related or not.

fkguo commented 4 years ago

Issue solved: it turns out that somehow the wlan autoconfig service was not automatically started. It was fixed by Win+R -> services.msc, and then change the startup type for WLAN AutoConfig from Manual to Automatic.

viralrsejpal commented 3 years ago

Fixed by applying this #5336 (comment)

============================================================================= FIX WSL2 NETWORKING IN WINDOWS 10 cmd as admin: wsl --shutdown netsh winsock reset netsh int ip reset all netsh winhttp reset proxy ipconfig /flushdns

Windows Search > Network Reset

Restart Windows

I was using Ubuntu on windows, Following the above mentioned steps I also had to Reset the app. Steps to Follow:

Windows -> Ubuntu -> App Settings ( context menu/right click ) -> Reset App.

This will delete your data, I was just setting up this so I did not have any data. Thank you

fandykun commented 3 years ago

Having the same issues after updating windows insiders into build 20215. I solved this by restarting my PC.

SangNguyenTL commented 3 years ago

Having the same issues after updating windows insiders into build 20215. I solved this by restarting my PC.

Me too. But sometimes it still doesn't work. It is pathetic when playing gambling. 👎

raidenii commented 3 years ago

Another way of allowing traffic for people use Symantec Endpoint Protection without allowing all IP traffic:

Add a firewall rule that allows IP traffic (or traffic you want, like IP protocol 1 (ICMP), 6 (TCP) and 17 (UDP)) on the Hyper-V adapter, both directions. You can find which adapter WSL2 uses in Network & Sharing Center (it will say vEthernet (WSL) in its name).

daneb commented 3 years ago

I have the same problem and I've lost close to 3 hours of my time today alone. Machine goes to sleep. WSL2 loses internet. Reset Hyper-V. Shutdown WSL. Reset Winsock. Reset Network. Try setup routing manually. Try use two nics. URRRGH still nothing!!! There are so many of these reported problems and they just seem be getting closed without resolution.

😪😪😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥😥

matthiasradde commented 3 years ago

For me ping to IP-addresses (even on the internet) are working. But DNS was not working :-( So I changed my /etc/resolv.conf to use 8.8.8.8 as DNS-server and created the /etc/wsl.conf as described in /etc/resolv.conf Might be a workaround but now the internet-connection from WSL2 is working again - at least for me. :-)

BTW: I'm using Win10 Build 19041.508 and Ubuntu with WSL2 and no additional Kaspersky/Symantec/whatever and have restarted my system.

camilo-agudelo commented 3 years ago

I was having the same problem with WSL2/Ubuntu. Ping did work but general connectivity (e.g. curl or telnet) did not. When I downgraded WSL version to 1 everything worked fine.

I solved the issue by disabling Hyper-V in Windows Features.

deduble commented 3 years ago

In my case just disabling the TAP OpenVPN Adapter worked. thanks to sydneys1 answer.

dennisameling commented 3 years ago

For me remvoing the TAP OpenVPN adapter indeed seems to have solved the issue. Fingers crossed it will keep working now 🤞

danton721 commented 3 years ago

Windows Search > Network Reset

Worked as a charm. But as my Windows is set in another language, just had a trouble to find this specific Network reset step. To help others: Windows Configurations -> Network -> On the "Status" tab, which should be already opened -> Last button on the page, there is the reset network

HiFiPhile commented 3 years ago

If you have multiple NICs try to set metric manually. I've one GbE NIC for Internet and one 10GbE NIC for internal network, I've tried all workarounds but nothing works. Finally I saw the metric of 10GbE is lower than GbE, so I set the metric of GbE to 1 and problem solved.

ubermanl commented 3 years ago

Facing the same issue here, it's very strange ip a | grep eth0

4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 172.26.231.97/20 brd 172.26.239.255 scope global eth0

ip route

default via 172.26.224.1 dev eth0
172.26.224.0/20 dev eth0 proto kernel scope link src 172.26.231.97

ipconfig

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::4410:dab:396c:135d%68
   IPv4 Address. . . . . . . . . . . : 172.31.160.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::d899:fefa:fc81:2e07%95
   IPv4 Address. . . . . . . . . . . : 172.26.224.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

winver image

Debian 10.5 installed thru Ms store.

Can ping the debian network ip from powershell

Pinging 172.26.231.97 with 32 bytes of data:
Reply from 172.26.231.97: bytes=32 time<1ms TTL=64
Reply from 172.26.231.97: bytes=32 time=1ms TTL=64
Reply from 172.26.231.97: bytes=32 time=1ms TTL=64

but the other way, just doesnt work at all

PING 172.26.224.1 (172.26.224.1) 56(84) bytes of data.
^C
--- 172.26.224.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 191ms

Tried uninstalling and reinstalling several times, with no success, also setting static routes doesn't work, and tried changing Hyper-V Virtual Switch, but whenever i select my wifi adapter, wifi connection goes down, and a reboot is needed to get it back working.

Also setting /etc/resolv.conf doesn't work.

guigoalmeida commented 3 years ago

Another way of allowing traffic for people use Symantec Endpoint Protection without allowing all IP traffic:

Add a firewall rule that allows IP traffic (or traffic you want, like IP protocol 1 (ICMP), 6 (TCP) and 17 (UDP)) on the Hyper-V adapter, both directions. You can find which adapter WSL2 uses in Network & Sharing Center (it will say vEthernet (WSL) in its name).

How can one do that? Apparently, symantec endpoint protection firewall rules ('security exception risks') should relate to either 1) known risks, 2) files, 3) folders, 4) extensions, or 5) web domains. (these might not be the exact terms: I am roughly translating back from my interface, which is in Portuguese).

i have tried to make an exception to wsl.exe, under Windows/System32, but it apparently did not work properly. How could one make exceptions only for certain types of IP traffic?

In my case, internet seems to be working rather properly (I can ping google.com with good results), but ubuntu's servers (for apt get update, for instance) do not work, and http addresses within command line instructions do not work either.

sboonyakiatACR commented 3 years ago

For people with SEP. I had to add new firewall rule in SEP console to allow both local and remote port 80,443. Only remote doesn't work, for some reason.

ubermanl commented 3 years ago

For people with SEP. I had to add new firewall rule in SEP console to allow both local and remote port 80,443. Only remote doesn't work, for some reason.

I have tried with SEP disabled, but still not working.

jsteenri commented 3 years ago

Since I found myself here and then eventually found a workaround elsewhere, sharing that resource as well: https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723

hatranpro commented 3 years ago

A colleague helpfully pointed out that Symantec Endpoint Protection includes a firewall that blocks the requests from the WSL2 context. (Incidentally, Symantec EP is according to themselves "not supported" for workloads that include running VM's in Hyper-V.)

As for the NAT rules -- with the firewall temporarily disabled I can do a request to the internet, but Get-NetNAT still does not return anything, so, apparently, these NAT rules are not needed for WSL2. I'm now wondering how it does work under the hood.

I confirm the issue with WSL2 is if Symantec Endpoint Protection running. I was able to connect to the internet after stopping Symantec Endpoint Protection. Thank you.

kevingosse commented 3 years ago

I ran into the same problem (ping working, not curl). In my case it seems it was another occurrence of https://github.com/microsoft/WSL/issues/4926#issuecomment-597146860. I couldn't find how to capture packets from the WSL network interface in Wireshark, so I just shutdown WSL, disabled a bunch of network adapters, and ran WSL again, and it worked.

rjudin commented 3 years ago

Our team reports about verified workaround https://github.com/sakai135/wsl-vpnkit with window 10 build 1909, that you could try

Adriano-Santtos commented 3 years ago

Hi, I solved this issue -- being able to ping addresses but not 'communicate' directly with them (in particular, github.com).

I have avast firewall turned on. Checking the avast fw settings, a few things stood out:

The adapter description was Hyper-V Virtual Ethernet Adapter #3.

  1. My network was set as a public network. I changed it to a private network (which it is :)).
  2. In settings (a blue link under firewall profile) I set ALLOW For programs with no defined rules (i.e. programs not listed on the Application Rules page) This setting was defaulted to 'Auto-Decide'

I haven't done too much more at this point than verify that I can curl google, and git pull without issue within Ubuntu on WSL2.

I'm on build 19041.330

It worked for me. Thank you!

kdxcxs commented 3 years ago

After trying every single way mentioned above and failed, I finally manage to find a way that works for me. Just run netsh int ipv4 set dynamic tcp start=49152 num=16384 as Administrator and wsl could reach the internet.

I've set some Protocol tcp Port Exclusion Ranges before as Docker and JetBrains' IDEs could not run properly, which might just cause this issue.

ambethell commented 3 years ago

Our team reports about verified workaround https://github.com/sakai135/wsl-vpnkit with window 10 build 1909, that you could try

I can confirm this helped me get around SEP (14.2.RU2 MP1 build 5569 - 14.2.5569.2100) issues. The configuration for my version of SEP also had 'allow IP traffic' on unmatched IP traffic settings but the logs were still showing it blocking wsl outbound connections.

raidenii commented 3 years ago

Another way of allowing traffic for people use Symantec Endpoint Protection without allowing all IP traffic: Add a firewall rule that allows IP traffic (or traffic you want, like IP protocol 1 (ICMP), 6 (TCP) and 17 (UDP)) on the Hyper-V adapter, both directions. You can find which adapter WSL2 uses in Network & Sharing Center (it will say vEthernet (WSL) in its name).

How can one do that? Apparently, symantec endpoint protection firewall rules ('security exception risks') should relate to either 1) known risks, 2) files, 3) folders, 4) extensions, or 5) web domains. (these might not be the exact terms: I am roughly translating back from my interface, which is in Portuguese).

i have tried to make an exception to wsl.exe, under Windows/System32, but it apparently did not work properly. How could one make exceptions only for certain types of IP traffic?

In my case, internet seems to be working rather properly (I can ping google.com with good results), but ubuntu's servers (for apt get update, for instance) do not work, and http addresses within command line instructions do not work either.

By adding a firewall rule on the WSL network adapter. Not the application settings, but configure firewall rules.