CentOS Question posted in
The official documentation can be found here.

Unable to connect to docker container port on one of the host interfaces from within the host – CentOS

I have a CentOS 7.8 machine with 2 interfaces. One is our management interface (eth0: 10.53.198.175) and other connects to our lab network (eth2: 10.209.81.73).

I run some container, in this case nginx using below command:

docker run --rm -d --publish 8888:8888 --name my_nginx nginx

Output of docker ps:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                            NAMES
133cdce7b7e1        nginx               "/docker-entrypoint.…"   About an hour ago   Up About an hour    80/tcp, 0.0.0.0:8888->8888/tcp   my_nginx

Since we are binding to 0.0.0.0, I am expecting it will listen on all interfaces.

Now to verify the reachability, from the host machine, if I use telnet to connect to port 8888, it works for these cases:

telnet localhost 8888 -> Works
telnet 0.0.0.0  8888 -> Works
telnet 10.209.81.73 8888 -> Works

But it doesn’t work if I give eth0 IP address:

telnet 10.53.198.175  8888 -> Doesn't work

From another host on the same network (10.53.198.x), telnet to 10.53.198.175 8888 works.

Firewalld service is disabled:

$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

And I don’t have any specific rules in iptables to block only for 10.53.198.175

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:menandmice-dns
ACCEPT     tcp  --  anywhere             172.18.0.3           tcp dpt:menandmice-dns
ACCEPT     tcp  --  anywhere             172.18.0.4           tcp dpt:menandmice-dns

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

$ cat /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Why would telnet 10.53.198.175 8888 not work from the host machine? Any idea what I should check next?

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    The root-cause of the problem was some IP rules that our lab team had added which took precedence over docker route. So the route basically said, anything to and from 10.53.198.175 send it out of eth0. This was created as part of separate route table and hence the entries were not visible with route -n command. After configuring a higher priority route for docker, the communication is working fine.


  2. 0

    Can you try with network host?

    docker run --rm -d --network host --name my_nginx nginx

    Default nginx port is 80. Is telnet working?

    telnet 10.53.198.175 80
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search