-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to access macOS host from container via host.containers.internal #11642
Comments
Hello, Good catch! I added a fix for that and it should land in the next gvproxy release. Thanks |
@guillaumerose I think we have to patch podman as well, podman will add this entry to /etc/hosts so the container will use this instead of the dns server. |
@Luap99 /etc/hosts can work but I suspect we will need to make the subnet of gvproxy configurable. 192.168.127.0/24 is a good random subnet but at some point we will get an issue for that. |
@guillaumerose I think you misunderstand me, right now we use /etc/hosts for this name. I want to patch podman to not add this entry to /etc/hosts when we run inside podman machine so that the container will use the respone from the gvproxy dns server. |
Oh ok I undertand now. Sorry, thanks! |
Let the gvproxy dns server handle the host.containers.internal entry. Support for this is already added to gvproxy. [1] To make sure the container uses the dns response from gvproxy we should not add host.containers.internal to /etc/hosts in this case. [NO TESTS NEEDED] podman machine has no tests :/ Fixes containers#11642 [1] containers/gvisor-tap-vsock@1108ea4 Signed-off-by: Paul Holzinger <[email protected]>
Let the gvproxy dns server handle the host.containers.internal entry. Support for this is already added to gvproxy. [1] To make sure the container uses the dns response from gvproxy we should not add host.containers.internal to /etc/hosts in this case. [NO NEW TESTS NEEDED] podman machine has no tests Fixes containers#11642 [1] containers/gvisor-tap-vsock@1108ea4 Signed-off-by: Paul Holzinger <[email protected]>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I'm trying to access a service listening on a TCP port on my macOS host from a container by using host.containers.internal but it does not seem to work. The same steps using host.docker.internal work with Docker.
Steps to reproduce the issue:
Listen for socket connections on the macOS host (
nc -lk 4444
)Verify Docker is able to connect from a container (
docker run --rm docker.io/subfuzion/netcat -zv host.docker.internal 4444
)Start a Podman machine (
podman machine init
andpodman machine start
)See the Podman fails to connect to the port (
podman run --rm docker.io/subfuzion/netcat -zv host.containers.internal 4444
)Describe the results you received:
Docker prints that a connection succeeded and Podman prints that the network is unreachable.
Describe the results you expected:
That the container running with Podman would be able to successfully establish a connection to the host.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):gathered from
rpm -q podman
afterpodman machine ssh
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
physical macOS host
The text was updated successfully, but these errors were encountered: