Rules That Don't Work — The Problem Is the Chain

When deploying pfsense, OpenWrt or an Ubuntu firewall on a mini pc, users often find rules not taking effect, ports silently dropped, or dual-lan forwarding failing. The root cause is usually not the command, but a missing understanding of the iptables rule chain model: a packet traverses five built-in hooks in fixed order — PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING. Pick the wrong table (filter, nat, mangle) or the wrong chain, and the packet gets DROPed somewhere you cannot see.

Trace the Packet Path, Then Choose the Chain

On a dual lan mini pc acting as a soft router, an inbound request first passes PREROUTING for DNAT, is filtered by the FORWARD chain, and leaves via POSTROUTING for SNAT. Clear on this path, you know whether a permit rule belongs in the filter table or the nat table, instead of appending blindly. On a 4 ethernet ports mini pc, the binding between each chain and the -i / -o interface directly decides whether cross-subnet forwarding works.

Debug by Chain to Locate the Drop

With the chain model in mind, troubleshooting moves from commenting out rules one by one to per-chain probes: use -L -v -n to read chain counters, and add a LOG target in FORWARD to see which hop drops the packet. This matters on a fanless firewall running 24/7, since one misplaced DROP rule can take the whole LAN offline. Shenzhen Helor Cloud Computer Co.,Ltd. advises customers to map the chain path before writing rules, in industrial mini pc network deployments.

In Short

iptables is not a pile of rules; it is a travel map for packets. Grasping the division between the five chains and four tables lets pfsense and OpenWrt soft routers behave as expected, blocking accidental drops and misfilters before deployment.