CCTE R81.20 common mistakes
CCTE R81.20 · Understand the traps and how to avoid them.
When a policy install fails or a gateway shows 'policy installation failed', the candidate immediately restarts the management server or the gateway instead of first reading the install log and the fw.log/CPView evidence for the specific failure stage (verification, transfer, or install).
Candidates treat policy install failure as a generic connectivity problem and jump to remediation, because the error dialog in SmartConsole is terse and they lack a mental model of the install pipeline stages. They never learned to distinguish the compile/verify phase (management side) from the transfer and install phases (gateway side), so they cannot localize the fault.
What to do instead
Before touching any service, map the failure to a stage: check the SmartConsole install progress details and the $FWDIR/log/fwd.elg on the management for compile/verify errors, then confirm SIC status and connectivity to the gateway for transfer failures, then read $FWDIR/log/fwd.elg and $FWDIR/log/cpca.elg on the gateway for install-phase errors. Only after identifying the stage should you act (e.g., re-establish SIC for trust failures, fix disk space or policy verification errors otherwise).
The candidate runs fw monitor or tcpdump on the gateway without first defining a capture filter and a hypothesis, then reads an unfiltered multi-interface capture and draws conclusions from packets that never traverse the inspection path they intended to test.
fw monitor and tcpdump are the most familiar tools, so they are reached for reflexively. Candidates do not internalize that fw monitor observes traffic at defined inspection points (i, I, o, O) and that without a filter and a clear interface/chain assumption the capture mixes pre- and post-inspection packets, producing misleading 'the firewall is dropping it' conclusions.
What to do instead
State the hypothesis and the expected path first, then capture with a tight filter: fw monitor -e 'accept src=10.1.1.10 and dst=10.2.2.20 and port=443;' and read the four-point output to see where packets stop (i/I present but o/O absent indicates a drop inside inspection). Correlate the capture timestamp with the matching log entry and the drop reason before concluding anything.
When a connection is blocked, the candidate assumes it is an implicit drop or a missing rule and starts editing the rulebase, instead of reading the actual log entry's rule number, action, and drop reason (e.g., 'Encryption failure', 'TCP out of state', 'Packet is longer than the maximum allowed').
Candidates conflate 'no log' with 'implicit drop' and do not know that many drops carry a specific reason field and a rule/implied-rule reference. They also forget that implicit cleanup and implied rules generate their own log entries with distinct rule numbers, so they misattribute the drop.
What to do instead
Open the specific log record, read the Rule column (including implied rule numbers), the Action, and the Information/Reason field, and enable logging on the relevant implied rules only if needed for diagnosis. Use the reason text to route the investigation: 'out of state' points to asymmetric routing or a stateful inspection issue, 'encryption failure' points to a VPN/IKE mismatch, 'maximum allowed' points to a packet-size or MSS problem.
The candidate treats SIC (Secure Internal Communication) failure as a certificate problem to be fixed by regenerating certificates immediately, without first verifying that the management can reach the gateway on the required ports and that the gateway's time is correct.
SIC errors surface as certificate/trust messages, so candidates assume the certificate is the root cause. In practice SIC failures are frequently caused by blocked management-to-gateway connectivity (CPMI/CPD ports), incorrect time skew, or a hostname/IP change, and regenerating the certificate before fixing these makes the situation worse and loses the audit trail.
What to do instead
Diagnose in order: verify management-to-gateway reachability on the CPD/CPMI ports, confirm both sides' clocks are synchronized, confirm the gateway object's IP and hostname match the device, then test SIC from SmartConsole. Only after those pass should you consider re-initializing SIC, and record the change.
The candidate uses cpview or top on the management server and interprets high CPU as the cause of slow SmartConsole response, without checking the management database, the number of concurrent admin sessions, or the revision/audit log growth that actually drive management-side slowness.
Candidates apply gateway troubleshooting instincts to the management server. Management slowness is more often caused by database contention, large audit/revision history, insufficient memory, or a single long-running operation (e.g., a large install or backup) than by raw CPU, so the CPU-first approach misdirects the investigation.
What to do instead
On the management server, check the management database and application logs, review audit and revision history size, verify memory and swap, and confirm no long-running operation is in progress. Use cpview for resource trends but correlate with the management-specific logs and the timing of the reported symptom before concluding CPU is the cause.
The candidate assumes that because a rule appears in the rulebase and the traffic matches it, the traffic must be permitted, ignoring NAT, VPN community membership, and the order of implied rules that can change the effective action.
Candidates reason about the rulebase visually and in isolation, without accounting for the fact that NAT translation changes the addresses seen by later rules, that VPN-encrypted traffic is evaluated differently, and that implied rules (e.g., for management access, DHCP, or established connections) can pre-empt or follow user rules.
What to do instead
Trace the actual path: use the log to see the matched rule and the pre- and post-NAT addresses, confirm whether the connection is encrypted and which community applies, and review implied rules and their position. Reproduce with a targeted fw monitor capture to confirm which addresses are evaluated at inspection.
When investigating an intermittent connectivity problem, the candidate collects a single fw monitor capture at one moment and declares the issue resolved or unreproducible, rather than setting up a sustained capture with logging and correlating across time.
Intermittent faults require evidence over time, but candidates are trained on one-shot captures and do not know how to run a filtered, sustained capture or how to correlate logs across a window. They also fear the performance impact of long captures and therefore under-collect.
What to do instead
Define the symptom window and run a filtered capture for that window (or use the gateway's built-in capture with a file output and rotation), simultaneously ensuring the relevant rules log. Correlate the capture with the log records by timestamp and connection tuple to find the pattern (e.g., a specific source, time of day, or state timeout) rather than a single snapshot.
The candidate debugs a VPN tunnel failure by changing encryption or integrity settings in the community one at a time, without first comparing the IKE and IPsec proposals and the peer identities on both ends.
VPN failures present as 'phase 1' or 'phase 2' errors, and candidates respond by tweaking settings rather than reading the negotiation logs. They do not know to compare the full proposal set, the peer identity type (certificate vs. pre-shared secret), and the community membership on both sides before changing anything.
What to do instead
Collect the IKE/IPsec negotiation logs from both peers, list the configured proposals and identities on each side, and diff them. Fix the specific mismatch (proposal, identity, or community membership) rather than iterating settings, then re-test with a filtered capture on the relevant ports to confirm the negotiation completes.
The candidate treats a 'TCP out of state' or asymmetric-routing log entry as a firewall bug and opens a support case, instead of verifying the return path and the state table behavior on the gateway.
'Out of state' sounds like an internal error, so candidates escalate rather than investigate. In reality it usually indicates that return traffic takes a different path, that a state timeout is too short for the application, or that a load balancer or router is rewriting addresses, none of which are firewall defects.
What to do instead
Verify the forward and return paths (routing tables, any intermediate NAT or load balancer), check the service's state timeout against the application's keepalive behavior, and confirm whether the connection is being seen by a different cluster member. Adjust routing, sticky connections, or timeouts as appropriate and re-test.
The candidate relies on memory of CLI syntax for diagnostic commands and runs them with wrong flags or on the wrong component (e.g., running gateway-side commands on the management, or using fw monitor flags that filter out the traffic of interest), then misreads the empty or confusing output as 'no problem found'.
The exam spans several components with different command sets, and candidates practice commands in one context and assume they transfer. Wrong-context or wrong-flag commands produce plausible-looking but meaningless output, which is then trusted.
What to do instead
Before running a diagnostic, state which component you are on and what the command observes, and verify the command's flags against its help output. Confirm the capture or query actually matches the traffic (check that counters increment or packets appear) before interpreting results; an empty result should be treated as 'capture did not match', not 'no problem'.