Traffic Not Passing — The 7-Step PA Diagnostic Ladder

The mental model — before you touch a single command

"Traffic not passing" is the single most common ticket on every Palo Alto firewall in production. Sneha at Infosys gets one at 11:47 AM on a Tuesday: "users can't reach the SAP server, fix it now." She has two choices — guess (open the GUI, eyeball rules, hope) or run the ladder. The ladder is faster, repeatable, and works the same on every PAN-OS version from 9.1 to 11.2.

One sentence to memorise: "Match the rule → match the NAT → find the session → read the counter → capture the packet → look at ACC → check threat logs." Seven steps. That's the entire blog in one line. The rest is "exactly how" and "exactly when."

① The canonical 7-step ladder — animated

Press Play. Each stage lights up as Sneha walks the ladder for a real ticket — Infosys user 10.10.10.5 can't reach sap.infosys.in (resolves to 10.50.5.20) on TCP 443.

Steps 1 & 2 in real CLI

test security-policy-match from trust to dmz source 10.10.10.5 destination 10.50.5.20 destination-port 443 protocol 6 application ssl

"Allow-Trust-to-DMZ" {
    from                  trust;
    source                [ corp-clients ];
    source-region         none;
    to                    dmz;
    destination           [ dmz-servers ];
    destination-region    none;
    user                  any;
    category              any;
    application/service   [ssl/tcp/any/443];
    action                allow;
    icmp-unreachable      no;
    terminal              yes;
}

"interzone-default" {
    action                deny;
    ...
}

If you see interzone-default or intrazone-default in the match, your custom rule never fired. Common culprits — wrong zone, wrong service (TCP/443 vs TCP/8443), wrong application (rule says ssl but client speaks web-browsing), or the rule is below another rule that already matched. Pre-NAT source & destination always — that's a top-5 mistake on day one.

test nat-policy-match from trust to untrust source 10.10.10.5 destination 8.8.8.8 destination-port 443 protocol 6

NAT-Internet-Outbound {
    from        trust;
    to          untrust;
    source      [ corp-clients ];
    destination [ any ];
    service     any;
    nat-type    ipv4;
    to-interface  ethernet1/2;
    source-translation: dynamic-ip-and-port (interface-address)
}

"No matching NAT policy" is the most common bug on a freshly-rebuilt outbound rule. If you expected NAT and don't get a match, the rule's source/destination zone is likely flipped — Palo Alto NAT rules use PRE-NAT zones for both directions. Did this lesson already? Skim back to Blog 4 (NAT Deep-Dive) for the zone gotcha.

② Symptom → next command — the decision tree

Pick a symptom Priya at HCL hears on Monday morning. The widget tells you the exact next command and what to expect.

③ The 10 production root causes (in order of frequency)

Across PAN-OS 9.1 to 11.2, support tickets, and Live Community threads — these 10 cover ~90% of "traffic not passing" incidents. Memorise them as a checklist.

Step 4 deep-dive — the global-counter buckets you must recognise

The show counter global filter severity drop delta yes output is your fingerprint. Each counter maps to one specific stage of the dataplane pipeline. The ones below cover ~85% of real-world drops.

Step 5 deep-dive — the 4 packet-diag stages

The debug dataplane packet-diag capture splits a packet's journey into 4 stages. The combination of which stages have packets — and which don't — tells you where the drop happened, even before you read the counter.

debug dataplane packet-diag set filter match source 10.10.10.5 destination 10.50.5.20
debug dataplane packet-diag set filter on
debug dataplane packet-diag set capture stage receive  file rx.pcap
debug dataplane packet-diag set capture stage transmit file tx.pcap
debug dataplane packet-diag set capture stage drop     file drop.pcap
debug dataplane packet-diag set capture on

! ... reproduce the issue from the client (2-3 attempts is enough) ...

debug dataplane packet-diag set capture off
debug dataplane packet-diag set filter off
debug dataplane packet-diag clear all

! Now download via SCP:
scp from mgt admin@10.10.10.5:/tmp/  to-name rx.pcap from rx.pcap

④ Session-end-reason — the field that solves 70% of "allow but doesn't work"

Step 7 of the ladder is the single most-overlooked log field on the entire firewall. The session-end-reason column in Monitor → Logs → Traffic tells you why a session ended — even when action says allow. Pearl-string-of-evidence: an "allow" action with a non-clean end-reason is the firewall saying "I allowed it, but something else killed it."