The chain's policy
only takes effect if the packet reaches the end of that chain without matching any rule that has an absolute verdict statement, i.e. accept
or drop
.
If a packet matches a rule with a drop
verdict, or reaches the end of a base chain with policy drop
, it's immediately gone forever; but if a packet gets an accept
verdict, it still has to go through any other base chains that might be associated with the same hook with a higher priority number, and any chains in other applicable hooks that may come after it in the package processing pipeline. Those other chains might still drop
the packet.
So, your FORWARD base chain has policy drop
. That only means if a packet reaches the end of the FORWARD chain, it will be dropped. But the first rule in the chain matches everything and jumps to the DOCKER-USER chain, so your packet will be processed by that chain first.
In the DOCKER-USER chain, the first rule matches packets that came in via pub_br0 and are going right out through the same bridge. Your packet matches, and the verdict is accept
. That terminates the ruleset evaluation: no need to process any further in the DOCKER-USER chain, nor process the rest of the FORWARD chain; and since there seems to be no other filter
base chains associated with hook forward
, and no base chains of any type with hook postrouting
, we're done and the packet is accepted for forwarding.
If the first rule in the DOCKER-USER chain does not match, the next rule is just a counter and an explicit return
, so anything that does not match the first rule in the DOCKER-USER chain would go right back to be processed through the rest of the chain that sent us to DOCKER-USER, i.e. the FORWARD chain in this case.
But the counter for that rule currently reads packets 0 bytes 0
, so everything that's arrived into the DOCKER-USER chain so far must have been accept
ed by the first rule in the chain, because they haven't had a chance to reach the return
rule.