Session Table & Flow — Watch a Session Live, Decode Every Field

The 6-tuple — not 5

Every networking textbook teaches you the "5-tuple": source IP, source port, destination IP, destination port, protocol. Palo Alto adds a sixth — ingress zone. This is why the same source / destination IPs entering via two different zones get two separate sessions, and why flow_fwd_zonechange (from Blog 15) fires on asymmetric routing — an existing session sees a packet arriving via a different zone and panics.

Sneha at Infosys learns this the hard way during an A/A HA cutover: the firewall sees zone trust for the SYN, zone trust-b (peer interface) for the SYN-ACK. Two sessions get created; one of them ages out lonely; the user sees an intermittent app. The 6-tuple is the firewall trying to protect you from stateful-inspection confusion.

① The session state machine — animated

PAN-OS sessions cycle through up to 7 states. Pick a scenario, press Play, watch how each state transitions.

The DISCARD branch — what happens when policy denies

When a packet's first SYN matches a deny rule, the firewall still creates a session — but in state DISCARD. The dataplane drops the packet AND remembers the 6-tuple so subsequent packets get dropped at fastpath instead of slowpath (saving CPU). The DISCARD session keeps refreshing its timer as long as packets keep arriving. If a noisy app retries 50 times a minute, the DISCARD session lives forever.

② Hardware offload — why some sessions fly

PAN-OS uses Single Pass Parallel Processing (SP3). After App-ID + Content-ID finish on the first few packets of a session, the firewall can offload the rest of the flow to dedicated hardware (the FE-card or Flow Engine on PA-series). Offloaded flows skip the Dataplane entirely on subsequent packets. That's how a PA-5450 can do 100+ Gbps.

But offload has rules. If the firewall has to keep inspecting payload (decryption ON, threat-profile actively scanning, decompress), it CAN'T offload. Karthik at Flipkart hit 95% Dataplane CPU during a backup window — root cause was SSL decryption on a 12 Gbps flow preventing offload.

③ Predict sessions — how ALG opens pinholes without writing rules

Some protocols negotiate a data channel separately from the control channel. Active-mode FTP is the canonical example: client tells server "I'm listening on port 5099", server connects BACK to client:5099. The firewall can't know to allow port 5099 from a policy lookup — it has to PEEK at the FTP control channel, learn the dynamic port, and pre-install a predict session.

④ show session id <N> — every field decoded

The single most important troubleshooting command on the firewall. Run it on the session in question and it tells you everything. Below is annotated output for a real allowed HTTPS session.

show session id 84219

Session         84219            ← session-id (slot in hardware table)

        c2s flow:
                source:      10.10.10.5 [trust-lan]    ← original client (pre-NAT)
                dst:         142.250.182.46            ← original destination (pre-NAT)
                proto:       6                          ← TCP
                sport:       51234   dport:    443      ← original ports
                state:       ACTIVE  type:    FLOW
                src user:    rahul.tcs                  ← User-ID mapping
                dst user:    unknown

        s2c flow:
                source:      142.250.182.46 [untrust]
                dst:         203.0.113.5                ← post-NAT (firewall's public IP)
                proto:       6
                sport:       443     dport:    62117    ← post-NAT translated port
                state:       ACTIVE  type:    FLOW
                src user:    unknown
                dst user:    rahul.tcs

        start time              : Mon May 25 11:47:22 2026
        timeout                 : 3600 sec              ← idle timer
        time to live            : 1842 sec              ← seconds until ageout
        total byte count(c2s)   : 14,328                ← bytes client → server
        total byte count(s2c)   : 188,420               ← bytes server → client (healthy 2-way flow)
        layer7 packet count(c2s): 18
        layer7 packet count(s2c): 142
        vsys                    : vsys1
        application             : ssl                    ← App-ID identified
        rule                    : Allow-Web-Out          ← matched security rule
        session to be logged at end: True
        layer7 processing       : completed              ← App-ID done; eligible for offload
        URL category            : computer-and-internet-info
        session in session ager : True
        offloaded               : yes                    ← hardware offload active
        address/port translation: source                  ← Source NAT applied
        nat-rule                : SNAT-Outbound (vsys1)
        layer7 processing       : completed
        URL filtering           : disabled
        session synced from HA peer: False
        end-reason              : (live, no end yet)
        tracker stage l7proc    : appid-completed

Reading the output: healthy two-way byte counts, App-ID identified, offloaded, NAT applied as expected, matched the right rule. Time to live is 1842s of 3600s — half the timeout remaining. If you saw total byte count(s2c) = 0 with non-zero c2s, you'd immediately suspect a return-path issue (Blog 15 territory).

Debug flow basic — the deepest tool

When show session id isn't enough, drop into debug dataplane packet-diag set log feature flow basic. It writes detailed per-packet decisions to mp-log pan_packet_diag.log. Three stages of interest: slowpath (zone/route/policy/NAT lookup), firewall (session install + App-ID gating), forward (egress + ARP).

debug dataplane packet-diag set filter match source 10.10.10.5
debug dataplane packet-diag set filter on
debug dataplane packet-diag set log feature flow basic
debug dataplane packet-diag set log on

! ... reproduce the issue (one or two attempts) ...

debug dataplane packet-diag set log off
less mp-log pan_packet_diag.log