I85PREP
⌘ K
CCTE R81.20 study materials
CCTE R81.20 study resources

CCTE R81.20: Security Gateway and Security Policy Troubleshooting

CCTE R81.20 · Work through your exam, one topic at a time.

All guide sections

Security Gateway and Security Policy Troubleshooting

Domain 3 tests enforcement on the Security Gateway: whether the correct policy is installed, whether acceleration or cluster state changes behavior, and whether routing, NAT, or anti-spoofing explains the drop. The exam rewards evidence from gateway commands over assumptions from the GUI.

Policy installation and verification

  • fw stat on the gateway shows the policy name, install time, and management server. If it is stale, run fw fetch <management> or reinstall from SmartConsole.
  • Policy verification errors in SmartConsole often concern implied rules, NAT, VPN, or blade ordering; read the specific verification message before editing.
  • Check licenses and contract files; an expired license or missing blade can block install or enforcement.
  • After a management restore, gateways may still hold an older policy; compare timestamps.

Acceleration, cores, and cluster

  • fwaccel stat shows SecureXL status; fwaccel conns shows accelerated connections. Accelerated traffic can bypass parts of the kernel path and change what fw monitor sees.
  • fw ctl multik stat shows CoreXL instances; uneven distribution can explain CPU hotspots.
  • For clusters, cphaprob stat, cphaprob -a if, and cphaprob list show failover state and interface monitoring. Debug the active member, not the standby.

Routing, NAT, and anti-spoofing

  • Check ip route, interface configuration, and ARP/neighbor entries before deep debugging.
  • NAT errors often look like routing errors: the post-NAT source or destination selects a different route.
  • Anti-spoofing drops appear in logs with a spoofing reason; verify topology and interface direction.

Worked example

A new policy is installed, but HTTP to a published server fails. On the gateway, fw stat shows the new policy timestamp, so propagation is not the issue. SmartLog shows an implied-rule drop for the server's port. The rule base allows the service, but Global Properties has Log Implied Rule enabled and the actual drop is anti-spoofing on the internal interface. Check cphaprob -a if and topology: the server's subnet is defined on the wrong interface. Correcting topology and reinstalling policy restores traffic. The reasoning: policy name alone does not prove the packet matched the intended rule; the log reason and topology check identify the enforcement point.

Traps

  • Assuming Installed means the gateway fetched the current policy.
  • Debugging a standby cluster member.
  • Forgetting that NAT changes routing lookup.
  • Ignoring SecureXL when captures look incomplete.
  • Treating anti-spoofing as a routing problem.