[WSL2] share localhost with Windows

[karuboniru]

• Your Windows build number:
  C:\Users\XXXX>ver
  Microsoft Windows [版本 10.0.18922.1000]

• What you're doing and what's happening:
  [XXX@XXX ~]$ netstat
  Active Internet connections (w/o servers)
  Proto Recv-Q Send-Q Local Address Foreign Address State
  tcp 0 0 localhost:52742 localhost:x11 ESTABLISHED
  tcp 0 0 localhost:52702 localhost:x11 ESTABLISHED
  tcp 0 0 localhost:52784 localhost:x11 ESTABLISHED
  tcp 0 0 localhost:52700 localhost:x11 ESTABLISHED
  tcp 0 0 localhost:52780 localhost:x11 ESTABLISHED

[ed, KC... some snips]

• What's wrong / what should be happening instead:
  Host don't share loopback with WSL guest (At least now). Reserve DNS takes host's ip as localhost may be confusing

172.17.58.195 is the ip address of the guest. 172.17.58.193 is the ip address of the host.
The problem occurs on every program using reserve dns.

[therealkenc]

This one is fundamentally dupe #4106, but we need a landing zone for the request to share localhost in WSL2 à la WSL1. For the time being (if or until that changes) this is by-design.

As a rider, not only does WSL not share the IP address space, the address assigned to the container is not stable to the Distribution (like Forest Gump, you never know what IP address you're gonna get). This is exceedingly problematic for numerous common dev scenarios. It would be better if:

(a) The nonroutable (usually 192* or 172*) segment were shared, and the MAC address made stable, so the user's DHCP can serve up a stable IP address, or
(b) Let the address float, but serve up a stable DNS entry based on the Distro name, or
(c) Both

Note that the current practice of serving up the same Windows hostname (for me, DESKTOP-BNN97ME) on different addresses (as of this writing also by-design behavior) is also problematic because it brings down the whole ssh key exchange (and by extension git) edifice.

[transtone]

Note that the current practice of serving up the same Windows hostname (for me, DESKTOP-BNN97ME) on different addresses (as of this writing also by-design behavior) is also problematic because it brings down the whole ssh key exchange (and by extension git) edifice.

#4208

[benhillis]

@transtone - Makes sense. May be prudent to change the WSL2 hostname until (hypothetically) we can share IP address with the host.

[therealkenc]

is also problematic because it brings down the whole ssh key exchange (and by extension git) edifice

Clarification because it was assumed obvious, and maybe wasn't. When I said "whole edifice" I am talking about sshd not ssh. For example, Github does not care whether a client address in WSL2 floats. On the other hand, if github.com's IP address changed all the time, and there was no way to DNS lookup github.com, well, that would be a problem.

[scarolan]

Same issue here. I was following this WSL2 + Kubernetes tutorial:
https://kubernetes.io/blog/2020/05/21/wsl-docker-kubernetes-on-the-windows-desktop/

the kubectl proxy command fails to forward traffic through to the Kubernetes dashboard. Running wsl --shutdown from a powershell terminal, then starting everything up again solves the issue.

[mmgeorge]

Having the same issue as @scarolan, things work if I shutdown wsl and then start it back up again.

[niczky12]

Same here, but with kubectl port-forward. Try restarting wsl with wsl --shutdown but it no longer fixes the issue. I can successfully curl the exposed port from wsl but opening a browser window in windows yields no response.

[Lucide]

Once updated to build 2004, my wsl remote development experience has been a nightmare. I've been experiencing the issue on 3/3 different machines. SSH connection to the vm, through localhost does not work reliably. Every morning I have to go through a painstakingly reboot cycle until the vm is reachable again. That can take between 1 to 4 reboots, a big waste of time.
Interestingly, the VSCode remote development server is not affected by this issue, no idea why.

• wsl --shutdown: doesn't do anything useful
• fast startup disabled
• "network reset": if useful, only lasts till the next reboot
• fiddling with hosts file: no good either, redirection is handled by internal server anyway
• restarting/reinstalling/resetting/full restarting ssh service: nothing

As I said, I had the chance to do in depth test on three different pc, all of them showed the same behavior. Sometimes more often, sometimes less. This was the only setup that made cross platform development feasible to setup.

There still are a lot of ongoing issues, but they have all been closed some time in the past: #4208 #5298 #4636 #4150

---

I'm aware Microsoft recommends WSL1 for cross development, due to filesystem performance issues. WSL1 is quite cool, tech wise, but it's not a vm, so there's no guarantee of everything behaving correctly. Like Unix domain sockets.

[95lux]

I got accessing localhost from Windows 2004 working through deinstalling Docker Desktop and its WSL2 integration. It worked for a few days.
Now it stopped working again. Also tried everything, from disabling fast startup to wsl --shutdown . It was such a happy world when it worked...

[niczky12]

I changed the insider programme updates to the beta channel and now it's all working again. Not sure what update is messing with this. I'm on: Version 10.0.19042 Build 19042 if that helps anyone.

[95lux]

The problem seems to be the 2004 update. After that, remote development was completely unreliable for me. Unfortunately i can't roll back to 19042, since the update was more than 10 days ago.
@niczky12 i just tried switching to the beta channel. It doesn't work for me though.

[niczky12]

That is good to know. I'll pause my updates and consider myself lucky. Let's hope this gets resolved quickly.

[95lux]

I found a solution, at least for the localhost accessability issue. To access localhost from a windows browser, you have to forward the wanted ports via a powershell script, as stated here:
#4150 (comment)

[yousafsyed]

Since I haven't been able to find a simple solution of kubectl port-foward, I tricked wsl2 with a docker container inside of my distro.

docker run --rm --name kubectl --user root -v ~/.kube/config:/.kube/config -p 8080:8080 bitnami/kubectl:latest / 
    port-forward --address 0.0.0.0 --namespace containerNameSpace containerName 8080:7111

To simplify even more this command can be wrapped into a simple bash script named /usr/bin/kubectl_wsl that can forward all the kubectl commands to the docker container.

Create the following bash script at /usr/bin/kubectl_wsl

#!/usr/bin/bash
kubectl version
docker run --rm --name kubectl --user root -v ~/.kube/config:/.kube/config -p 8080:8080 bitnami/kubectl:latest "$@"

now we can simply run the command as

kubectl_wsl port-forward --address 0.0.0.0 --namespace containerNameSpace containerName 8080:7111

I hope this can help someone.

[stephankoelle]

For us installing chrome on wsl2 was a viable solution (but for this you need a running xserver / xserver setup).
Accessing the the http server (running wsl2) via localhost from linux-chrome is blazing fast.

The second solution was:
remove a line in %UserProfile%.wslconfig

localhostForwarding=true

[newcanopies]

same issue

[maciejgwizdala]

On Windows 20H2 & Ubuntu 20.04 in WSL2, I just solved this issue with running kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000 and then to open it directly in Windows browser, I run command in second terminal wslview http://$(hostname -I):8888 - works really good without any other configuration.

[guidsdo]

This worked for me:

1. Run: kubectl proxy
2. Open your browser and go to: http://localhost:8001/api/v1/namespaces/NAMESPACE/services/https:SERVICE:PORT/proxy/

Example:
http://localhost:8001/api/v1/namespaces/argocd/services/https:argocd-server:80/proxy

More info:
https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-services/#manually-constructing-apiserver-proxy-urls