PAN-OS is a session factory. Stamps, then Session Browser.

1. Why allow is not a session

Every other blog starts with App-ID, User-ID and Content-ID as three marketing boxes. That is why students freeze in interviews. The real object is the session. Features are only stamps the factory puts on a ticket before it lets two directions talk.

Official session overview: a PAN-OS session is two uni-directional flows, each keyed by a 6-tuple — source address, destination address, source port, destination port, protocol, and security zone. Same IPs in a different zone pair are a different factory job. The first flow is c2s (client to server). The return is s2c (server to client). Security policy is written in the c2s direction. The return does not need a second allow.

Hero · the factory floor

2. Mental model — ticket plus three stamps

Hold three parts. Interviews fail when people mix them.

Visual · three stamps on one ticket

App-ID answers “what conversation is this?” — not the port. Official: when you allow traffic, App-ID begins to classify without extra config. Port is the first guess. After a few packets the name can change from incomplete or ssl to salesforce-base.

User-ID answers “whose badge is on this IP right now?” Official packet-flow: the firewall queries the User-IP mapping table (per VSYS) with the packet source IP, then the user-group mapping table. Shared NAT, a stale AD mapping, and a laptop that moved desks will lie to you.

Content-ID answers “is the payload sick, leaking, or in a bad URL category?” Official packet-flow Section 6: it runs after the session is allowed and a profile / ALG / tunneled app applies. Decrypt is taking the envelope off so Content-ID can read. No profile on the allow = no stamp.

3. First-packet setup vs fast path

The first packet of a new 6-tuple has no session yet. It walks session setup — Palo Alto also calls this the slow path. Later packets of the same 6-tuple skip that queue and ride the session. That is why “I added a rule” sometimes does nothing until the old session dies.

Path · first packet vs fast path

4. How to choose the stamps

You are not choosing a product. You are choosing what the factory is allowed to write on the ticket.

application-default is a port contract, not a vibe. Official wording: it permits the standards-based port for the application. DNS matches only on TCP/UDP 53. Source: Safely Enable Applications on Default Ports / Security Policy Rules.

5. Runbook Side A → B → C

Lab values only. Hostname PA-VM-LAB, serial LAB-PA-0001, user example\finance.user, client 192.0.2.25, SaaS 198.51.100.44, PAT 203.0.113.10. Nothing here is a live tenant.

Side A — zones and the virtual router (building the factory floor)

Primary source: PAN-OS Admin · Network > Interfaces / Zones / Virtual Routers.

1. Put interfaces in the right zones

   Network → Interfaces. ethernet1/2 = L3, zone trust, VR default. ethernet1/1 = L3, zone untrust, VR default. Same IPs in the wrong zone are a different 6-tuple.

2. Create the zones

   Network → Zones. Type = Layer3. Enable User-ID on trust only if you will stamp identity. Do not enable User-ID on untrust as a reflex.

3. Give the default VR a way out

   Network → Virtual Routers → default. Static default 0.0.0.0/0 next hop 198.51.100.1 out ethernet1/1. Dest zone for internet is the zone that owns that egress interface.

Side B — NAT then security policy (printing the ticket, choosing stamps)

Primary source: NAT Policy Rules + Security Policy Rules. Remember: policy uses pre-NAT addresses and post-NAT zones. Translation happens on egress.

1. Write outbound DIPP first

   Policies → NAT → Add. Name nat-outbound. Original Packet: Source Zone trust, Destination Zone untrust, Destination Interface ethernet1/1, Source Address 192.0.2.0/24. Translated Packet: Source Translation = Dynamic IP and Port, Interface Address, interface ethernet1/1. NAT rules are most-specific first. Source: NAT Policy Rules.

2. Write the security rule under that NAT

   Use the mock above. Put finance-saas above any catch-all ssl allow. Security rules evaluate top to bottom, first match wins. Default interzone is deny. Source: Security Policy Rules.

3. Attach a profile group on allow

   Security profiles evaluate only on Allow. That is the Content-ID stamp. Decrypt is a separate rulebase — do not “decrypt everything off” to make one mobile app happy.

4. Commit, then do not celebrate

   A green commit means the recipe printed. It does not mean Salesforce answered. Side C is the proof.

admin@PA-VM> test security-policy-match from trust to untrust source 192.0.2.25 destination 198.51.100.44 destination-port 443 protocol 6 application ssl
"finance-saas" {
        from trust;
        source 192.0.2.0/24;
        source-user any;
        to untrust;
        destination 198.51.100.0/24;
        application ssl;
        service application-default;
        action allow;
        log-start no;
        log-end yes;
}

Say the word predicted. This command is a what-if. The live session may show a different rule after App-ID shifts. Compare it to Session Browser and show session id in Side C.

Side C — prove the two-way session in Session Browser

Primary source: Monitor → Session Browser (PAN-OS 11.1 help) + Palo Alto Networks Firewall Session Overview (show session id).

1. Baseline the box

   show system info — hostname PA-VM-LAB, serial LAB-PA-0001, sw-version, operational-mode normal. Half of “it doesn’t match the doc” is a different PAN-OS train. Half of empty session tables is the passive unit.

2. Click Salesforce, then open the live table

   Monitor → Session Browser. Official wording: browse and filter current running sessions. This is not the Traffic log. Filter source 192.0.2.25 and dest port 443.

3. Read the stamps on the row

   You need state ACTIVE, type FLOW, application that left incomplete, a non-zero receive / s2c byte count, src-user matching finance, rule finance-saas. Copy the Session ID for CLI.

4. If s2c is 0, do not add a rule

   Check NAT / DIPP, return route, ARP, and the server SYN-ACK. That is the evidence desk, not a missing allow.

Proof · Session Browser cockpit

admin@PA-VM> show session id 48219
Session          48219

        c2s flow:
                source:      192.0.2.25 [trust]
                dst:         198.51.100.44
                proto:       6
                sport:       53122          dport:      443
                state:       ACTIVE         type:       FLOW
                src-user:    example\finance.user

        s2c flow:
                source:      198.51.100.44 [untrust]
                dst:         203.0.113.10
                sport:       443            dport:      18422

        start-time                  : 08/15 10:42:18
        timeout                     : 3600 sec
        total byte count(c2s)       : 2844
        total byte count(s2c)       : 0
        application                 : ssl
        rule                        : finance-saas
        service                     : application-default
        action                      : allow
        session end reason          : aged-out

6. Runtime — App-ID shift, decrypt, old slots

After the slot exists, later packets skip the setup queue. Official fast path: if the session is DISCARD, drop; if ACTIVE, refresh timeout; apply NAT on the L3/L4 header; TCP reassembly; then security processing.

If the application is not yet known, App-ID runs (override policy first, then signatures, then decoders / heuristics). After the app is named, the firewall looks up security policy again with the full key — application, IP, port, protocol, zone, user, URL category. If logging at session start is on, a Traffic log can fire each time App-ID changes. Source: Packet Flow Sequence, Section 5.

Content-ID then inspects if a profile is attached, or an ALG / tunneled app is involved. If the inner application changes (web-browsing inside ssl), policy is consulted again. Decrypt is a second walk through the same factory: terminate TLS when policy and law say so, stamp a real application, run Content-ID, re-encrypt. Certificate-pinned mobile apps will scream. That is the app refusing a substitute certificate — not a broken firewall. Bypass those hosts on purpose, with an owner and an expiry.

HA is two copies of the factory. Active/passive means one factory is printing tickets and the other holds a copy of the book. Green HA state means the book is synced. It does not mean Salesforce recovered in three seconds. Prove that with the same business click. Session Overview: session synced from HA peer True means the slot was born on the other unit.

7. Traps + Session Browser proof

Related: Session table — setup vs fast path, field by field · The evidence desk · Security policy fundamentals · Allow is not protect · Palo Alto hub

Sources

• Packet Flow Sequence in PAN-OS — ingress, session lookup, setup (zone / TCP / forward / NAT / User-ID / DoS / policy ANY / allocate), fast path, App-ID, Content-ID, egress
• Palo Alto Networks Firewall Session Overview — 6-tuple, c2s/s2c, FLOW vs PREDICT, INIT / ACTIVE / DISCARD, show session id
• Monitor → Session Browser — browse and filter current running sessions
• NAT Policy Rules — pre-NAT addresses, post-NAT zones, translation on egress
• Security Policy Rules — top-down first match, required fields, application-default
• App-ID — classify after you allow; content updates carry new App-IDs
• User-ID Overview — identity vs IP on the wire
• Why traffic may not match the expected rule after App-ID / URL — initial 6-tuple lookup, then full match

Related: PAN-OS session table — setup vs fast path · The PAN-OS evidence desk · Security policy fundamentals · Security profiles — allow is not protect · SP3 architecture · Palo Alto firewall hub