integration/network/bridge/nftablesdoc/templates/new-daemon.md
When the daemon starts, it creates two tables, ip docker-bridges and
ip6 docker-bridges for IPv4 and IPv6 rules respectively. Each table contains
some base chains and empty verdict maps. Rules for the default bridge network
are then added.
{{index . "Ruleset4"}}
Chain filter-FORWARD is a base chain, with type filter and hook forward.
So, it's equivalent to the iptables built-in chain FORWARD in the filter
table. It's initialised with two rules that use the output and input
interface names as keys in verdict maps:
{{index . "chain filter-FORWARD"}}
The verdict maps will be populated with an element per bridge network, each jumping to a chain containing rules for that bridge. (So, for packets that aren't going to-or-from a Docker bridge device, no jump rules are found in the verdict map, and the packets don't need any further processing by this base chain.)
The filter-FORWARD chain's policy shown above is accept. However:
drop if the sysctl
net.ipv4.ip_forward was not set to '1', and the daemon set it itself when
an IPv4-enabled bridge network was created.Chains added for the default bridge network are named after the base chain hook they're called from, and the network's bridge.
Packets processed by filter-forward-in__* will be delivered to the bridge
network if accepted. For docker0, the chain is:
{{index . "chain filter-forward-in__docker0"}}
The rules are:
Packets processed by filter-forward-out__* originate from the bridge network:
{{index . "chain filter-forward-out__docker0"}}
The rules in docker0's chain are:
Like the filter-FORWARD chain, nat-POSTROUTING has a jump to per-network chains for packets to and from the network.
{{index . "chain nat-POSTROUTING"}}
In docker0's nat-postrouting chains, there's a single masquerade rule for packets leaving the network:
{{index . "chain nat-postrouting-in__docker0"}} {{index . "chain nat-postrouting-out__docker0"}}