Binding docker container to 0.0.0.0 doesn't bind to IPv4

[cxn-pkovacs]

Version

Microsoft Windows [Version 10.0.22000.1641]

WSL Version

• WSL 2
• WSL 1

Kernel Version

PS > wsl --version
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1641

Distro Version

Release: 22.04

Other Software

docker

Repro Steps

docker run --name nginx -p 0.0.0.0:9999:80 --rm nginx

Expected Behavior

The container binds to all available IPv4 (and maybe IPv6) network interface addresses:

0.0.0.0:9999

Actual Behavior

The container binds only to all available IPv6 network interface addresses:

:::9999

Diagnostic Logs

No response

[cxn-pkovacs]

The issue started to appear about a week ago (after a Windows update?)

A probably related issue (which started to appear at the same time) is that node express apps to bind to localhost now bind to :: (only) instead of (also?) 127.0.0.1. (Specifying 127.0.0.1 to bind to correctly will result in binding to 127.0.0.1.)

[cxn-pkovacs]

Upgrading to the most recent WSL version

PS > wsl --version
WSL version: 1.1.3.0
Kernel version: 5.15.90.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1641

does not solve the problem.

[cxn-pkovacs]

Installing docker-engine instead of Docker Desktop seems to fix the issue.

[elsaco]

@cxn-pkovacs docker-desktop is still using docker-engine. After the container is up do a docker container inspect and check the NetworkSettings. This is how the ports look on a test container started with docker run -d --name webserver -p 80:80 -p 443:443 8a35eb5b6899:

            "Ports": {
                "443/tcp": [
                    {
                        "HostIp": "0.0.0.0",
                        "HostPort": "443"
                    },
                    {
                        "HostIp": "::",
                        "HostPort": "443"
                    }
                ],
                "80/tcp": [
                    {
                        "HostIp": "0.0.0.0",
                        "HostPort": "80"
                    },
                    {
                        "HostIp": "::",
                        "HostPort": "80"
                    }

and the container is accessible via http://127.0.0.1:80 from Windows side.

[cxn-pkovacs]

@elsaco , thank you for this additional information!

Indeed, I forgot to mention that my main use case is for apps and services started in WSL to consume services started in WSL. The issue is about "what happens" on the WSL side.

In fact, the practical problem I am experiencing is a combination of this issue and another, much older: #4851. I am not a networking expert, but I suspect that :: bindings should be reachable at IPv4 adresses as well.

[ghost]

ipv6 and ipv4 bindings are separate. (Except maybe for RFC 4291)

[cxn-pkovacs]

@pmartincic , what do you mean in the context of this issue by this:

ipv6 and ipv4 bindings are separate.

Is this issue closed, because the behavior ("ipv4 bindings don't work with Docker Desktop in WSL2") cannot be reproduced. Or else, is it closed, because ipv4 bindings not working with Docker Desktop in WSL2 is the expected behavior?

[ghost]

Perhaps I closed this prematurely, if that's the case my apologies. I've seen a lot of issues created because people don't understand the ipv6 and ipv4 bindings to be separate unless you're using a dual stack socket. I closed this because of your comment regarding ipv6 bindings being reachable from ipv4 addresses and the bug you linked to.

Are you using IPV6_V6ONLY set to 0 and binding to ::? This part would be my fault because I didn't realize that dual-mode sockets are on by default.

If you're bound to :: on the guest, are you able to connect to both :::PORT and 127.0.0.1:PORT from the guest?

Please give me the output from ss -lntp on the guest.

[ghost]

Right now we don't support forwarding for dual-mode sockets, though I'll look into what would be needed for that.

[cxn-pkovacs]

Thank you for taking some more time investigating this issue.

Are you using IPV6_V6ONLY set to 0 and binding to ::?

The simplest case I can provide is (as in the issue description) running this command on the guest:

docker run --name nginx -p 0.0.0.0:9999:80 --rm nginx

As I understand IPV6_V6ONLY is an option for the linux socket systemcall. I am not setting myself, but docker may set it. Unfortunately, I am not aware of the ways the environment (WSL2?) makes available to programs the information whether this flag has to be set or not.

If you're bound to :: on the guest, are you able to connect to both :::PORT and 127.0.0.1:PORT from the guest?

Running the following command on the guest

docker run -d --rm --name nginx -p [::]:9999:80 --rm nginx

gives

$ ss -lntp
State                    Recv-Q                   Send-Q                                      Local Address:Port                                      Peer Address:Port                  Process
LISTEN                   0                        4096                                       172.25.133.229:15432                                          0.0.0.0:*
LISTEN                   0                        511                                             127.0.0.1:9229                                           0.0.0.0:*                      users:(("node",pid=15936,fd=44))
LISTEN                   0                        4096                                              0.0.0.0:42093                                          0.0.0.0:*                      users:(("java",pid=1641,fd=82))
LISTEN                   0                        511                                             127.0.0.1:45267                                          0.0.0.0:*                      users:(("node",pid=480,fd=18))
LISTEN                   0                        4096                                              0.0.0.0:10389                                          0.0.0.0:*
LISTEN                   0                        511                                             127.0.0.1:8869                                           0.0.0.0:*                      users:(("node",pid=15626,fd=43))
LISTEN                   0                        511                                             127.0.0.1:8870                                           0.0.0.0:*                      users:(("node",pid=15645,fd=41))
LISTEN                   0                        128                                               0.0.0.0:8070                                           0.0.0.0:*                      users:(("ssh",pid=6242,fd=4))
LISTEN                   0                        4096                                                 [::]:9999                                              [::]:*
LISTEN                   0                        4096                                                 [::]:10389                                             [::]:*
LISTEN                   0                        511                                                     *:8888                                                 *:*                      users:(("node",pid=15936,fd=47))

and yes I can reach [::] from the guest

$ curl http://[::]:9999
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

, but I cannot reach 127.0.0.1:

$ curl http://127.0.0.1:9999
curl: (7) Failed to connect to 127.0.0.1 port 9999 after 0 ms: Connection refused

(which is expected if I correctly understand your comment about the separation of v4 and v6 adresses).

[ghost]

Thanks @cxn-pkovacs, all that looks expected. If you see the last bind to *:8888. I'm pretty sure that means it's a dual mode bind on both ipv4 and ipv6. However, [::]:9999 will be on ipv6 only.

Your original bug specified having issues with docker run --name nginx -p 0.0.0.0:9999:80 --rm nginx. What's the output of ss -lntp from that.

[elsaco]

When you start the container with -p 0.0.0.0:9999:80 mapping it will be accessible only over IPv4 and port 9999. Sample output of docker ps, notice port mapping:

[tux@eleven ~]$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                  NAMES
cfb993b16800   nginx     "/docker-entrypoint.…"   33 minutes ago   Up 33 minutes   0.0.0.0:9999->80/tcp   nginx1

And this is output of trying to reach the container:

From WSL instance, running the docker engine:

[tux@eleven ~]$ curl -I http://127.0.0.1:9999
HTTP/1.1 200 OK
Server: nginx/1.23.3
Date: Fri, 03 Mar 2023 22:47:50 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 13 Dec 2022 15:53:53 GMT
Connection: keep-alive
ETag: "6398a011-267"
Accept-Ranges: bytes

[tux@eleven ~]$ curl -I http://[::]:9999
curl: (7) Failed to connect to :: port 9999 after 0 ms: Couldn't connect to server

From Windows host:

PS C:\Users\valli> curl -I http://127.0.0.1:9999
HTTP/1.1 200 OK
Server: nginx/1.23.3
Date: Fri, 03 Mar 2023 22:48:46 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 13 Dec 2022 15:53:53 GMT
Connection: keep-alive
ETag: "6398a011-267"
Accept-Ranges: bytes

PS C:\Users\valli> curl -I http://[::]:9999
curl: (7) Failed to connect to :: port 9999 after 0 ms: Address not available

This works as intended. WSL 1.0.3 and Windows 10.0.22621.1344 was used for testing.

Output of ss on WSL instance:

[tux@eleven ~]$ ss -ntl
State        Recv-Q        Send-Q               Local Address:Port                Peer Address:Port       Process
LISTEN       0             4096                     127.0.0.1:45697                    0.0.0.0:*
LISTEN       0             4096                       0.0.0.0:9999                     0.0.0.0:*

There's no IPv6 listening port open, and it shouldn't be, based on the nginx container port mapping.

[ghost]

Thanks @elsaco, on that note I'll close this out because that all looks expected and normal to me.

[cxn-pkovacs]

What's the output of ss -lntp from that.

Since this issue has been closed for the second time (this time without even waiting 10 hours for the input I was requested to provide) I decided not to reinstall Docker Desktop to provide the extra input and to desist from pursuing this issue. Thank you for the work done!