integration/network/bridge/iptablesdoc/templates/new-daemon.md
When the daemon starts, it creates custom chains, and rules for the default bridge network.
Table filter:
{{index . "LFilter4"}}
{{index . "SFilter4"}}
The FORWARD chain's policy shown above is ACCEPT. However:
The FORWARD chain rules, explained in the order they appear in the output above, are:
Once the daemon has initialised, it doesn't touch these rules. Users are free to append rules to the FORWARD chain, and they'll run after DOCKER's rules (or to the DOCKER-USER chain, for rules that run before DOCKER's).
The DOCKER-FORWARD chain contains the first stage of Docker's filter rules. Initial rules are inserted at the top of the table, then not touched. Per-network rules are appended. The DOCKER-FORWARD chain rules, explained in the order they appear in the output above, are:
setupIPChains.setupIPChains.setupIPChains.The DOCKER-CT chain is an early ACCEPT for any RELATED,ESTABLISHED traffic to a docker bridge. It contains a conntrack ACCEPT rule for each bridge network.
DOCKER-BRIDGE has a rule for each bridge network, to jump to the DOCKER chain.
The DOCKER chain implements per-port/protocol filtering for each container.
The DOCKER chain has a single DROP rule for the bridge network, to drop any packets routed to the network that have not originated in the network. Added by setDefaultForwardRule. This means there is no dependency on the filter-FORWARD chain's default policy. Even if it is ACCEPT, packets will be dropped unless container ports/protocols are published.
The DOCKER-INTERNAL chain is for --internal networks (bridge networks that
have no external access), it's unused in this example.
Table nat:
{{index . "LNat4"}}
{{index . "SNat4"}}