Not able to connect to host from within docker container using host.docker.internal

[measterix]

Actual Behavior

I have Rancher Desktop version 1.8.1. I have created a docker container and from within the docker container, I tried to access an application (eg:Elasticsearch) which is running locally (not as a container) on the host machine using
curl http://host.docker.internal:9200
The prompt just hangs and doesnt give any response.
If there is mapping in hosts file as per below, then it gives "Connection refused"
127.0.0.1 localhost
127.0.0.1 host.docker.internal

Steps to Reproduce

On Rancher Desktop version 1.8.1, I start a docker container using docker compose.
From within the docker container, I tried to access Elasticsearch which is running locally on the host machine using
curl http://host.docker.internal:9200

Result

The prompt just hangs and doesnt give any response.

Expected Behavior

It should connect to the host application and print a response.

Additional Information

No response

Rancher Desktop Version

1.8.1

Rancher Desktop K8s Version

4.5.7

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 10

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

No response

[ericpromislow]

I couldn't repro this on a Windows 10/WSL2 box, with Enable networking tunnel both enabled and disabled.

This is with Rancher Desktop 1.9.1 -- we did some work on the Windows networking stack for the 1.9 series. Could you upgrade, and reopen this issue if it's still a problem?

[measterix]

I have upgraded to Rancher Desktop 1.9.0. I still get the same issue.

curl http://host.docker.internal:9200
curl: (7) Failed to connect to host.docker.internal port 9200: Connection refused

[IsaSih]

Would you mind to upgrade to 1.9.1 instead and try it one more time? The module handling https proxies inside Rancher Desktop was updated and it may fix your issue. Also, could you please attach the logs here?

[measterix]

I upgraded to Rancher Desktop 1.9.1. I am still getting the same error.

curl http://host.docker.internal:9200
curl: (7) Failed to connect to host.docker.internal port 9200: Connection refused
curl http://localhost:9200
curl: (7) Failed to connect to localhost port 9200: Connection refused

I have enabled the firewall as described in the Rancher Desktop documentation.
I tried adding and removing the mapping for host.docker.internal and localhost in the hosts file. But I still get the issue for both the cases.
Can you please suggest how to resolve this and get it working?

[measterix]

Would you mind to upgrade to 1.9.1 instead and try it one more time? The module handling https proxies inside Rancher Desktop was updated and it may fix your issue. Also, could you please attach the logs here?

Can you tell me the name of the log file that you want?

[gunamata]

@measterix , It could be because of the firewall configuration blocking communication between the container and the host machine. Can you please try the fix suggested in this FAQ item and see if it works?

[measterix]

Hi @gunamata,
I have tried enabling the firewall as given in the FAQ. That also didnt solve the issue.

[jewolz]

@gunamata Having the same issue on Windows. Is there any update on this?

Ping works flawless with the firewall rule. Curl to host.docker.internal works also as expected. But curl host.docker.internal:12070 where my application is running on doesn't work and just hangs.

[NaldoRay]

I'm also having this issue on Rancher Desktop 1.11.0.
I'm not using VPN, just Wi Fi connection.

With network tunneling off, host.docker.internal is mapped to vEthernet (WSL) adapter's IP address (e.g. 172.28.128.1), and the containers (including rancher-desktop) CAN'T connect to host.docker.internal or to vEthernet (WSL) adapter's IP address at all.
Weirdly enough, with network tunneling on, host.docker.internal is mapped to another IP address (e.g. 192.168.127.254, not from any of network adapters), and the containers (including rancher-desktop) CAN connect to host.docker.internal.

When i'm using VPN (cisco anyconnect), with network tunneling on or off, container CAN'T connect to host at all either by host.docker.internal or any of the ip addresses.

UPDATE:
After multiple restarts & shutdowns with RD's network tunneling on, containers now CAN also connect to host via host.docker.internal even when using VPN. And containers can also connect to host via vEthernet (WSL) adapter's IP address now only if network tunneling is on.
So the issue where "containers unable to connect to host either via host.docker.internal or direct ip address" is already resolved for us, by and only by turning on the network tunneling.
As long as it works! Thanks.

[peters-axon]

I am having the same issue with Rancher Desktop 1.9.0 and 1.11.1 under Windows 11.

Strangely enough, this configuration worked already a few weeks ago but I cannot say for sure, which Rancher Desktop version it was.

With 1.9.0 and 1.11.1 the containers cannot resolve the name host.docker.internal anymore, which I could fix by adding these lines to my docker-compose.yml

    extra_hosts:
      - "host.docker.internal:host-gateway"    

Nevertheless, now I get "connection refused" when I access a service running on my host machine. Please note, that docker services, which expose ports to the host, can be accessed via the host (in our case for example http://host.docker.internal:9080/ which is mapped to a container). It does not work for services which run natively on the host (and listen to 0.0.0.0 and are not blocked by the firewall).

Setting network tunneling did not help.

Is there anything else to check?

[Nino-K]

I ran the following test using 1.11.1 and everything seems to be functioning as expected. I ran an HTTP server on my local Windows machine that listens on 8880 with network tunnel on I hopped on the container and managed to curl my application that is running on the host:

> docker exec -it 35613d10f570 sh
# curl -vvv host.rancher-desktop.internal:8880
*   Trying 192.168.127.254:8880...
* Connected to host.rancher-desktop.internal (192.168.127.254) port 8880 (#0)
> GET / HTTP/1.1
> Host: host.rancher-desktop.internal:8880
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 06 Dec 2023 16:30:21 GMT
< Content-Length: 71
< Content-Type: text/plain; charset=utf-8
<
http upstream is called via method: host.rancher-desktop.internal:8880
* Connection #0 to host host.rancher-desktop.internal left intact
# curl -vvv host.docker.internal:8880
*   Trying 192.168.127.254:8880...
* Connected to host.docker.internal (192.168.127.254) port 8880 (#0)
> GET / HTTP/1.1
> Host: host.docker.internal:8880
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 06 Dec 2023 16:30:35 GMT
< Content-Length: 62
< Content-Type: text/plain; charset=utf-8
<
http upstream is called via method: host.docker.internal:8880
* Connection #0 to host host.docker.internal left intact

If you encounter a connection refused I would suggest to ran the firewall rule mentioned here however, make sure that the name of the WSL adapter/interface matches the rule e.g:

Mine is called vEthernet (WSL)

> ipconfig
Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::9679:f715:cb71:908d%20
   IPv4 Address. . . . . . . . . . . : 172.27.176.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

should match

New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Since it is possible that on the newer WSL the interface name might be different.

[peters-axon]

Hi @Nino-K,

thanks for the hint, but I did the firewall configuration as mentioned in the FAQ (for vEthernet (WSL (Hyper-V firewall))) before I wrote here.

As I said, my setup used to work a few weeks ago, something must have changed in the last days.

I did a few more tests and found out, that a connection from a container to host.docker.internal is now going to the WSL host instead of the Windows host.

So I think I have two topics:

1. why is host.docker.internal suddenly no longer DNS resolvable and needs the extra_host setting (and is it correct)?
2. why is it not connecting to Windows but to my WSL host?

[Nino-K]

@peters-axon can you turn off the new Hyper-V firewall to see if that helps at all? Your issue might be related to this.

[peters-axon]

@Nino-K thank you for your support! I wanted to test your suggestion with a fresh container but found out, that accessing the windows host in this container is working as it should without turning the setting off. I then removed the extra_host settings from my other containers and rebuilt them from scratch and now it is working there too.

What I have seen before I rebuilt the containers, was that pinging host.docker.internal in the old containers went to 172.17.0.1, while in the rebuilt containers it goes to 192.168.127.254. (BTW my Windows interface is in the 192.168.0.* network, my WSL ethernet is currently on 172.29.16.1 and my WSL network tunneling is enabled).

[Nino-K]

What I have seen before I rebuilt the containers, was that pinging host.docker.internal in the old containers went to 172.17.0.1, while in the rebuilt containers it goes to 192.168.127.254. (BTW my Windows interface is in the 192.168.0.* network, my WSL ethernet is currently on 172.29.16.1 and my WSL network tunneling is enabled).

That seems to be the correct behavior, the 192.168.127.254 is the IP address that is assigned as static DNS hosts to both host.rancher-desktop.internal. and host.docker.internal.. The IP address itself is part of the virtual network's subnet. You should always have the network tunnel enabled as it will not be considered experimental in our next release and also rectifies some of the issues we were previously seeing with our old network.

[atiqkhaled]

I can not access host machine from docker container using host.docker.internal. I am using docker version 4.29.0 and host machine is mac Ventura 13.5.1.

[Nino-K]

I can not access host machine from docker container using host.docker.internal. I am using docker version 4.29.0 and host machine is mac Ventura 13.5.1.

@atiqkhaled this is a windows specific issue, if you are still encountering this, please feel free to create a separate issue. I'm going to close this issue.

[grahambunce]

@Nino-K I know you've closed this as a windows issue, but I'm getting the same behaviour on MacOS.

Rancher Desktop - 1.14.1
MacOS = Sonoma 14.5

Run this docker command:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

This talks to ollama running locally on my Mac, which is on port 11434

Error in logs:

ERROR:apps.ollama.main:Connection error: Cannot connect to host host.docker.internal:11434 ssl:default [Connection refused]

Run this instead (where 192.168.1.92 is the IP address of my local PC)

docker run -d -p 3000:8080 --add-host=192.168.1.92:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Then it works fine.

Should this be re-opened as "not fixed" ?

[gauravmanerkar]

This is definitely not windows issue. @Nino-K

[hexlify]

@Nino-K why this firewall rule not created by default during Rancher Desktop installation?

[alex-levashev]

@Nino-K I know you've closed this as a windows issue, but I'm getting the same behaviour on MacOS.

Rancher Desktop - 1.14.1 MacOS = Sonoma 14.5

Run this docker command:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

This talks to ollama running locally on my Mac, which is on port 11434

Error in logs:

ERROR:apps.ollama.main:Connection error: Cannot connect to host host.docker.internal:11434 ssl:default [Connection refused]

Run this instead (where 192.168.1.92 is the IP address of my local PC)

docker run -d -p 3000:8080 --add-host=192.168.1.92:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Then it works fine.

Should this be re-opened as "not fixed" ?

@Nino-K I've the same issue, stopped using Rancher Desktop and got back to Docker Desktop due to that issue, could it be reopened?

[jochenhebbrecht]

I have created a new issue as I ran into the same problem on OS X. See: #7611