Packet Flow Sequence in PAN-OS

by jpa on ‎10-22-2010 11:27 AM - edited on ‎07-25-2018 02:08 AM by Community Manager (158,416 Views)

This document describes the packet handling sequence in PAN-OS.


Day in the  Life  of a  Packet
PAN-OS  Packet Flow Sequence.   Since PanOS 7.0.2 and 6.1.7 (PAN-48644), dos protection lookup is done prior to security policy lookup.  This DOC was updated to reflect this change in behaviour.




  • 3.3.   TCP STATE CHECK
  • 3.6.    USER- ID



Section 1:  Overview

This document describes the packet handling  sequence inside of PAN-OS devices . The ingress and forwarding/egress stages handle network functions  and make packet - forwarding decisions on a  per-packet basis. The remaining stages are  session-based security modules highlighted by App-ID and Content-ID. This decoupling offers stateful security functions at the application layer, and the resiliency of per-packet forwarding and flexibility of deployment topologies. 

Section 2:  Ingress Stage

The  ingress stage receives packets from the network interface, parses those   packets,  and then determines whether  a   given packet is subject to further inspection . If the  packet is subject to  further  inspection, the  firewall continues with a  session lookup and  the  packet enters the security processing stage. Otherwise, the firewall forwards the packet to the egress stage.  Section 3 summarizes cases when the firewall forwards packets without inspection, depending on  the  packet type and the  operational mode of the interface.

Note : During packet processing,  the firewall may discard a packet because of a protocol violation. In certain cases,  due to firewall attack prevention features,  it discards packets  without configurable options.   Section 2.1 enumerates  such  cases when  the firewall discards packets  at this stage .

2.1   Packet  Parsing

Packet parsing starts with  the Ethernet (Layer-2)   header of the packet received from  the wire.
The ingress  port, 802.1q tag,  and  destination MAC address  are used as keys to lookup the ingress logical interface. If  the interface is not found, the packet is discarded. The hardware interface counter "receive error" and global counter  “flow_rcv_dot1q_tag_err” are incremented. 

Next, the IP header is parsed (Layer-3) . 
IPv4:  The firewall will discard the packet for any one of the following reasons :  
  • Mismatch of Ethernet type and IP version 
  • Truncated IP header 
  • IP protocol number 0 
  • TTL zero 
  • Land attack 
  • Ping of death 
  • Martian IP address 
  • IP checksum errors
IPv6 :  The firewall will discard the packet for any one of the following reasons :  
  • Mismatch of Ethernet type and IP version
  • Truncated IPv6 header 
  • Truncated IP packet (IP payload buffer length less t han IP payload field) 
  • JumboGram  extension (RFC 2675)
  • Truncated extension header
Next,  the Layer-4 (TCP/UDP) header is parsed, if  applicable .
TCP:  The firewall will discard the packet for any one of the following reasons :
  • TCP header is truncated.
  • Data - offset field is less than 5 
  • Checksum error
  • Port  is  zero 
  • Invalid combination of TCP flags 
UDP:  The firewall will discard the packet for any one of the following reasons :  
  • UDP header truncated 
  • UDP payload truncated (not IP fragment and  UDP buffer length less than  UDP length field)
  • Checksum error

2.2   Tunnel Decapsulation

The firewall performs  decapsulation/decryption at the  parsing stage. After parsing the packet, if  the firewall determines   that it matches a tunnel, i.e. IPSec, SSL-VPN with SSL transport, then it performs the following sequence:
  • The firewall decapsulates the packet first and discards it if errors exist.
  • The tunnel interface associated with the tunnel is assigned to the packet as its new ingress interface and then the  packet is fed back through the parsing process, starting with the packet header defined by the tunnel type. Currently,  the supported tunnel types are IP layer tunneling, thus packet parsing (for a tunneled packet) starts with the IP header.

2.3   IP Defragmentation

The firewall parses IP fragments, reassembles using the defragmentation process,  and then feeds the packet back to the parser starting with the IP header.  At this stage, a fragment may be discarded due to tear-drop attack (overlapping fragments), fragmentation errors, or if the firewall  hits system limits on buffered fragments (hits the max packet threshold) .

Section  3 Firewall Session Lookup

A packet is subject to firewall processing depending on the packet type and the interface mode. The  following  table summarizes the packet processing behavior for a given interface  operation mode and packet type:
Packet Type Interface operational modes
Layer-3 Layer-2 Virtual-Wire Tap
IPv4 unicast   inspect & forward   inspect & forward   inspect & forward inspect & drop

IPv4 Multicast

( -

    inspect & forward forward only (flood)  

forward, but inspect only if multicast 

firewalling is on

inspect & drop

IP broadcast


drop forward only (flood)

forward, but inspect only if multicast 

firewalling is on

IP local broadcast drop forward only (flood)

forward, but inspect only if multicast 

firewalling is on


inspect and forward   if enabled

forward, but inspect only if IPv6  firewalling is on  (default)

forward, but inspect only if IPv6  firewalling is on (default) drop, but inspect only if IPv6  firewalling is on  (default)
Non-IP process if applicable,  not forward forward only   forward only   drop
If the packet is subject to firewall inspection, it performs a flow lookup on the packet. A  firewall session consists of two unidirectional flows, each uniquely identified. In  PAN-OS ’s   implementation, the firewall identifies the flow using a 6-tuple key :
  • Source and destination addresses : IP addresses from the IP packet. 
  • Source and destination ports:  Port numbers from TCP/UDP protocol headers.  For non-TCP/UDP, different  protocol  fields are used (e.g. for ICMP the ICMP identifier and sequence numbers are used, for IPSec terminating on device the Security Parameter Index (SPI) is used, and for unknown, a constant reserved value is used to skip Layer-4 match).
  • Protocol:  The IP protocol number from the IP header is used to derive the flow  key .  
  • Security zone:  This field is derived from the ingress interface at which a packet  arrives.
The firewall stores active flows in the flow lookup table. When a packet is determined to be eligible for firewall inspection, the firewall extracts the  6-tuple flow key from the packet and then performs a flow lookup to match the packet with an existing flow. Each flow has a client and server component, where the client is  the sender of the first  packet of the session from firewall’s perspective, and the server is the receiver of this first packet. 
Note:  The distinction of client and server is from the firewall’s point of view and may or may not be the same from the end hosts’ point of view.  Based on the above definition of client and server, there will be a client-to-server (C2S)  and server-to-client (S2C) flow, where all client-to-server packets should contain the same key as that of the C2S flow, and so on for  the  S2C flow.

3.1   Firewall Session Setup

The  firewall performs the following steps to set up a firewall session :

3.2.   Zone Protection Checks

After the packet arrives on a firewall interface, the ingress interface information is used to determine the ingress zone. If  any zone protection profiles exist for that zone, the packet is subject to evaluation based on the profile configuration.

3.3.   TCP State Check

If the first packet in a session is a TCP packet and it does not have the SYN bit set, the firewall discards it (default).  If SYN flood settings are configured in the zone protection profile and action is set to SYN Cookies, then TCP SYN cookie is triggered if the number of SYN matches the activate threshold. SYN cookie implementation functions as follows: 
  • The seed to encode the cookie is generated via random number generator each time the data plane boots up.
  • If an ACK packet received from the client does not match cookie encoding,  it treats the packet as non-SYN packet .
  • A session that passes SYN cookie’s process is subject to TCP sequence number translation because the firewall acted as a proxy for TCP 3-way handshake. 
If the SYN Flood protection action is set to Random Early Drop (RED) instead, which  is the default, then the firewall simply drops any SYN messages that are received  after hitting the threshold. SYN Cookies is preferred when you want to permit more  legitimate traffic to pass through while being able to distinguish SYN flood packets and drop those instead. RED, on the other hand, will drop SYN packets randomly and can impact legitimate traffic equally.
Note:  You can configure the firewall to allow the first TCP packet, even if it does not have SYN bit set.  Altering the default behavior and allowing non-SYN TCP packets through poses a security risk by opening up the Firewall to malicious packets not part of a valid TCP connection sequence. Although this is not a recommended setting,  it might be required for  scenarios with asymmetric flows.   You should configure the firewall to reject TCP non-SYN when SYN cookies are  enabled.

3.4.   Forwarding Setup

This stage determines the  packet-forwarding path. Packet forwarding depends on the configuration of the interface . The  following table summarizes the packet-forwarding behavior:
Interface Mode
Forwarding action
Tap Egress interface/zone is the same as the ingress interface/zone from a policy perspective. The firewall discards the packet.
Virtual Wire Egress interface is the peer interface configured in the virtual wire
Layer - 2
Egress interface for the destination MAC is retrieved from the MAC table. If the information is not present, the frame is flooded to all interfaces in the associated VLAN broadcast domain, except for the ingress interface .
Layer - 3 The firewall uses the route lookup table to determine the next hop, or discards the packet if there is no match.

3.5.   NAT Policy Lookup

This is applicable only  in Layer-3 or Virtual Wire mode. At this stage, the ingress and egress zone information is available.  The firewall evaluates NAT rules for the original packet. 
  • For destination NAT,  the firewall performs a second route lookup for the translated address to determine the egress interface/zone.  
  • For source NAT,  the firewall evaluates the NAT rule for source IP allocation. If the allocation check fails, the firewall discards the packet.


3.6.   User-ID

The firewall uses the IP address of the packet to query the User-IP mapping table (maintained per VSYS) . The corresponding user information is fetched. The firewall next takes this user information to query the user-group mapping table and fetches the group mapping associated with this user (it returns all groups the user belongs to).
There is a chance that user information is not available at this point. In that case, if captive portal policy is setup, the firewall will attempt to find out  the user information via captive portal  authentication ( discussed in Section 4) .

3.7.   DoS Protection Policy Lookup

Next, the firewall checks the DoS (Denial of Service) protection  policy  for traffic thresholds based on the DoS protection profile.  If the DoS protection policy action is set to “Protect”, the firewall checks the specified thresholds and if there is a match (DoS attack detected), it discards the packet. 
If the policy action is either allow or deny, the action takes precedence regardless of threshold limits set in the DoS profile. 

3.8.   Security Policy Lookup

At this stage, the ingress and egress zone information is available.  The firewall uses application ANY to perform the lookup and check for a rule match.  In case of a rule  match, if the policy action is  set to ‘deny’, the firewall drops the packet.  The firewall denies the traffic if there is no security rule match.   The firewall permits intra-zone traffic by default.   You can modify this default behavior for intra-zone and inter-zone traffic from the security policies rulebase.  
Note :  The firewall applies security rules to the contents of the original packet, even if there are NAT rules configured .    

3.9.   Session Allocation

The firewall allocates a new session entry from the free pool after all of the above steps are successfully completed. Session allocation failure may occur at this point due to resource constraints:
  • VSYS session maximum reached, or 
  • The firewall allocates all available sessions.
After the session allocation is  successful :  
  • The firewall fills session content with flow keys extracted from the packet and the forwarding/policy results .  
  • Session state changes from INIT (pre-allocation) to OPENING (post-allocation) .  
  • If the application has not been identified, the session timeout values are set to default value of the transport protocol. You can configure these global timeout values from the Firewall’s device settings.  Application specific timeout values override the global settings, and will be the effective timeout values for the session once application is identified .    
After setup, session installation takes place :
  • Firewall queries the flow lookup table to see if a match exists for the flow keys matching the session.  If a flow lookup match is found (session with same tuple already exists), then this session instance is discarded as session already exists, else
  • Session is added to the flow lookup table for both C2S and S2C flows and firewall changes the session’s state from  OPENING to ACTIVE .
The firewall then sends the packet into Session Fast Path phase for security processing.

Section 4 :  Firewall Session Fast Path

A packet that matches an existing session will enter the fast path. This stage starts with  Layer-2 to Layer-4 firewall processing:  
  • If the session is in discard state, then the firewall discards the packet.  The firewall can mark a session as being in the  discard state due to a policy action change to deny, or threat detection . 
  • If the session is active, refresh session timeout .  
  • If the packet is a TCP FIN/RST, the session TCP half closed timer is started if  this is the first FIN packet received (half closed session) or the TCP Time Wait  timer is started if this is the second FIN packet or RST packet.  The session is  closed as soon as either of these timers expire.
  • If NAT is applicable, translate the L3/L4 header as applicable. 
If an application uses TCP as the transport, the firewall processes it by the TCP  reassembly module before it sends the data stream into the  security-processing module. The TCP reassembly module will also perform window check, buffer out-of-order data while skipping TCP retransmission. The firewall drops the packets if there is a reassembly error or if it receives too many out-of-order fragments, resulting in the reassembly buffers filling up.

4.1.  Security Processing

A packet matching an existing session is subject to further processing (application identification and/or content inspection) if  packet has TCP/UDP data (payload), or it is a non-TCP/UDP packet .  
If the firewall does not detect the session application, it performs an App-ID lookup. If  App-ID lookup is non-conclusive, the content inspection module runs known protocol decoder checks and heuristics to help identify the application.  
If the firewall detects the application, the session is subject to content inspection if any of the following apply:
  • Application Layer Gateway (ALG) is involved .
  • Application is tunneled application .
  • Security rule has security profile associated. 

4.2.  Captive Portal

If the user information wa s not available for the source IP address extracted from the packet, and the packet is destined to TCP/80, the firewall performs a captive portal rule lookup to see if the packet is subject to captive portal authentication. If captive portal is applicable, the packet is redirected to the captive portal daemon. 
Note:  Since captive portal is applicable to http traffic  and also supports a URL category based policy lookup, this can be   kicked in only  after the TCP handshake is completed and the http host headers are available in the session exchange.

Section 5 Application Identification (App-ID)

The firewall first performs an application-override policy lookup to see if there is a rule match. If there is, the application is known and content inspection is skipped for this session .  
If there is no application-override rule, then application signatures are used to identify the application.  The firewall uses protocol decoding in the content inspection stage to determine if an application changes from one application to another .
After the firewall identifies the session application, access control, content inspection, traffic management and logging will be setup as configured. 
  • Security policy lookup: The identified application as well as IP/port/protocol/zone/user/URL category in the session is used as key to find rule match. 
  • If the security policy has logging enabled at session start,  the firewall generates a traffic log, each time the App-ID changes throughout the life of the session.  
  • If security policy action is set to allow and it has associated profile and/or application is subject to content inspection,  then it passes all content through Content-ID .  
  • If security policy action is set to allow, the firewall performs a QoS policy lookup and assigns a QoS class based on the matching policy .  
  • If security policy action is set to allow and the application is SSL or SSH, perform a decryption policy lookup and set   up proxy contexts if there is a matching decryption rule .

Section 6 : Content Inspection  

The firewall performs content Inspection, if applicable,  where protocol decoders’ decode the flow and the firewall parses and identifies known tunneling applications  (those that routinely carry other applications like web-browsing).
If the identified application changes due to this, the firewall consults the security policies once again to determine if the session should be permitted to continue .
If the application does not change, the firewall inspects the content as per all the security profiles attached to the original matching rule. If it results in threat detection, then the corresponding security profile action is taken. 
The firewall forwards the packet to the forwarding stage if one of the conditions hold true:
  • If inspection results in a ‘detection’ and security profile action is set to allow, or  
  • Content inspection returns no ‘detection’.
The firewall then re-encrypts the packet before entering the forwarding stage, if applicable (SSL forward proxy decryption and SSH decryption).

Section 7 : Forwarding/Egress

The firewall identifies a forwarding domain for the packet, based on the forwarding setup (discussed earlier). 
The firewall performs QoS shaping as applicable in the egress process. Also, based on the MTU of the egress interface and the fragment bit settings on the packet, the firewall carries out fragmentation if needed.
If the egress interface is a tunnel interface, then IPSec/SSL-VPN tunnel encryption is performed and packet forwarding is reevaluated.
Finally the packet is transmitted out of the physical egress interface.

Section 8 Summary

Palo Alto Networks next-generation firewalls use a unique Single Pass Parallel Processing (SP3) Architecture – which enables high-throughput, low-latency network security, all while incorporating unprecedented features and technology. Palo Alto Networks solves the performance problems that plague today’s  security infrastructure with the SP3 architecture, which combines two complementary components - Single Pass software, Parallel Processing hardware. The result is an excellent mix of raw throughput, transaction processing, and network security that today’s high performance networks require.
by blacksan
on ‎10-22-2010 12:22 PM

Amazing Document.   Can't wait to see the other flows from a network layer like QoS, Zone Protection (mention), Routing and when the Captive Portal kicks in when the User-ID is not available.

by sunilsadanandan
on ‎08-02-2011 07:42 AM

The document mentions the following:

"A session that has application identified will be subject to content inspection, either
because of the application itself requires content inspection"

Could provide an example of an Application that requires content inspection ?

"Any intra zone traffic is permitted by default"

I had multiple L3 subinterfaces (representing different internal networks) linked to an Internal zone. Does that mean the firewall would by defualt allow traffic between these networks associated with the Internal zone without a rule specifically saying allow traffic from Internal to Internal zone?

by migration
on ‎08-02-2011 11:16 AM


1. Application flow requires content inspection for example when the app is changing from one to another (i.e webex conferece -> webex desktop sharing), because this process is done via protocol decoding in content inspection. In general, every application that require "protocol decoding" to be identified needs content inspection. Remember that PAN use foure different technologies to identify the apps: SSL Decryption, Protocol Decoder, Application Signature, Heuristics.

2. Yes, any intra-zone traffic will be permitted by default, even through different subinterfaces if this are configured under the same zone.

by dos_2_II
on ‎10-28-2011 09:11 PM

if the intra-zone traffic also need consume the session number?

by mikand
on ‎02-27-2013 01:47 AM

The App-ID Tech Brief over at also contains a workflow which is handy to describe what happens to a packet when it arrived to a PA-box.

by nextgenhappiness
on ‎05-23-2013 07:30 PM

The document shows IPv6 in Layer 3 mode will get drop (Page 7).   Is that still true in PAN-OS 5.0?   Please update the document.

by dhshah
on ‎06-15-2015 12:00 PM

Document has been updated based on v6.1

by Harald.Norvik
on ‎01-25-2016 11:02 AM

Section 2.1 Packet parsing states:

"The ingress port, 802.1q tag, and destination MAC address are used as keys to lookup the ingress logical interface." 

How do you use the destination MAC address to determine the ingress interface? 


IP header parsing

IPv4: Martian IP address - should be useful if you could specify which ranges are dropped. 

Of course you cannot drop RFC1918 addresses, but what about the rest? Will the TEST ranges be dropped so we cannot use this in the lab setup? See

by nextgenhappiness
on ‎06-26-2016 07:50 AM

Any changes apply since PANOS 7.1?  If so, please update the doc

on ‎04-07-2017 03:07 PM

Is this still accurate for PANOS 8.0.1 ?

by Community Manager
on ‎04-10-2017 01:58 AM

yes, this is still  accurate for PAN-OS 8.0

by sunright
on ‎05-18-2017 11:38 PM


Since PanOS 7.0.2,6.1.7(PAN-48644), dos protection lookup is done prior to security policy lookup.

The doc needs to be updated sometime soon.

by smisra
‎08-14-2017 01:38 PM - edited ‎08-14-2017 01:38 PM



For TAP Mode Interface Type and IPv4/IPv6 Multicast packet type, Action = DROP. Firewall doesn't inpect the multicast packets in tap mode.


by Xtreme
on ‎08-24-2017 05:21 AM

When the session is allocated, and flow lookup table for both C2S and S2C are being filled with session info, the information will be based on pre-Nat information (original packet data), and not the translated packet info ?

by Community Manager
on ‎08-24-2017 08:02 AM

the c2s flow will contain the pre-nat IPs and the c2s flow will contain the post-nat IPs as you can see in this session output :


> show session id 24868

Session           24868

        c2s flow:
                source: [v1-trust]  <- pre-NAT source
                proto:       17
                sport:       61075           dport:      53
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        s2c flow:
                source: [v1-untrust]
                dst:   <- post-NAT source
                proto:       17
                sport:       53              dport:      29142
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

by BoardwareITSupport
on ‎09-07-2017 09:34 PM

Hello,Could you have a big-size diagram,the diagram too small to understand this flow sequence.

by DarinSutton
‎12-05-2017 04:17 PM - edited ‎12-05-2017 04:35 PM

***sorry this IS A Different Document than what we had in the past****


document has been updated and modified ... ~ early 2017

with corrected flow / NAT(earlier) / ZP (early on)....etc

newer picture has been added (lower resolution)


we need a new flow chart - in high res - so we can read it when enlarged

by Community Manager
on ‎12-06-2017 07:01 AM

Hi @DarinSutton

I increased the resolution on the flow chart

by lthompson
on ‎12-19-2017 05:55 PM

I don't see the Zone Protection in the flow chart, this would be good to add.  Also, it reads like there are some points missing from the text in Section 3.1: Firewall Session Setup.


My understanding is that if security policy denies a packet it is not counted for the zone protection thresholds.  I think it would be more useful to count denies, so that visibility of scan activity can be gained.

by jyates
on ‎01-09-2018 11:55 AM

Can we add PBF to the logic here? At least, I can't seem to find it when searching for it.

by emr_
on ‎03-06-2018 09:01 PM

Could you add when 'Hardware IP Address Blocking' works in the chart?

Hope this feature will work in Ingress stage, though since this diagram is based on PAN-OS 7.0, new feature added on PAN-OS 8.0 is not covered.


by petersetlak
on ‎04-24-2018 10:03 AM

Concerning Martian IP Addresses:


How does the Palo Alto know what Interface is connected to the Internet to know what interface they should drop these types of packets on? On that interface, are RFC-1918's being blocked also? On the non-Internet interfaces, are other martian IP's blocked (and not RFC-1918's)?

by Community Manager
on ‎04-25-2018 12:15 AM

Hi @petersetlak


We do not discriminate agains IP addresses in the sense that you are capable of routing these in the firewall's default stance (all IPs are equal)

If you want to block martians and bogons, you will need to create security policy to do so. 

by BobW
on ‎05-29-2018 04:12 PM

I am curious if there will be an updated PDF of this document,




by ms.jzam
on ‎07-23-2018 02:07 PM - last edited on ‎07-25-2018 02:02 AM by Community Manager

For anyone looking for a high resolution downloadable image of the diagram.


by DarinSutton
‎07-24-2018 09:14 AM - edited ‎07-24-2018 10:42 AM

please relink diagram - it is blocked or inaccessible 


thanx in advance









just get an x


whether logged in as partner or not

on ‎07-24-2018 10:12 AM

@DarinSutton, We have checked the diagram in Section 2, and it is fine with us. What browser are you using? Are you on a Tablet/phone/computer?


Also ms.jzam posted a link to the diagram above in high res if you needed it.

by lthompson
on ‎07-24-2018 06:15 PM - last edited on ‎07-25-2018 02:03 AM by Community Manager

The href for the high res image has a couple of extra unicode characters tacked onto the end.  if you remove these or copy paste the link text it is fine.






by JamesRen
3 weeks ago

Dear reaper,


Could you please explain at which stage RPF check is implemented? What would the firewall do if ECMP is enabled, but the traffic is received on an interface which is currently not the active one on the Forwarding Information Table?





by PatrickDeJong
2 weeks ago

Additional info from Philip Kwan with regards to routing decision FIB/PBR:

"It’s a very simple operation just before we forward the packet.  Once the external zone is identified and after the packet goes through the security engines, a decision is made to use the PBR rule or to use the FIB table’s entry.  If PBR is setup and a match is made, the PBR will be executed and the FIB lookup bypassed.  PBR always takes precedence over the FIB if the match is made."


by JamesRen
2 weeks ago

Dear Patrick,


I think you mis-read my question.


Please see a scenario below. ECMP is enabled for default route out of the two interfaces, eth1/1 and eth1/2. The destination NAT only works for the link that is in the top line of the FIB. The other link actually fails. The only possible explanation to this is RPF, but this has not been documented anywhere.


by PatrickDeJong
2 weeks ago

Hi James,


Actually my response was more an answer to the question upwards in the thread;

"Can we add PBF to the logic here? At least, I can't seem to find it when searching for it."


Adding on that furhter;

There is btw one caveat when you consider a multi-vsys and multi-vr environment. Looking at the flow debugging when a packet enters it’s first VSYS the firewall does a PBF/route lookup in the current VSYS and virtual router. If the next-hop in the VR is a next VR it will also do a route lookup in the next VR, but it will not evaluate the PBF rule in the next VSYS of that VR.

Ignite 2018, Amsterdam, Netherlands
Ask Questions Get Answers Join the Live Community