Description

Docker needs to enable IP Forwarding for its bridge networks - that potentially turns an unsuspecting host into a router, which is particularly important when it has multiple interfaces. So, when Docker enables IP forwarding, it also sets the iptables/nftables "filter forward" policy to "drop" - Docker's container-related traffic is explicitly allowed, and everything else (packets between host interfaces etc) will be dropped.

But, if IP forwarding is enabled when Docker starts, it may mean other services running on the host need it enabled, and the drop policy is likely to break them. So, it doesn't set the "drop" policy.

Before #48594, Docker always set the policy to "drop" for IPv6. But, when we enabled ip6tables by default, that broke things for people. So, we currently do the same thing for IPv6 as we've done forever for IPv4 - only set the policy to "drop" if the daemon enabled forwarding.

As "forwarding already enabled" is a poor way to guess at whether the policy should be "drop", #48594 also added daemon config option --ip-forward-no-drop to tell it not to set the policy.

The issue for nftables is with daemon restarts ...

With iptables, a daemon restart re-creates all of Docker's rules. But, because iptables only has one set of tables/chains, that doesn't reset the filter-FORWARD policy. So, unless the user does-something, if Docker set the policy to drop it stays that way.

But, with nftables, the filter-FORWARD policy belongs to a chain in Docker's own table - which gets a complete reset on daemon restart. When the table is reconstructed, its filter-FORWARD policy becomes "accept". It then stays that way because an earlier incarnation of the daemon already enabled IP forwarding in the kernel.

Similarly, when switching from iptables to nftables ...

The nftables filter-FORWARD policy doesn't get set to drop, because Docker enabled IP forwarding while it was running with iptables. To make things worse, the iptables policy gets left at "drop" ... but the iptables chains no longer have exceptions for published ports, the nftables chains have those exceptions. So, the iptables (iptables-nft) policy drops traffic for published ports.

(The upgrade case could probably be documented away, but not the daemon restart issue.)

Reproduce

See description.

Expected behavior

No response

docker version

Latest master (pre-29.0.0).

docker info

Dev build.

Additional Info

No response