I used to be able to do iptables debugging on a Debian 9 host with specific rules in chains PREROUTING and OUTPUT (both in table raw) and target TRACE and as described here. Messages showed up in /var/log/kern.log when such rules fired.
The host had the following relevant entries in its boot config file. Things apparently worked without either CONFIG_IP_NF_TARGET_LOG or CONFIG_IP6_NF_TARGET_LOG. (I am interested in IPv4 traffic.)
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_IP_NF_RAW=m
CONFIG_IP6_NF_RAW=m
# CONFIG_IP_NF_TARGET_LOG missing
# CONFIG_IP6_NF_TARGET_LOG missing
CONFIG_NETFILTER_XT_TARGET_LOG=m
I have by now upgraded the same host to Debian 10 (Buster). It uses iptables-legacy (not the default iptables-nft), for this is in the context of a Kubernetes cluster.
What I am observing is that the same rules (e.g. iptables -t raw -A PREROUTING -d $service_ip -p tcp -j TRACE; also the same with $pod_ip) are apparently no longer working in the sense in that I do not see any resulting messages in /var/log/kern.log.
What could be the reason why and how can I further diagnose? It is perhaps the case that the TRACE capability requires a different boot config (different modules) with Debian 10, or does iptables-legacy now hinder somehow?
Now it looks as if this kind of iptables debugging does in fact still work under Debian 10 as it did previously for me under Debian 9.
Apparently I had made a mistake by installing rules for iptables debugging before recreating targeted Kubernetes services, etc. That way the iptable rules and Kubernetes resources were out of sync with respect to cluster IPs, node ports, pod IPs, etc., and so the rules never fired with traffic to those services, etc.