The Deny Rule That Never Fires and the Permit Rule That Never Matches
An enterprise runs a USG6650E in routed mode with three zones: trust (10.10.0.0/16, roughly 3,000 clients), dmz (172.16.8.0/24, eight servers) and untrust. The policy set was migrated from an older firewall and now holds 340 rules, several of them broad permits. Two problems appeared in the same week. First, RDP from trust to the DMZ jump host 172.16.8.20 on TCP 3389 still works even after a rule named deny-rdp-to-dmz was inserted at position 300. Second, a rule at position 5 that permits the DMZ patch server 172.16.8.31 to reach an internal WSUS server 10.10.20.15 on TCP 8530 does not work and the patch job times out. The default interzone action is deny, no NAT is involved in either flow, and both rules show zero hits in the policy counters. A change freeze protects the core rules and the customer wants a low-risk fix before the weekend maintenance window.
1. Both rules show zero hits. Explain what that single fact tells you about each flow, and give the diagnostic sequence you would run before editing any rule.
Read the worked answer
Zero hits does not mean the same thing in both cases. Security policy counters increment when a new session is created, not per packet, because the firewall is stateful.
For the RDP flow the counter behaviour is expected: the RDP session to 172.16.8.20 was built before rule 300 existed (or was built by a broad permit above it) and the firewall keeps forwarding it from the session table. Packets of an established session never re-enter policy lookup, so the deny rule cannot fire. Diagnosis: display firewall session table verbose source 10.10.x.x destination 172.16.8.20 to see the session age and the rule that created it, then, in a declared window, reset firewall session table for that 5-tuple and reconnect. If the deny is correctly placed it will then match.
For the WSUS flow, a permit that shows zero hits means no new session ever reached it - the packet was dropped before policy lookup or never arrived. Sequence: confirm 172.16.8.31 is really in the dmz zone and the interzone direction is dmz→trust (not trust→dmz); check display ip routing-table for a route back to 172.16.8.0/24 and display firewall server-map for a stale NAT entry; verify the WSUS service is listening and ARP resolves; then check the hit counters of all rules above position 5 - a shadowing rule would itself show hits. Finally capture with packet-filter on both interfaces to prove where the packet dies.
2. The customer insists position 300 is 'approved and tested' and refuses a full re-ordering. What is the minimal-risk implementation, and what would you verify before and after?
Read the worked answer
Before: export the running configuration, list every rule above position 300 that matches trust→dmz, and read their hit counters. The blocker is almost certainly a broad permit (source any, destination any, service any) whose counter is climbing.
Minimal-risk change: do not renumber 340 rules. Insert a narrow deny for the exact 5-tuple 10.10.0.0/16 → 172.16.8.20:3389 immediately above the first broad permit that currently matches, rather than at 300, and leave the rest of the ordering untouched. If the platform requires a fixed ordering, use the policy move function to shift only the one rule and re-verify the ID/position mapping afterwards, since IDs and display order are not the same thing. Pair the deny with an explicit exception for the two jump-host admin subnets so the change is scoped, and clear the existing RDP sessions in the window, otherwise the deny appears not to work.
After: confirm the deny counter rises from a test client, confirm the permitted subnets still work, confirm the WSUS flow by watching its own counter rise, and re-check that no broad permit above the new rule is still matching the same traffic. Record the pre-change counters so a rollback decision is data-driven rather than a guess. Also put a note in the change record that hit counters are session-based, because the next engineer will read 'zero hits' as 'not matched'.