Make a firewall rule fail by putting it in the wrong place

short · 35 min · Objective 3.2

Task

Write a rule set where a specific deny sits below a broad permit, prove the deny never fires, then reorder and prove it does. 'The rule exists but is not working' is nearly always rule order, and this is the fastest way to internalise it.

Steps

Start from a clean, permissive state and confirm the other lab VM can reach a test service on this host.
Add rules in the WRONG order: first a broad permit for the lab subnet on all ports, then a specific deny for the test service from the other VM's address.
Test from the other VM and record that the connection still succeeds despite the deny rule being present.
Show why with the rule counters: list the rules with packet counts and observe that the deny rule's counter is zero — it has never matched anything.
Reorder so the specific deny sits above the broad permit.
Test again, record that the connection is now refused, and confirm the deny rule's counter is non-zero. Write both counter readings into /tmp/ruleorder.md.

Verify

sudo iptables -L INPUT -v -n --line-numbers 2>/dev/null | head -20 || sudo nft -a list chain inet filter input
sudo iptables -L INPUT -v -n 2>/dev/null | awk '/DROP|REJECT/ {print $1" packets matched the deny rule"}'
grep -ciE "counter|zero|order" /tmp/ruleorder.md

The counter is the verification and it is why this lab does not just test connectivity: a deny rule with a zero packet count has never been consulted, which tells you the problem is order rather than syntax. After reordering the same rule must show a non-zero count.

Notes

Reading rule counters is the fastest firewall diagnostic there is, and almost nobody does it. A rule that looks correct and has never matched is either unreachable behind an earlier rule or written against traffic that does not exist, and the counter distinguishes the two in one command.

This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.