Firewall health¶
Question this answers: "Which rules are dead weight or quietly too permissive?"
Health is a structural read on a single policy — independent of any edit. It scans for rules that match no packets, rules an earlier rule already decides, and the independent blocks your policy breaks into. Each finding points to the exact rules involved.
Running an analysis¶
Open the Health panel with a policy loaded. Firevyzer analyzes the current rule list and reports three things: redundant rules, shadowed rules, and the policy's structural decomposition. A summary line at the top tells you how many findings need review.
Redundant rules¶
A redundant rule decides no packets — every flow it could match is already decided by an earlier rule. It is dead weight: removing it cannot change the policy's behavior.
Redundant rules are always safe to delete, and the panel offers a one-click Remove.
Shadowed rules¶
A shadowed rule has part — or all — of its traffic claimed by an earlier rule.
- Partially shadowed — an earlier rule decides some of this rule's traffic. The rule still fires for the rest, but its written guard overstates what it does. Worth a look.
- Fully shadowed — an earlier rule decides all of it. (A fully shadowed rule is also redundant, and is reported as such.)
Catch-all shadowing is normal
A trailing catch-all — any → any : drop — is partially shadowed by every
specific rule above it, because those rules consume most of its match. That's
expected, not a problem. Firevyzer separates this catch-all shadowing out
from genuine findings so it doesn't drown the signal; you can expand it if
you want to see it.
Overly broad rules¶
A rule can be valid yet reach further than intended — a catch-all that allows any port except 22 to a host, for example. These surface as traffic classes describing what the rule actually decides in context, so an over-permissive shape is visible as the real set of packets it lets through rather than its innocent-looking guard.
Structure¶
Firevyzer also decomposes the policy into independent blocks — groups of rules whose guards never intersect another group's. Rules in different blocks decide disjoint traffic, so each block is a self-contained sub-policy you can reason about, or refactor, on its own. The recombined allow-set provably equals the original.
Broad rules tie everything together
If your whole policy collapses into a single block, a broad rule is usually the culprit — it overlaps enough traffic to connect otherwise-independent groups. Tightening it can reveal the real structure underneath.
The result shape¶
For integrators, analysis returns:
| Field | Meaning |
|---|---|
redundant |
rule references that decide no packets (dead) |
shadowed |
findings of the form { rule, fully_shadowed, shadowers } |
decomposition |
independent sub-policies, as lists of rule indices |
shadowers are the earlier rules whose decision region overlaps this rule's
guard. decomposition is the connected components of the rule-overlap graph.
Scope it down¶
Pair Health with a traffic scope to audit just the rules that touch a particular host or subnet. Rules that don't touch the scoped flow are hidden from the findings, and the panel tells you how many it set aside.