Allow communication between two containers in the same bridged network

Here is my docker-compose.yml:

version: "2.4"
        image: portainer/portainer-ce:2.17.1-alpine
        container_name: byod-portainer
        restart: always
            - /var/run/docker.sock:/var/run/docker.sock
            - portainer_data:/data
            - "9999:9000"
            driver: none

        image: portainer/agent:2.17.1-alpine
            - /var/run/docker.sock:/var/run/docker.sock
            - /var/lib/docker/volumes:/var/lib/docker/volumes
            - "9001:9001"
        restart: always


So I have two containers in the same bridged network named myapp_default.
My portainer container must be allowed to contact portainer_agent on port 9001.
Here is the iptable rule automatically created by my docker compose:

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  !br-e46741861868 br-e46741861868             tcp dpt:9001

In my case when my portainer request request (my eth0 ip), packet is in input on br-e46741861868 and in output on the same interface, so this rule doesn’t match (in = ! br-e46741861868).

Should I:

  • Use the br- interface?

iptables -A INPUT -i br-e46741861868 -p tcp --dport 9001 -j ACCEPT

I’m not sure is a good idea creating iptables rules on a “virtual” interface, and it not really script friendly…

  • Use a larger rule?

iptables -A INPUT -p tcp --dport 9001 -j ACCEPT

But less secure…

What would be the good practice to allow communication between these containers?

Every compose project creates a user defined network. Every user defined network has built-in dns-based service discovery. Containers in the same network can communicate with any other container in the same network on any port (as long as a process is listening on that port). So the good and the bad part is: there is no port-filter or restriction of any kind. Just use the service name of the target container and the container port for the connection.

Much more easier with your solution, indeed! Thanks a lot!