Troubleshoot
Troubleshooting questions reward a systematic method over memorized commands. Establish the layer: is the packet arriving, being dropped by policy/NAT/decryption, being routed out, or is the return path failing? Use the traffic log detail view first (it shows the rule matched, the stage, and the reason), then targeted tools: test security-policy-match, test routing fib-lookup, test url, ping/traceroute sourced from the firewall, show session all filter, show counter global filter, and show running resource-monitor for CPU, session, and packet buffer pressure.
Packet capture is the decisive tool, but stage matters. Capture on the firewall dataplane stages (drop, firewall, receive, transmit) to see exactly where the packet disappears. A packet that never appears at the firewall stage is a routing, zone, or MAC-layer problem; a packet seen at the firewall stage but not transmitted is a policy, NAT, decryption, or profile drop.
Frequent traps: asymmetric routing causing drops after a firewall restart or routing change; MTU and MSS with IPsec or encapsulation; testing reachability with ping when the policy permits only a specific application; certificate/decryption failures (forward trust vs forward untrust, untrusted CA chain); and content or App-ID not yet identified so a rule matches an unknown-tcp/unknown-udp fallback. On HA, remember that sessions are not synchronized for every failure scenario if the path or configuration is incomplete.
Worked example: users cannot reach a SaaS app but ping succeeds. Check the traffic log for the deny, run test url or test security-policy-match with the exact source user, destination, and application, then compare whether the rule's service or application restriction is blocking the real traffic.