This tool lets you build a firewall policy (ACL) and automatically detect common misconfigurations: conflicting rules with different actions on identical traffic, shadowed rules that are never evaluated due to earlier broader rules, overly permissive ANY-source or ANY-destination ALLOW entries, and the absence of a default deny-all at the end of the ruleset. Load the pre-built sample to see all issue types, then build your own policy.
This analyzer uses first-match top-down evaluation, which is the model used by Cisco ASA, Cisco IOS ACLs, pfSense, FortiGate, Palo Alto Networks security policies, Check Point, and Linux iptables. Rules are evaluated from top to bottom. The first rule that matches the packet's source IP, destination IP, port, and protocol determines the action (ALLOW or DENY). All subsequent rules for that packet are ignored.
This means rule order is critical: more specific rules must appear BEFORE broader rules that cover the same traffic, otherwise the broad rule shadows the specific one. The classic mistake is placing a deny rule for a specific host below a permit-any-any rule — the permit fires first and the deny is never reached.
CONFLICT (High): Two rules have identical source, destination, port, and protocol but different actions (ALLOW vs DENY). The later rule can never fire — the first-match rule always wins. One of them is always wasted.
SHADOWED (Medium): An earlier rule subsumes all traffic that a later rule would match. The later rule is never evaluated. This is the most common production misconfiguration — administrators add specific deny rules after broad permit rules and wonder why the deny has no effect.
OVERLY PERMISSIVE (High/Medium): ALLOW rules with ANY source and/or ANY destination expose the network beyond the minimum required access. ANY→ANY ALLOW is the most critical form.
NO DEFAULT DENY (High): The ruleset does not end with an explicit DENY ANY ANY rule. Traffic that matches no rule depends on platform default behavior.
Follow this ordering pattern for a well-structured policy:
1. Deny obvious bad traffic first (known malicious IPs, deprecated protocols like Telnet/FTP) 2. Permit management traffic from restricted management subnets only 3. Permit specific application flows: app-tier → db-tier on the required port only 4. Permit monitoring flows: SNMP, syslog, NTP from monitoring servers 5. Permit required external inbound (HTTPS/443, SMTP/25, etc.) to specific destination hosts 6. Deny all (catch-all at the bottom)
For OT/ICS networks per IEC 62443: the IT/OT DMZ firewall should have explicit deny rules for all Microsoft file-sharing protocols (SMB 445, NetBIOS 137-139), direct RDP without a jump server, and all protocols not specifically required by SCADA/DCS communications.
After clicking Analyze, the rule table highlights issues directly on the affected rows:
Red border: The rule is involved in a conflict — it shares identical match criteria with another rule but has a different action.
Orange border: The rule is shadowed — an earlier rule covers all its traffic. This rule will never match.
Yellow border: The rule is overly permissive — it uses ANY source or ANY destination in an ALLOW rule.
No highlight: The rule has no detected issues. Note that an absence of highlighting does not guarantee the rule implements your intended security policy — it only means no automated conflict/shadow/permissive issue was detected. Manual review is always required.
A shadowed rule appears later in a ruleset than a broader rule that already matches all the same traffic. Since firewalls evaluate top-down (first match wins), the shadowed rule is never evaluated. For example, if Rule 3 permits ANY→ANY TCP 443, and Rule 7 denies 10.0.0.5→192.168.1.1 TCP 443, Rule 7 is shadowed — Rule 3 always matches the traffic first.
ANY→ANY ALLOW means the firewall will pass all traffic from any source to any destination, effectively removing it as a security control for that traffic type. It is almost always a temporary "dev" or "test" rule that gets left in production. Even if it's not the first rule, if anything above it fails to match, this rule passes the traffic. Remove it and replace with specific source/destination CIDRs.
Not directly — you enter rules manually using the web form. This tool is for policy design and review, not config file parsing. For parsing real Cisco ACL configs or FortiGate policies, use vendor-specific tools or open-source parsers like Batfish or Capirca. This tool is best used during the design phase to validate your intended policy before deploying it, or to manually transcribe and audit an existing policy.
A conflict occurs when two rules have identical source IP, destination IP, port, and protocol but different actions (one ALLOW, one DENY). The first rule in the list always wins due to first-match semantics, making the second rule unreachable. This is often a sign of a rule added to fix a security issue that was already handled by an earlier rule, or a duplicate rule from a policy merge. Remove one of the conflicting rules after determining which action is correct.
Yes — LOG rules (which log matching traffic without blocking or allowing) are useful for visibility before committing to a DENY. A common pattern: add a LOG rule above a DENY rule with the same criteria to see how much traffic would be blocked before enforcing the deny. LOG-then-DENY is also used for forensic capture of attack traffic. Be aware that logging every matched packet on high-traffic rules generates significant log volume — apply LOG selectively to suspicious or high-value traffic categories.