How do I allow "egress" requests from containers to the docker0 interface?
I have an issue related to the combined network on all of my Linode instances + Docker. I need to curl from inside container A to container B.
Both containers are behind a reverse proxy (traefik), all containers are in the same (docker-)network and seeing each other.
Both containers are basic nginx instances. nginx A has domain a.example.com, nginx B b.example.com, both responding as expected on port 443 (piped to the backend by traefik)
I
docker exec -it <container A> bash
and then try tocurl -v <b.example.com>
from inside the container which gives an timeout. Butcurl -v google.com
orcurl -v <hostname_container_b>
succeeds (still from inside container A).
IP of my Linode instance is 139.xxx.171.xx
My assumption here is that there is something blocking the traffic from the virtual interface of the container A, only when it reaches directly the interfaces of my hosts (either 139.xxx.171.xx, either docker0).
I think there is a firewall rule blocking "egress" requests from the container to the docker0 interface itself.
I never touched firewall rules of my instances. When poking in iptables, it seems to me that docker itself messes a lot with iptables.
I'm stuck and as I'm not an iptables/firewall expert I'm not sure how to go on from where I'm now.
Any help appreciated, thx!
1 Reply
You're right that Docker itself impacts iptables. In fact, Docker works directly with iptables and overrides other firewall overlays, such as UFW. You may need to make use of the -p flag to publish your containers and make them open to external traffic, depending on how your reverse proxy is configured. You might find Docker's iptables documentation to help as well. This resource has some suggestions regarding making changes to the compose.yml
file. That last link also suggests that containers can't inherently communicate despite being part of the same network, and the use of docker network create [OPTIONS] NETWORK
would be necessary to create a shared network.