A firewall with IP whitelists, IP blocklists, custom rules, DDoS gates, and application-layer policy all active at once needs an unambiguous answer to "what happens when two of these disagree about the same packet." Neurowall's precedence order is fixed, documented, and testable before you ever apply a change.
Firewalls that layer multiple enforcement mechanisms — IP whitelists, IP blocklists, custom rules, DDoS heuristics, application-layer policy — inevitably produce cases where two of them technically apply to the same packet. If the precedence between them isn't fixed and documented, every conflict becomes a debugging session instead of a known answer.
If "which rule wins" isn't specified, a rule change can silently produce a different outcome than intended — and nobody notices until traffic behaves unexpectedly.
Once you have more than one enforcement mechanism, something has to decide what happens when they disagree — leaving that implicit means it can change between versions without anyone deciding it should.
Mid-incident is the worst time to discover that a manual emergency block doesn't actually take precedence over a stale custom rule someone forgot about.
A rule-review process worth its name asks "what happens if these two rules conflict" — an answer of "we're not sure" is a finding, not a shrug.
Neurowall evaluates enforcement layers in a fixed sequence and stops at the first layer that produces a decisive verdict. The same precedence engine backs both live traffic decisions and the policy trace/simulation endpoints, so a "what if I add this rule" check and the real enforcement path never disagree.
In the fast packet-filtering layer itself, the IP whitelist is checked before the IP blocklist — any whitelist match passes the packet regardless of how specific a matching blocklist entry might be. If the IP blocklist is consulted and multiple entries could match, the most specific one wins. DDoS flood-gate checks run before the custom rules step in modes that include both — a confirmed flood pattern can drop a packet before your custom rules are ever consulted.
A rule's priority field decides which enforcement layer it's placed in (fast-path-eligible vs firewall-rules-only, threat-intel tier vs manual tier) — it does not arbitrate between two already-placed rules matching the same packet, since each lookup is a direct key match, not a scanned list.
Policy trace simulation doesn't approximate what will happen — it runs the proposed change through the identical verdict-derivation logic used for live traffic. A shadowed rule, an unreachable IP blocklist entry, or an unexpected IP whitelist override shows up in the simulation exactly as it would in production, before it's applied.
| Scenario | What simulation catches |
|---|---|
| A new IP blocklist entry is unreachable | An existing IP whitelist CIDR already covers the address — the new block would never fire, and simulation shows the whitelist match taking precedence |
| A new rule is shadowed by an existing one | A broader existing rule already decides the same traffic — the new rule's effect is visible (or its absence of effect) before it's live |
| A DDoS threshold change interacts with a rule | Simulation reflects that DDoS gates run before the rules stage, so a stricter DDoS threshold can pre-empt a rule that was expected to be the deciding factor |
| An admin-gated live check | The live-simulation variant runs an actual probe against the running filter for the highest-confidence pre-apply verification available |
| Common approach | The gap |
|---|---|
| First-match, top-to-bottom rule lists | Precedence exists but is implicit in rule ordering — reordering rules for an unrelated reason can silently change which rule wins for existing traffic |
| No distinction between simulation and live logic | A "test mode" that approximates production behavior with separate code can drift from what actually happens once applied — the two paths quietly diverge over time |
| Undocumented allow/block ordering | Whether IP whitelists or IP blocklists win is often left to vendor documentation (if it exists at all) rather than being independently verifiable via a simulation tool |