PCNSE common mistakes
PCNSE · Understand the traps and how to avoid them.
Sizing a firewall or choosing an HA configuration from the headline firewall throughput number (or from the active/active label alone) without derating for App-ID, threat inspection, decryption, and logging, and without stating what A/A actually buys.
Candidates memorize a single 'throughput' figure from datasheets and assume A/A doubles capacity per session; the exam instead tests that threat/SSL inspection throughput is much lower than App-ID throughput, and that A/A load-shares flows between peers rather than giving a single flow more capacity.
What to do instead
In design questions, select the model using the threat-prevention and decryption throughput figures, note the expected inspection profile and log volume, and justify HA mode by requirement (A/P for simplest failover and per-session symmetry; A/A floating IP for aggregate throughput with session hashing). State the assumption explicitly in the answer rationale.
Writing a security policy rule that matches the pre-NAT (public/original) destination IP and the external source zone for an inbound destination-NAT flow, then concluding the policy is broken when traffic is still denied.
The order of operations is misremembered. On ingress the firewall applies destination NAT, then routes, then performs the policy lookup, so the policy must match the post-DNAT destination address and post-DNAT zone; source NAT is applied only after the policy decision.
What to do instead
Memorize the sequence destination NAT → routing → security policy → source NAT. Build the rule with the translated (inside) address and the inside zone as destination zone. If the traffic is internal U-turn NAT, remember both source and destination zones are the post-NAT ones. Confirm with Test Security Policy Match using the post-NAT addresses.
Allowing an application with Service set to application-default while the app runs on a non-standard port, or setting Service to any and expecting App-ID dependent policies (App-ID shift, application filters) to behave predictably.
Candidates treat App-ID and Service as interchangeable. application-default restricts the rule to the application's standard ports, so a non-standard port never matches; conversely Service any masks port-based intent and defeats dependency-based App-ID shifting on the first packet.
What to do instead
Use application-default when the app is on its default ports; add the explicit custom service (or a separate rule) when it is not; reserve Service any for cases where port is genuinely irrelevant. Remember App-ID identification occurs on early packets, so a port-based implicit dependency may be needed for accurate identification on non-standard ports.
Configuring interfaces, zones, and policies on Panorama and pushing, but placing network settings inside a device group (or policy objects inside a template), then wondering why the push fails or the settings never reach the firewall.
The split between templates (network/device configuration, template stacks and variables) and device groups (policy, objects, profiles) is confused, and candidates forget that a Panorama commit and a push-to-devices are two separate steps with a scope.
What to do instead
Classify each item before configuring: interfaces, virtual routers, zones, HA, and device-level settings go in templates/template stacks; security rules, objects, profiles, and NAT live in device groups. After Commit to Panorama, verify the push scope and success per device, and check that overridden local configuration is not blocking the pushed values.
Assuming Threat Prevention, URL Filtering, WildFire, or DNS Security behavior is active on a device or firewall managed by Panorama without verifying the license state and the dynamic content update status and schedule.
The exam scenario describes a security outcome (a verdict, a block page, a signature hit) and candidates answer on feature configuration alone, forgetting that the subscription must be active, content must be current, and Panorama-pushed content updates must actually reach the managed devices.
What to do instead
Before answering, confirm the relevant license is active, check the installed content versions and update schedule, and verify that Panorama is pushing content to the device group. Remember license activation can require a commit or an explicit content check, and that a security profile with no license/updated content produces no enforcement.
Adding a new allow rule at the bottom of the rulebase (or wherever it fits visually) while a broader rule above it already matches the traffic, and not checking hit counts or rule shadowing after the commit.
Candidates assume 'a permit rule exists' equals 'traffic is permitted'. PCNSE scenarios hinge on top-down first-match evaluation, the intrazone-default allow and interzone-default deny, and the fact that adding a rule below a matching rule changes nothing.
What to do instead
Use Test Security Policy Match with the actual five-tuple to see which rule matches, check hit counts on the candidate rules, and review rule-shadowing and rule-inefficiency warnings before commit. Place specific rules above general ones and, when the requirement is deny, ensure no broader allow rule sits above it.
Declaring the firewall innocent or guilty from a single packet capture taken at the default stage, or ignoring the session end reason and drop counters in the traffic log.
The capture stages are misunderstood: the firewall-stage capture shows traffic entering the forwarding path in both directions and does not show packets dropped earlier (receive/drop stages). Candidates also read only the deny/allow action and skip the session end reason (policy-deny, aged-out, tcp-fin, resources-unavailable) and global drop counters.
What to do instead
Capture at the correct stage (firewall for forwarding-path traffic, drop stage for discarded packets, receive/transmit for interface-level issues) with a tight filter, and correlate timestamps with the traffic log. Read the session end reason and check global counters with a delta flag after repeating the failing flow, so the counter change is attributable.
Enabling an SSL decryption policy without completing the trust chain and exclusions: no forward trust / forward untrust CA generated, the forward trust CA not distributed to endpoints, and no decryption exclusions for pinned, certificate-validating, or unsupported applications.
Candidates treat decryption as one checkbox and forget it is a separate policy evaluated ahead of security policy, dependent on a certificate pair, and dependent on the endpoint trusting the forward trust CA; they also forget that decryption can break applications that pin certificates.
What to do instead
Generate both forward trust and forward untrust certificates, sign/issue the forward proxy CA, distribute the forward trust CA to endpoints via GPO/MDM, and attach the correct certificate to the decryption policy and SSL/TLS service profile. Add decryption exclusions and no-decrypt rules for pinned and unsupported apps and sensitive categories, and verify with the decryption log and certificate details in the session.
Building a route-based IPsec VPN that reports the tunnel as up, but leaves the tunnel interface without a zone or virtual router, with no route to the remote subnet, and with no security policy permitting the tunnel zone - then diagnosing 'the VPN is up but nothing passes'.
Candidates stop at IKE gateway and IPsec crypto profile configuration and treat 'tunnel up' as end-to-end success, forgetting that the tunnel interface must be zoned, routed, and permitted exactly like a physical interface, and that policy-based VPNs additionally depend on matching proxy IDs.
What to do instead
Complete the checklist: IKE gateway and crypto profile attached to the tunnel interface, tunnel interface in a dedicated zone and in the virtual router, static route to the remote protected subnet via the tunnel, security rules in both directions between tunnel zone and LAN zone, and matching proxy IDs (or no proxy IDs for route-based) on both peers. Verify phase 2 selectors and that the tunnel interface counters increment.
Configuring GlobalProtect with a portal that has no gateway attached or a gateway with no valid certificate in its SSL/TLS service profile, and writing HIP-based or user-based policy without HIP data collection or without verified user-to-IP mapping.
Portal, gateway, agent configuration, and HIP are treated as one object. Candidates forget the portal/gateway relationship, that the gateway needs a certificate for the portal and tunnel connections, and that HIP-enabled and user-based rules silently never match if HIP collection is off or if User-ID mapping is absent.
What to do instead
For GlobalProtect, verify the portal configuration lists the gateway(s), each gateway has an SSL/TLS service profile with a valid certificate matching the connecting hostname, and the portal agent configuration defines the connection method and any HIP profile assignment. For HIP and user rules, confirm HIP data collection is enabled, then verify identity with the IP-to-user mapping output and the group mapping source before troubleshooting the policy itself.