WSL2 with hostAddressLoopback - docker-ce bridge network unreachable from Windows #48136
Description
Description
Reported by @dannyhpy in #48075 (comment) ...
This PR fixes the issue listed in microsoft/WSL#10494 for the loopback interface only, sadly. Running docker run -ti --rm -p 192.168.1.100:8080:80 traefik/whoami and opening http://192.168.1.100:8080/ in the browser on the host machine still fails with a ERR_CONNECTION_TIMED_OUT. On other hosts in the LAN, though, this works.
The hostAddressLoopback option is set to true in my %USERPROFILE%.wslconfig file as noted in https://learn.microsoft.com/en-us/windows/wsl/wsl-config and running another program such as python -m http.server works and is reachable from the Windows host at http://192.168.1.100:8000/
I took a look, and could repro ...
Packets arrive on the WSL2 guest's ethN interface, with the shared host address as the source. So, everything looks normal. They're DNAT'd, arrive at the container, and get a response addressed to the shared host address (192.168.1.100 in the example). But, the response packets don't get back to the WSL2 ethN interface.
That's because the dest MAC address in response packets belongs to the docker network's bridge (the container's default gateway). The WSL2 guest has that IP address itself, on its own ethN, it doesn't know anything about the Windows version of that address. So, packets are delivered locally rather than sent back to ethN - then dropped because nothing in the Linux guest is listening on that dest port.
I don't have an idea for a workaround right now. Maybe somehow forcing use of docker-proxy for these connections would help, but it sounds messy. It'd be good to get some input from Microsoft on how they think this sort of thing could work.
(Perhaps this sort of problem is why the hostAddressLoopback option is still experimental. Possibly unrelated, but it seemed a bit unstable while I was testing it, a few times after a tcpdump the guest Linux became unresponsive until I restarted WSL.)
Reproduce
- In
.wslconfig...
[experimental]
hostAddressLoopback=true
- Install docker-ce in the WSL2 instance.
- As described in the example above:
- Create a bridge network, and a container with ports mapped from the host address (which is shared with Windows).
- In Windows, try to connect to that service via the host address.
Expected behavior
The Linux service is accessible from Windows.
docker version
Client: Docker Engine - Community
Version: 27.0.3
API version: 1.46
Go version: go1.21.11
Git commit: 7d4bcd8
Built: Sat Jun 29 00:02:23 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 27.0.3
API version: 1.46 (minimum version 1.24)
Go version: go1.21.11
Git commit: 662f78c
Built: Sat Jun 29 00:02:23 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.18
GitCommit: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
runc:
Version: 1.7.18
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client: Docker Engine - Community
Version: 27.0.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.15.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.28.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 2
Server Version: 27.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
runc version: v1.1.13-0-g58aa920
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.15.133.1-microsoft-standard-WSL2
Operating System: Ubuntu 24.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 15.46GiB
Name: Dkr-RM-Win
ID: 9cbf9b0b-1612-4e58-b38a-95a8f3e65cbe
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: falseAdditional Info
No response