Stop nftables from silently dropping traffic while your logging rules do nothing

Technical Briefing | 8/12/2026

We have all been there. You write a complex nftables ruleset, test your connections, and everything seems fine until a random service starts timing out. You check your logs for dropped packets, but the file is empty. It is not that you missed the rule; it is that the kernel is burning through packets before they even hit your log chain. This usually happens because you are logging after a drop verdict or placing your log rule behind a stateful filter that assumes too much.

Where the kernel actually puts the skb

The trap is in the execution order. If you have a chain that jumps to a drop action immediately, the logger never gets a chance to see the packet. Most tutorials show you putting logging at the end of the chain, but that only works if your traffic manages to traverse every single filter without hitting a drop verdict first. You need to hook into the nflog group specifically if you want to inspect these transients in real-time without cluttering your main dmesg buffer.

nft add rule inet filter input log group 0 prefix "dropped-packet: " drop

• Avoid using log before a drop in the same rule if you are already saturating the logging buffer
• Use nflog with specific groups to keep your debug output separate from standard syslog noise
• Check your ratelimit settings, because the kernel will silently stop logging to prevent CPU starvation

Most of the time, the silent drops are caused by reverse path filtering (rp_filter) or conntrack entries that never got established correctly. When you are debugging this, don’t trust the firewall logs alone. Run a capture on the interface to see if the SYN reaches the host in the first place, or you might end up debugging a firewall that isn’t even seeing the packets you think it is dropping.

If you are still pulling your hair out, dump your full ruleset and pipe it into a text file. Look for chain policy defaults; a default drop policy will eat your traffic before your verbose logging rules even get a look. It is often faster to flip your default policy to accept temporarily and watch the traffic flow than to guess which rule is responsible for the silence.