No internet connectivity from WSL2/Ubuntu

[j0057]

• Your Windows build number: 10.0.19041.84

• What you're doing and what's happening:

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]

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]

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]

@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]

@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]

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).

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]

@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]

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]

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]

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]

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]

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]

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.

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]

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]

my issue was wit AVG Internet security enhanced firewall