You can use nftrace to trace packet flows. It's very verbose but doesn't go to kernel logs but instead is distributed over multicast netlink socket (ie if nothing listens to them, traces just go to "/dev/null").

If you really want to trace everything, trace from prerouting and output at a low priority. Better use a separate table, because what you are displaying with nft list ip table filter is actually iptables-over-nftables with the compatibility xt match layer API and shouldn't be tampered with (but can safely be used along traces). Also you should know there are probably other tables for iptables, like the nat table.

So, with a ruleset from the file traceall.nft loaded with nft -f traceall.nft:

table ip traceall delete table ip traceall table traceall { chain prerouting { type filter hook prerouting priority -350; policy accept; meta nftrace set 1 } chain output { type filter hook output priority -350; policy accept; meta nftrace set 1 } } 

You can now follow these (very verbose) IPv4 traces with:

nft monitor trace 

This would even work the same if doing this inside a container (which is usually not the case for log targets).

You can activate these traces elsewhere, or put conditions before activating them, and also deactivate them (meta nftrace set 0) again in a rule in a later priority to avoid tracing all hooks/chains. Following this schematic will help understand the order of events: Packet flow in Netfilter and General Networking.

For iptables-over-nftables ' equivalent version of the TRACE target, consult the man for xtables-monitor.

---

While I answered OP's question, here are wild guesses about both issues and log issues:

• if Docker itself is running within a container, logs might not be available. They can be made available to the host, and to all containers allowed to query the kernel messages, with sysctl -w net.netfilter.nf_log_all_netns=1, simply because kernel messages don't have namespace instances.

• the counter at the log rule in ip filter INPUT is zero, while the counter at the previous rule with a drop statement is not. That means the log rule is made too late: after drop. The log rule (or rather iptables's -j LOG) should be inserted before the final drop statement, not appended after where it will never be reached.

• The only INPUT rule about Docker is iifname "docker0" counter packets 0 bytes 0 accept. If the containers are not on the default Docker network, there's no rule allowing them to reach the host.

  Try adding a rule for testing this. Be sure the result is inserted before the drop rule. Use iptables, avoid adding a rule with nftables that could be incompatible with iptables-over-nftables:

  iptables -I INPUT 8 -i "br-*" -j ACCEPT