Troubleshooting
Free Palo Alto Networks Certified Network Security Engineer practice — 6 questions on Troubleshooting, with explanations. No sign-up. Full 12-question mixed test →
A destination NAT rule translates traffic addressed to public IP 203.0.113.10 to an internal server at 10.1.1.50, which resides in the DMZ zone (interface ethernet1/3, DMZ zone). The Untrust zone interface faces the internet. An engineer configures a security policy rule with source zone Untrust, destination zone Untrust, destination address 203.0.113.10, action allow. Traffic matching the NAT rule is still denied. Given how PAN-OS orders NAT and security policy evaluation, what is the root cause?
PAN-OS performs NAT policy lookup before the security policy lookup to determine post-NAT zones. The security rule's destination zone must reflect the translated (post-NAT) zone, while the destination address in the rule still matches the original pre-NAT IP address because the packet header hasn't been rewritten yet at the point of policy evaluation. Using Untrust as the destination zone here is the misconfiguration.
While troubleshooting SSL Forward Proxy decryption, `show session id <id>` on a firewall returns: session end-reason: decrypt-cert-validation. All other decrypted sites work normally. Which situation most likely produced this specific end-reason?
The decrypt-cert-validation end-reason specifically indicates the firewall's Forward Proxy validation of the destination server's certificate failed (untrusted issuer, expired, or revoked) and the applicable Decryption Profile setting for blocking sessions with untrusted issuers/expired certificates is enabled, so the session is terminated rather than allowed through.
An engineer suspects packets destined for an internal host are being silently dropped at some internal processing stage but wants to avoid running a full packet capture. Which command displays only the global counters that have incremented since the packet-diag filter was applied, allowing quick identification of the exact drop reason (e.g., flow_policy_deny, flow_fwd_l3_noroute)?
`show counter global filter delta yes packet-filter yes` restricts output to counters that have incremented since the packet-diag filter was set, which is the standard PAN-OS technique to pinpoint exactly which internal drop counter is firing for a matched flow without capturing full packets.
Users report that a specific mobile banking application consistently fails to connect whenever SSL Forward Proxy decryption is enabled for their zone. The decryption policy correctly matches the app's traffic, and the Forward Trust CA certificate is properly deployed and trusted on all managed endpoints. Disabling decryption for that traffic immediately resolves the issue, while all other decrypted sites continue working fine. What is the most likely cause and best remediation?
Certificate pinning — common in banking and financial mobile apps — causes the app to reject the firewall's re-signed certificate even though it is properly trusted at the OS level, because the app validates the server's original certificate specifically. Since only this one app fails while everything else decrypts fine, the documented remediation is a targeted decryption exclusion for that FQDN/app, not a CA, cipher, or protocol-wide change.
Remote users see the error "Unable to connect to GlobalProtect service: Verify server certificate" only when connecting to the gateway using its published FQDN (not when connecting directly by IP). The gateway's SSL/TLS Service Profile uses a certificate issued by an internal enterprise CA, and the GlobalProtect app is configured to validate server certificates. What is the most likely fix?
Certificate validation checks the SAN (not just CN) against the hostname used to connect; failing only on FQDN-based connections (not IP) strongly indicates a SAN/hostname mismatch, and the client must also trust the issuing internal CA. Both the SAN entry and CA trust chain must be correct for validation to succeed.
In an active/passive HA pair, both firewalls unexpectedly transition to the active state simultaneously, causing routing instability. The HA2 (data) link and all dataplane interfaces remain fully operational between sites, but `show high-availability state` on each firewall reports the peer as "unknown" with no heartbeats received. What most likely caused this split-brain condition, and what is the recommended long-term fix?
The symptom of the peer state reporting as "unknown" with no heartbeats received, despite the HA2 data link and dataplane being fully functional, is the classic signature of an HA1 control link failure. Without a configured HA1 backup link, both members lose heartbeat visibility and independently assume the active role, producing split-brain; the standard remediation is a redundant HA1 backup link on separate infrastructure.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →