Firewall Rule Planner
Plan a firewall change — or audit the rules you already run — before anything touches production.
Add your proposed rules with source, destination, protocol and port, and the planner checks the whole set for you:
overlapping rules, rules that shadow later ones, exact duplicates,
redundant entries, and anything overly broad (an allow from anywhere, SSH or a
database port exposed to the internet, a 40,000-port range). Every finding comes with a plain-English explanation
and a suggested fix. When you are happy, export the set as readable text, CSV or JSON — or as starting-point
iptables, nftables or pf (OPNsense/pfSense) snippets to review and adapt.
1 · Your rule set
| # | Name / purpose | Action | Direction | Source | Destination | Protocol | Ports | Flags |
|---|
any, single IPs, CIDR blocks (IPv4 and IPv6) and hostnames. Ports accept numbers, ranges (80-443), comma lists, service names (ssh, https…) or any.2 · Analysis
3 · Export
How firewall rule ordering works
Most stateful firewalls (iptables/nftables, pf behind OPNsense and pfSense, Windows Firewall) evaluate rules in the order you wrote them and stop at the first match. That single fact explains almost every “why is my rule not working” ticket:
- A deny above an allow wins. If a broad deny (or a block from a bad range) sits before the allow you actually wanted, the traffic never reaches your allow rule. The planner flags this as shadowing.
- A narrow allow above a broad allow is fine — and usually intentional. Overlaps with the same action are harmless but cluttered; the planner marks the later one as redundant when an earlier rule already covers all of its traffic.
- Catch-all rules go last. A final “deny everything else” is the safe default posture. If it sits in the middle, every rule after it is dead weight.
- Specific before general. The classic layout: named exceptions first, then service allows, then the catch-all deny.
Least-privilege checklist for a new rule set
- Every allow names a real source range — never
anyunless the service is genuinely public. - Remote-admin and database ports (SSH 22, RDP 3389, MySQL 3306, PostgreSQL 5432, Redis 6379, MongoDB 27017…) are reachable only from VPN or office ranges.
- No allow uses protocol
anywith a wide or open port range. - The set ends in an explicit deny-all for the direction you are protecting.
- No two rules say the same thing twice — duplicates drift apart over time and one copy always gets edited.
Suggested
Luke Keam | techgeek.biz