I'm running an application in a Docker container that is accessed from the Internet over HTTPS on port 443 by both human users and machines through a REST API. The application also needs outbound access to the Internet and to all required hosts and ports on an internal network.
The Docker host is Red Hat Linux with SELinux and firewalld enabled. Under the default bridge network, the application could reach most destinations, but FTP, SFTP, and SSH connections failed when the target host was on the same subnet as the Docker host. I was told this might be related to traffic not being forwarded correctly between the physical interface and Docker's bridge interface.
I then changed the container to host networking and removed the port mappings, since port publishing is not available in host mode. Afterward, the application could reach machines on the local subnet, but other internal hosts and the Internet became unavailable, apparently because DNS resolution or routing was no longer working.
I reverted to bridge mode because Internet access and DNS are more important than reaching a few hosts on the local subnet. What networking setup and firewall or routing details should I check? Is host networking actually necessary, or can bridge mode be configured correctly for this situation?
3 Answers
Bridge mode is generally the safer default. Check that the Docker host is forwarding traffic, that firewalld allows forwarding between the Docker bridge and the physical interface, and that the internal hosts have a route back to the container subnet. Also verify the container’s DNS configuration and the host’s DNS settings. Switching to host mode can change which interfaces, routes, and firewall policies are involved, so it may fix one path while breaking DNS or Internet access.
A dedicated Docker network can be useful if several related containers need to communicate, but it won’t by itself solve routing to the intranet. For this case, first identify the container subnet and inspect the route taken to a failing host. Then confirm that the Docker host and the destination network know how to return traffic to that subnet, or configure appropriate masquerading on the host if that is the intended design.
Host networking usually isn’t necessary here. Keep the container on bridge networking and publish only the ports the application needs, for example with Docker’s port mappings. This preserves isolation while still allowing inbound HTTPS traffic and normal outbound connections. The connections to hosts on the same subnet are more likely related to routing, forwarding, firewall rules, or return routes than to bridge mode itself.
If a reverse proxy or another container needs to reach the application by name, putting the related containers on the same user-defined network is often easier than using host mode. Host mode should be reserved for cases that genuinely require access to the host’s network stack.