PAN-OS: Day in the life of a packet
Packet flow sequence in PAN-OS
October 2010
Palo Alto Networks
232 E. Java Dr.
Sunnyvale, CA 94089
408.738.7700
www.paloaltonetworks.com
Table of Contents
Overview ............................................................................................................................................ 3
Ingress Stage ..................................................................................................................................... 3
Packet Parsing................................................................................................................................ 5
Tunnel decapsulation ......................................................................................................................... 6
Flood and per-packet anomaly detection ....................................................................................... 8
TCP state check ............................................................................................................................. 8
Forwarding setup ............................................................................................................................ 8
Interface Mode ............................................................................................................................ 8
Forwarding action........................................................................................................................ 8
Tap .............................................................................................................................................. 8
Virtual Wire.................................................................................................................................. 8
Layer 2 ........................................................................................................................................ 8
Layer 3 ........................................................................................................................................ 8
NAT policy lookup........................................................................................................................... 9
User ID............................................................................................................................................ 9
Security policy lookup ..................................................................................................................... 9
Session allocation........................................................................................................................... 9
Firewall session fast path ................................................................................................................. 10
Application Identification................................................................................................................... 10
Summary .......................................................................................................................................... 11
2010 Palo Alto Networks Page 2
Overview
This document describes the packet handling sequence inside of PAN-OS device. The ingress and
forwarding/egress stages handles network functionalities to make packet forwarding decisions on
per packet basis. The rest of stages are flow-based security modules highlighted by App-ID and
Content-ID. This decoupling offers stateful security functions at application layer, and the resiliency
of per-packet forwarding, and flexibility of deployment topologies.
Security policies are always evaluated whenever there is an application change either from
unknown to a known one, or from a tunneling application to tunneled application.
Ingress Stage
Ingress stage receives packet from the network interface, parses the packet and determines
whether the given packet is subject to firewalling. If the packet is subject to firewalling then
continue with firewall session lookup and enter security processing stage, otherwise forward the
packet.
Note: During packet processing, a packet may be discarded because of protocol violation. In
certain cases which are considered firewall attack prevention features the packet maybe discarded
without configurable options because those packets will eventually be discarded by the end hosts.
2010 Palo Alto Networks Page 3
2010 Palo Alto Networks Page 4
Packet Parsing
Packet parsing starts with layer2 header of the packet received from interface,
Layer2: The ingress-port, 802.1q tag, destination MAC address is used as key to lookup ingress
logical interface. If interface is not found the packet is discarded. The hardware interface counter
"receive error" and global counter flow_rcv_dot1q_tag_err are incremented.
Layer3: The IP header is parsed.
IPv4: A packet can discarded 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
Maritain IP address
IPv6: A packet can discarded 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 than IP payload field),
JumboGram extension (RFC 2675),
truncated extension header
Layer 4:
TCP: The packet is discarded if
TCP header is truncated,
data-offset field is less than 5
Checksum error,
port zero
invalid combination of TCP flags
UDP: The packet is discarded if
UDP header truncated,
UDP payload truncated (not IP fragment, and
UDP buffer length less than UDP length field)
Checksum error
2010 Palo Alto Networks Page 5
Tunnel Decapsulation
Tunnel decapsulation/decryption is also performed at the parsing stage. After parsing, if the packet
is determined that it matches tunnel, i.e. IPSec, SSL-VPN with SSL transport, then the following
sequence is executed:
packet will be decapsulated first, discarded if any error,
the tunnel interface associated with the tunnel will be assigned to packet as new ingress
interface, then packet will be fed back to parsing process, starting with packet header
defined by tunnel type.
Currently all supported tunnel types are IP layer tunneling, thus packet parsing (for tunneled
packet) starts with IP header.
IP Defragmentation
IP fragments will be parsed, be reassembled by defragmentation process and fed back to the
parser starting with IP header. A fragment may be discarded due to tear-drop attack (overlapping
fragments).
Firewall Session Lookup
A packet is subject to firewall processing depending on the packet type and the interface mode.
The table below summarizes the packet processing behavior for a given interface operation mode
and packet type.
Interface Operational Mode
Virtual wires
Packet Layer3 Layer 2 IPv6- Tap
type Multicast
Default firewalling
firewalling on
on
IPv4 Inspect Inspect Inspect Inspect and Inspect and Inspect and
unicast and and and forward forward drop
forward forward forward
IP limited drop forward forward Inspect and forward drop
broadcast ( flood) forward
IP directed drop forward forward Inspect and forward drop
broadcast ( flood) forward
2010 Palo Alto Networks Page 6
Interface Operational Mode
Virtual wires
Packet Layer3 Layer 2 IPv6- Tap
type Multicast
Default firewalling
firewalling on
on
Martian drop drop drop drop drop drop
address
IPv6 drop forward forward Inspect if Inspect and drop
IPv6 forward
firewalling
is on
Non-IP process if forward forward forward forward drop
applicable
If the packet is subject to firewall inspection, flow lookup is performed on the packet. A firewall
session consists of two unidirectional flows each uniquely identified by 6-tuple key. In PAN-OS
implementation a flow is uniquely identified 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 field from protocols are used. For ICMP, ICMP identifier and
sequence numbers are used, for IPSec SPI is used to identify the flow and GRE call ID
is used for PPTP.
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.
Active flows are stored in the flow lookup table. When a packet is determined to be eligible for
firewall inspection, the 6-tuple flow key is extracted from the packet and flow lookup is performed to
match the packet with an existing flow. Each flow has a client and server component, where client
is sender of the first packet of the session from firewall perspective, and server is receiver of this
very first packet.
Note: The distinction of client and server is from the firewalls point of view and may or may not be
the same from the end hosts point of view.
Based on 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 contains same key as that of C2S flow,
and so on for S2C flow.
2010 Palo Alto Networks Page 7
Firewall Session Setup
The following steps are taken to setup a firewall session
Flood and per-packet anomaly detection
Once the packet arrives on a firewall interface, the ingress interface information is used to
determine the ingress zone. If there are any zone protection profiles configured for that zone, the
packet is subject to evaluation as configured in the zone protection profile.
TCP state check
For any first TCP packet that does not have SYN bit set will be discarded. If SYN flood settings are
configured in the zone protection profile, then TCP SYN cookie is triggered if the number of SYN
matches the activate threshold. SYN cookie implementation works as follows:
The seed to encode cookie is generated each time dataplane boots up via random number
generator
If an ACK packet received from the client does not match cookie encoding, it treats the
packet as non-SYN and discards the packet.
A session that passes SYN cookies process are subject to TCP sequence number
translation as firewall acted as proxy for TCP 3-way handshake.
Note:
I. The firewall can be configured to allow the first TCP packet even if it does not have
SYN bit set. Even though this is not a recommended setting, scenarios with
asymmetric flow will require this
II. It is recommended to have firewall set to reject TCP non-SYN when SYN cookies are
enabled.
Forwarding setup
This stage determines packet forwarding path. Packet forwarding depends on the way firewall
interface is configured. The table below summarizes packet forwarding behavior.
Interface Mode Forwarding action
Tap Egress interface/zone is the same ingress interface/zone. The packet is
discarded
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 interface
except the ingress interface in the VLAN
Layer 3 Route table lookup is used to determine the next hop
2010 Palo Alto Networks Page 8
NAT policy lookup
This is applicable only in layer 3 mode. At this stage the ingress and egress zone information is
available. NAT rules are applied to the original packet.
For destination NAT, a second route lookup for the translated address is performed to
determine the egress interface
For source NAT, the IP address is translated as the packet forwarded out via the egress
interface.
Note: For more information on NAT, refer to the document Understanding PAN-OS NAT.
User ID
If the user information is not available for the IP address, and the packet is destined to TCP/80, a
captive portal rule lookup is checked 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
Security policy lookup
At this stage the ingress and egress zone information is available. If the security policy action is to
allow the packet, the packet is forwarded out via egress interface. If the policy action is deny, the
packet is dropped. Any traffic that does not match a security rule is denied. Any intra zone traffic is
permitted by default.
Note:
Security rules are applied to the contents of the original packet, even there are NAT rules
configured
Port scan/ Address sweep protection
Port scan and address sweep protection is enforced if zone protection profile is configured on the
ingress zone
Session allocation
A new session entry from the free pool will be allocated once all of the above steps are
successfully completed. Session allocation failure may occur at this point due to resource
constraint
VSYS session maximum reached, or
All available sessions are allocated,
Once the session allocation is successful
Session content will be filled with flow keys extracted from packet and forwarding/policy
results
Session state changes from INIT (pre-allocation) to OPENING (post-allocation)
If the application has not identified, the session timeout value is set to default value of the
transport protocol
2010 Palo Alto Networks Page 9
Firewall session fast path
A packet that matches an existing session will enter the fast path. This stage starts with Layer2 to
layer4 firewall processing,
If the session is in discard state, then the packet will be discarded. A session can be
marked as discard state due to a policy action change to deny, or a threat detected.
If the session is active, refresh session timeout
If the packet is a TCP FIN/RST, the session timeout is changed to timeout-tcpwait value
If NAT is applicable, translate the L3/L4 header if applicable.
A packet matching an existing session is subject to layer7 processing if any of the following,
condition matches.
Packet has TCP/UDP data, or it is a non-TCP/UDP packet
If session application is not detected yet, application identification is performed.
A session that has application identified will be subject to content inspection, either
because of the application itself requires content inspection, if an ALG is involved,
application is tunneled application, or the security rule has security profile associated.
If a application uses TCP as transport, it will be processed by TCP reassembly module before
stream data is fed to layer7 module. TCP reassembly module will also perform window check,
buffer out-of-order data and skip TCP retransmission.
Application Identification (App-ID)
Application Identification consists of two cases:
a) Session application from undecided to defined one, and
b) From one defined application to another
Application-override policy lookup is done first to see if there is matched rule. If so we have an
application. If there is no application override rule, then application signature are used to identify
the application. Once the application is matched the destination IP/port/ and protocol that identifies
the application is stored into App-ID cache to speed up subsequent lookups if applicable. For
application changing from one to another, is done via protocol decoding in content inspection,
After session application is identified, 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 in
the session as keys to find rule match.
If security policy has logging enabled at session start, there will be a traffic log generated
If security policy has associated profile and/or application is subject to content inspection,
setup content inspection session
If security policy action is allow, perform QoS policy lookup and assign matched QoS class
If security policy action is allow application is SSL, perform SSL decryption policy lookup
and setup proxy contexts if there is decryption rule match
2010 Palo Alto Networks Page 10
Summary
Palo Alto Networks next-generation firewalls are based on a unique Single Pass Parallel
Processing (SP3) Architecture which enables high-throughput, low-latency network security, even
while incorporating unprecedented features and technology. Palo Alto Networks solves the
performance problems that plague todays security infrastructure with the SP3 architecture, which
combines two complementary components-Single Pass software, Parallel Processing hardware.
The results is the perfect mix of raw throughput, transaction processing and network security that
todays high performance networks require.
2010 Palo Alto Networks Page 11
