A container’s network isolation comes from a Linux kernel feature called a network namespace — each container gets its own private set of network interfaces, routing tables, and firewall rules, completely separate from the host’s own networking stack and from every other container’s. This is powerful for isolation, but it creates an immediate practical problem: if a container’s network world is truly private and separate, how does a web browser outside the machine ever reach a web server running inside one of these isolated containers?

Docker solves this by creating a virtual Ethernet bridge on the host — by default, an interface named docker0 — and connecting every container’s private network namespace to it using a virtual cable pair called a veth pair. This gets containers talking to each other and to the bridge, but a bridge alone still does not let outside traffic in, or let container traffic reach the internet while pretending to come from the host’s own address. That translation and permission-granting work is where iptables, the standard Linux tool for configuring the kernel’s netfilter packet-filtering framework, becomes essential — and it’s why installing Docker on a Linux machine visibly adds a long list of new, auto-generated iptables rules the moment the Docker daemon starts.

graph TB
    A["Internet / Client"] -->|"Request to host:8080"| B["Host Network Interface (eth0)"]
    B --> C["iptables DOCKER chain\n(DNAT rule: 8080 -> container:80)"]
    C --> D["docker0 Bridge"]
    D -->|"veth pair"| E["Container Network Namespace\n(port 80)"]
    E -->|"Outbound response"| D
    D --> F["iptables POSTROUTING chain\n(MASQUERADE rule)"]
    F --> B
    G["Admin custom firewall rules"] --> H["DOCKER-USER chain\n(evaluated first, safe to edit)"]
    H --> C
    

Docker’s Custom iptables Chains

Rather than dumping all of its rules into the handful of built-in netfilter chains, Docker creates and manages its own dedicated chains — most notably DOCKER, DOCKER-ISOLATION-STAGE-1, DOCKER-ISOLATION-STAGE-2, and DOCKER-USER — and wires them into the standard chains with jump rules. This keeps Docker’s auto-generated, frequently regenerated rules cleanly separated from any rules an administrator might add by hand.

The DOCKER Chain

This chain holds the DNAT rules responsible for port publishing — every -p hostPort:containerPort a user specifies when starting a container results in a corresponding rule here, rewriting the destination of matching inbound packets to the container’s actual internal address and port.

The DOCKER-ISOLATION Chains

These chains enforce separation between different Docker networks, ensuring that, by default, containers attached to one user-defined network cannot freely reach containers on a completely separate network unless something has explicitly connected the two.

The DOCKER-USER Chain

This chain exists specifically so administrators have a stable, safe place to insert their own custom firewall logic — rules placed here are evaluated before Docker’s own generated rules and, critically, are not overwritten or wiped out when Docker regenerates its other chains, which happens routinely as containers start and stop.

Consider running a container with -p 8080:80, exposing a web server so it’s reachable at the host’s port 8080. The moment this container starts, Docker’s daemon does not just start the process — it also inserts a new DNAT rule into the DOCKER chain, roughly saying: “any TCP packet arriving on this host’s port 8080 should have its destination rewritten to this specific container’s internal IP address, on port 80.”

When an external client’s packet arrives at the host addressed to port 8080, the kernel’s netfilter framework evaluates it against the PREROUTING chain, where Docker’s DOCKER chain is invoked. The matching DNAT rule rewrites the packet’s destination to the container’s private bridge-network IP address and port 80, and normal Linux routing then delivers it across the docker0 bridge and into the container’s network namespace through its veth pair — the container’s own application never sees anything unusual, it simply receives a connection on port 80 as if that connection arrived directly.

Outbound traffic follows the reverse logic through the POSTROUTING chain: as a container’s packet leaves the host on its way to the internet, a MASQUERADE rule rewrites its source address from the container’s private bridge IP to the host’s own external-facing address, and the kernel’s connection-tracking system remembers this translation so the eventual response can be correctly reversed and delivered back to the originating container.

By default, Docker’s automatic iptables management is permissive in one specific, often-surprising way: a published container port can bypass a host-level firewall rule that a system administrator configured separately, because Docker inserts its own DNAT and forwarding rules early enough in the chain evaluation order to take effect regardless. This has caused real, documented incidents where administrators believed a host firewall was blocking a port, while Docker’s own rules quietly allowed traffic straight through to a container anyway.

The isolation chains between separate Docker networks provide a meaningful default security boundary — containers on an isolated, user-defined network cannot reach containers on an entirely different network unless something explicitly bridges them — but this isolation applies between Docker networks specifically, and does not substitute for application-level authentication or a properly configured DOCKER-USER policy for traffic entering from outside the host entirely.

Because Docker’s networking rules live inside the standard Linux netfilter framework, standard Linux tools for inspecting that framework work equally well against container traffic: listing the current rule set reveals every DNAT and MASQUERADE rule Docker has generated, and the kernel’s connection-tracking table shows every currently active translated connection, container-related or not, in one unified view.

Standard Linux network interface statistics on the bridge and veth interfaces give visibility into overall container network throughput, while per-rule iptables packet and byte counters can reveal exactly how much traffic a specific published port or isolation rule is actually handling — useful both for capacity planning and for confirming a security rule is genuinely being hit as expected.

Pattern: Custom Firewall Logic Always in DOCKER-USER

Placing any administrator-defined rules affecting container traffic specifically into the DOCKER-USER chain guarantees they survive Docker’s routine chain regeneration and are evaluated before Docker’s own default-permissive rules.

Pattern: User-Defined Networks for Deliberate Segmentation

Grouping related containers onto their own explicitly created network, rather than relying on the single default bridge, uses Docker’s built-in isolation chains to enforce a real, kernel-level segmentation boundary between unrelated groups of containers.

Anti-pattern: Manually Editing the DOCKER Chain Directly

Modifying Docker’s own auto-managed chains by hand is fragile, since Docker regularly regenerates them as containers start and stop, silently discarding manual changes and creating confusing, hard-to-reproduce behavior.

Anti-pattern: Assuming a Host Firewall Covers Container Ports

Relying solely on a general host-level firewall tool, configured without awareness of Docker’s own chain insertion behavior, frequently leaves published container ports unintentionally exposed regardless of the intended host firewall policy.