Connections to a service on a Linux host are disappearing with no reply and you suspect the local iptables rules. Using iptables itself, how do you determine which rule is responsible?

## Counters are the cheapest evidence you have The kernel maintains a packet count and a byte count for every iptables rule, continuously and for free. `iptables -L -n -v` shows them in the `pkts` and `bytes` columns — this is the main reason `-v` is not optional in practice. A rule whose counters move is handling traffic; a rule at `0 0` is not being reached at all. The raw totals are usually useless because they cover everything since boot. The technique that makes them decisive is zeroing: ```bash iptables -Z # zero every counter in the filter table # reproduce the failure from the client, once iptables -L -n -v --line-numbers # read the deltas ``` Now every non-zero count describes exactly the traffic you just generated. `iptables -Z INPUT` zeroes a single chain, and `iptables -Z INPUT 3` zeroes just rule 3, which is handy when you want to watch one suspect without disturbing a longer investigation. ## Read the chain header too Under `-v` the chain header carries its own counters: `Chain INPUT (policy DROP 12 packets, 900 bytes)`. That number is packets that traversed the whole chain, matched nothing terminating, and were disposed of by the default policy. It is a genuinely different diagnosis from a specific rule firing: no rule is wrong, a rule is *missing*. People spend a long time hunting for "the rule that is blocking it" when the answer is that nothing accepts it and the policy is doing its job. ## When counters are not enough: the LOG target Counters tell you how many packets, not which. When you need the packets — source address, port, flags, interface — insert a logging rule directly above the suspect: ```bash iptables -I INPUT 5 -p tcp --dport 8443 -m limit --limit 5/min \ -j LOG --log-prefix "fw-8443: " --log-level info ``` Three properties make this safe: - **`LOG` is non-terminating.** The packet is logged and then continues to the next rule, so inserting the rule does not change what happens to the traffic. This is what lets you probe a live system. - **`--log-prefix` makes the lines greppable.** Keep it short and distinctive; you will be filtering on it. - **`-m limit --limit 5/min` bounds the damage.** An unrated LOG rule on a busy chain can flood the kernel log, fill a disk, and evict the very lines you were trying to read. Never insert one without a limit on a production host. The messages go to the kernel ring buffer, so read them with `journalctl -k -f` or `dmesg -w`. `NFLOG` is the alternative target when you want the packets delivered to a userspace collector rather than the kernel log. Remove the rule when you are finished. A forgotten LOG rule is noise for the next person, and the `-m limit` on it silently disguises how much traffic is really matching. ## The two checks people skip **Is the client actually on IPv4?** `iptables` governs IPv4 only. If the host has an AAAA record and the client prefers IPv6, the entire IPv4 ruleset is irrelevant to the failure and `ip6tables -L -n -v` is where the evidence lives. A wide-open-looking `iptables` listing has convinced many people the firewall is innocent while `ip6tables` was quietly dropping everything. **Is it even the filter rules?** `iptables -t nat -L -n -v` and `iptables -t mangle -L -n -v` list the other tables, each with its own counters, and a packet redirected somewhere unexpected produces the same "no reply" symptom as a dropped one. ## The symptom itself narrows the search Before any of this, the shape of the failure tells you something: - **Hangs until the client's own timeout** is the signature of a silent `DROP`. Nothing is sent back, so the client retransmits until it gives up. - **An immediate error** points at `REJECT`, which actively sends a refusal — `--reject-with icmp-port-unreachable` by default for most cases, or `--reject-with tcp-reset` — or at a host with no process listening on that port at all, which is not a firewall problem. That distinction is worth stating out loud in an interview, because it is the difference between "the firewall is dropping it" and "the firewall never saw it". ## Putting it together The sequence that resolves this quickly: confirm which address family the client uses; note whether the failure hangs or errors; zero the counters; reproduce once; read `-L -n -v --line-numbers` and find the rule or the policy line that moved; add a rate-limited LOG above the suspect if you need packet detail; fix; remove the LOG rule; and re-save the ruleset so the fix survives a reboot.