[WSL2] No network communication between WSL and Windows

[mahmoudajawad]

* Your Windows build number: Microsoft Windows [Version 10.0.18917.1000]
UPDATE: After upgrading to 10.0.18922.1000, I can now access any daemon started from WSL using the VM IP.

• Your Windows build number: Microsoft Windows [Version 10.0.18922.1000]

• What you're doing and what's happening: I can't communicate with Windows daemons from WSL and vice-versa.

• What's wrong / what should be happening instead: Since, WSL2 is a standalone machine, It got its own IP as well as the bridge on Windows. Although I was able to successfully pick the IP of both, I still can't access any daemon started from WSL or Windows from the other side WSL.

This is probably the same as #4192, but since that one is closed with no proper instructions or issue resolution, I'm opening this here.

Answer is here: #4212 (comment) (thanks to @onomatopellan)

[mahmoudajawad]

@therealkenc, can I get the reference of the duplicate issue you are referring to when closing this one? I understand you are under huge pressure of endless number of issues, but closing the issue like this doesn't help.

[therealkenc]

You cited the issue. Yes; since you were unblocked (re: "UPDATE"), and there was not enough information for any actionable, it just got the tag. Whether #4192 it is the "same" or not, fair enough. I've deduped ya. But changing this status to open+question is (perhaps) academic. There were no changes in 18922 that would unblock "network communication" but I could be wrong, natch.

[mahmoudajawad]

@therealkenc, thanks a lot! Appreciate reopening it.

Same wise, fair enough, it could've been some issue on my device that related to me being unable to access WSL[2] services from Windows, that I got over in the same time with the update to 18922. My concern is now accessing Windows services from WSL[2] for many reasons.

[aamkye]

Same here, running docker run -d -p 0.0.0.0:8080:8080 nginxdemos/hello in wsl2 build: 18922 and trying to reach localhost:8080 from windows gives timeout.

[mahmoudajawad]

@amadeuszkryze, this won't work. To access your WSL2 daemons follow what is mentioned here: #4192 (comment)

[aamkye]

@AjawadMahmoud if you mean to use cat /etc/resolv.conf | grep nameserver, it always points to 192.168.124.1 and it's not working for me. I could also mentioned doc1 and doc2 as an official documentation, but it's not working for both ways (linux->windows and windows->linux).

[mahmoudajawad]

For me, Linux to Windows isn't working either, but Windows to Linux is working fine. Could it be a firewall rule no your WSL that is preventing Windows from reaching it, since it's now considered a foreign machine.

[mahmoudajawad]

So, from the lack of interaction in this direction, can I understand that none else but me is not able to connect to Windows services from WSL2? For instance, I have mongodb and Python web server running in Windows, and I can't access them from WSL2 no matter what IP I use.

Any luck with this?

[onomatopellan]

@AjawadMahmoud I just tested a python3 http simple server on a VM with 18922 and these are the results:

python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [02/Jul/2019 17:36:29] "GET / HTTP/1.1" 200 - --> From Edge Browser
127.0.0.1 - - [02/Jul/2019 17:54:16] "GET / HTTP/1.1" 200 - --> From Edge Browser
127.0.0.1 - - [02/Jul/2019 18:11:38] "HEAD / HTTP/1.1" 200 - --> From WSL1 (curl --head localhost:8000)
192.168.34.117 - - [02/Jul/2019 18:12:52] "HEAD / HTTP/1.1" 200 - --> From WSL2 (curl --head 192.168.34.113:8000)
192.168.34.117 - - [02/Jul/2019 18:14:22] "HEAD / HTTP/1.1" 200 - --> From WSL2 (curl --head 192.168.34.113:8000)

The only thing I did was open TCP and UDP for windows python on the Windows Firewall.

[mahmoudajawad]

@onomatopellan, since you are using python3 I assume you are starting Python server from WSL2 and not Windows, right? This is fine with me, I can access WSL2 from Windows, but I can't access Windows services from WSL2.

What is confusing is that you said:

The only thing I did was open TCP and UDP for windows python on the Windows Firewall.
If this is the case then you are really touching on the problem and all what I need to do is opening the ports in Windows Firewall.

I'll give this a shot and comment on this later.

Thanks for your input.

[onomatopellan]

It's python3.exe downloaded from the Windows Store and launched from cmd.

File on Windows Firewall is

C:\program files\windowsapps\pythonsoftwarefoundation.python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\python.exe

[mahmoudajawad]

Wow! I knew I've added Python and MongoDB to Windows Firewall rules, but what I didn't do was marking Public networks. And, although I'm on Private network, by simply marking Public I was able to access both without an issue. Thanks for pointing this up @onomatopellan, I wouldn't have made this attempt without your message that confirmed this.

UPDATE:
To anyone coming here in the future looking for the answer, two things:

1. Accessing WSL2 services from Windows is never an issue as long as you are picking the correct IP via ip addr show eth0 in WSL2.
2. Accessing Windows services from WSL2 should be fine given:
   a. You add Inbound Rule exception for the service you have on Windows on Private, Public networks.
   b. Use the correct IP to connect to Windows.

As a quick hack, you can add:

export WSL_HOST_IP=$(ipconfig.exe | awk '/WSL/ {getline; getline; getline; getline; print substr($14, 1, length($14)-1)}')

at the end of your ~/.profile for your debian-based distro or ~/.bash_profile for your redhat-based distro. This would give you the env variable $WSL_HOST_IP available in your distro and updated always with the correct IP of your Windows bridge, so you can easily do stuff like:

ping $WSL_HOST_IP
curl $WSL_HOST_IP:8080

[mahmoudajawad]

@bitcrazed, Are you planning any change to this behaviour? If not I would like to contribute to WSL project with a hack guide to explain the same based on the input from this issue. However, I don't want to start publishing details that you are planning to change its behaviour which might result in some future confusion to some.

Could you confirm whether your team are planning to share ports between WSL2 distros and Windows likewise in WSL1 or this is going to be the behaviour going forward?

[therealkenc]

planning to share ports between WSL2 distros and Windows likewise in WSL1 or this is going to be the behaviour going forward?

Ben basically answered that in #4199 here. Status "hypothetically".

But even if, hypothetically, sharing IP address space (sic) à la WSL1 is in the cards, it will almost certainly be behind some yet-to-be imagined configuration setting. Reason being, separation of the address space is a feature not a bug in many use cases. The new behavior (that you have to access the WSL2 side with its address, and the Win10 side with its address) is detailed here. This is all pretty standard fare for folks used to VBox/VMware/QEMU/Hyper-V. It is just taking some getting used to for folks coming off WSL1. Whatever you pen will very likely remain applicable (and has been applicable since VMs were invented).

Since I'm here: Like your use of interop to set $WSL_HOST_IP. Interesting tid-bit: that would be harder to do with a traditional VM like say QEMU, because the VM client has (to a first order) no idea it is living on a Windows host. [Granted usually in that scenario you've set up local names via DNS and aren't going to futz with IPv4 addresses.]

[mahmoudajawad]

separation of the address space is a feature not a bug in many use cases

Agree. I'm not saying it's bad. I'm just trying to figure out what's the team approach towards this going forward.

Like your use of interop to set $WSL_HOST_IP

This coming from a WSL team member is a good sign I was right in using such an approach.

Alright, then I'm going to finalise a hack guide I just started working on and would post it as separate issue and would welcome your comment on it as well as any other one interested in it. Hope it becomes some part of WSL eco-system as well.

[craigloewen-msft]

@AjawadMahmoud we always encourage people to write articles and build ontop of WSL! Like the user cerebrate who implemented systemd in WSL 2 or ibuildthecloud who made instructions on running k3s in WSL 2.

And as stated in our docs we are looking into adding localhost capabilities into WSL 2.

[mahmoudajawad]

That's great, @mscraigloewen. So, I've prepared some form of a hack guide that involves some risk in using it. I would like to have you and the team review it to see if any of the uses in it can be refactored into more safe and secure and novice-ready:

https://github.com/AjawadMahmoud/wsl-hacks/blob/master/wsl2-networking.md

To make this clear, this is what I'm currently using and it's doing great job helping me using WSL2. So, this is not a question about the validity, rather security review of the instructions mentioned, or even better, a call to include the functionality as built-in into WSL2 (and getting my name as contributor to this great project 😁).

[relipse]

I am running elasticsearch on port 9200 on my Windows side, after opening the firewall, I finally got GET traffic through from my wsl2 ubuntu side using curl http://172.30.224.1:9200 but when I try to use PUT to put an index, it just hangs indefinitely. Anyone know what is going on?