I am running a service on my docker host that I am trying to access from a docker container. The service is accessible from the host, but I cannot access the service from inside my Docker container. I have tried using both the host private IP address (10.0.0.60) and the IP address of the docker0 bridge interface (172.17.0.1), and neither work. I have tried binding the service on the host to both 0.0.0.0 and 172.17.0.1, and neither makes the service visible to the container.
Running curl localhost:9090 on the host works correctly, but running curl 172.17.0.1:9090 inside the docker container returns curl: (7) Failed to connect to 172.17.0.1 port 9090 after 1 ms: Couldn't connect to server. Same happens when I try to use 10.0.0.60.
Running netstat -tulpn on the host gives tcp6 0 0 :::9090 :::* LISTEN 210664/java, and running the same command in the docker container does not show any service running on port 9090.
The only thing I can suspect would be causing this would be a firewall, however I have tried adding several rules to UFW and even disabling the firewall outright, and nothing seems to allow the docker container to access the service on the host. My docker-compose file is as follows:
Based on the output you shared, itās safe to say that this should have worked:
The ip of the docker0 interface should be accessible from any container. I assume your java process does listen on ipv4 and ipv6 and therefor should also bind to the ip of docker0.
Your os uses a non default kernel. Is your Linux running in some sort of os container technology like lxc container?
Update:
What is the result, if you execute the command on the host itself? curl 172.17.0.1:9090
Iām unsure of the exact technology used for containerization, but my host machine is a VPS running on Oracleās OCI plaftorm. Fastfetch labels my host as KVM Virtual Machine (virt-4.2), so itās definitely running under some sort of virtualization technology.
Running curl 172.17.0.1:9090 on the host returns nothing, however looking at the logs of the application I can see a valid HTTP GET request reaching the server. The exact response from the server logs are:
2025.01.09 14:11:40:0000 [io-comp...] [INFO ] org.http4s.server.middleware.Logger - HTTP/1.1 GET /
2025.01.09 14:11:40:0001 [io-comp...] [INFO ] org.http4s.server.middleware.Logger - HTTP/1.1 303 See Other
It canāt be just a kvm vm, as there must be a reason why your os doesnāt use a default ubuntu kernel. Though, that should be irrelevant (at least I donāt see why it should be).
Your server already returns ā303 See Otherā. So we know it binds to the ipv4 address. Though, It is still an unusual redirect http code. Usually people use 301 or 302. You can make curl follow the redirect: curl -L 172.17.0.1:9090.
Note: If you canāt get it to work on the host itself, it wonāt be able to work from a container either.
Update:
To make sure that your application isnāt the problem, you can do following test.
Run a ad-hoc webserver on the host:
python3 -m http.server 8080
Note change the port from 8080 to another free port, if port 8080 is already used on your host.
Then open a second terminal and test whether its possible to reach the web server from a container:
docker run --rm alpine wget -O - http://172.17.0.1:8080
Following the redirect using curl -L returns the HTML for the expected page. I am also able to access the application using my Tailscale VPN and accessing port 9090 from the browser. Accessing the application from the browser or using curl -L also ends with the application returning a HTTP 200 OK response.
Running the python webserver on the host and attempting to connect through the alpine container also results in the container not being able to access the host. Result of docker run --rm alpine wget -O - http://172.17.0.1:8080:
Connecting to 172.17.0.1:8080 (172.17.0.1:8080)
wget: can't connect to remote host (172.17.0.1): Host is unreachable
However, running wget -O - http://172.17.0.1:8080 on the host returns a successful response:
--2025-01-09 14:40:41-- http://172.17.0.1:8080/
Connecting to 172.17.0.1:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 187 [text/html]
Saving to: āSTDOUTā
- 0%[ ] 0 --.-KB/s <!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Directory listing for /</title>
</head>
<body>
<h1>Directory listing for /</h1>
<hr>
<ul>
</ul>
<hr>
</body>
</html>
- 100%[==========================================================================================>] 187 --.-KB/s in 0s
2025-01-09 14:40:41 (47.9 MB/s) - written to stdout [187/187]
You get really strange results. I concur with you conclusion that some sort of firewall must prevent it. I never run docker on a system which establishes a vpn connection, but I can imagine that it messes around with routes, the default gateway of the host and might even tinker with firewall rules.
Nothing I can realy help with. I hope you do find a solution!
Thank you so much for your support! Iām wondering if my issue is somehow caused by the hosting configuration, as Iām running an almost identical setup on a physical Debian server and that system has no issues accessing the host from inside containers. Iāll try asking on the Oracle forums to see if thereās any advice they can offer there.
Found a solution! To anyone in the future who stumbles on this post looking for answers, it seems that the default Ubuntu image for Oracle Cloud has strange firewall rules by default, running the command iptables -I INPUT -j ACCEPT as specified in this Reddit post solved my problem!