Secure Packet Flow

(PAN-OS)

{ Prepared By
Shaikat Ahmed
PCNSE, CCNA, JNCIA, NSE
Admin-Cloud Infrastructure & Network Security
Packet Flow Sequence in PAN-OS

INGRESS STAGE

 PACKET PARSING

 TUNNEL DECAPSULATION

 IP DEFRAGMENTATION
Packet Processing State
FIREWALL SESSION LOOKUP

 ZONE PROTECTION CHECKS

 TCP STATE CHECK
 FORWARDING SETUP
 NAT POLICY LOOKUP
 USER-ID
 DOS PROTECTION POLICY LOOKUP
 SECURITY POLICY LOOKUP
 SESSION ALLOCATION
Packet Processing State [Cont.]
FIREWALL SESSION FAST PATH

 SECURITY PROCESSING
 CAPTIVE PORTAL

APPLICATION IDENTIFICATION (APP-ID)

CONTENT INSPECTION
FORWARDING [EGRESS]
 Identifies a forwarding domain for the packet
 Performs QoS shaping
 Firewall carries out fragmentation based on
MTU
 IPSec/SSL-VPN tunnel encryption is performed
and packet forwarding is reevaluated if the
egress interface is tunnel interface.
 Finally the packet is transmitted out of the
physical egress interface
Interested for more?? Let’s dive
into deep ocean of packets
Ingress State [Flow Debugging]
 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.
Ingress State [Packet Parsing]
L2 Header 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.
Packet Parsing (Cont.) – L3 Header
IPv4 [Matching Criteria - IPv4 [Matching Criteria -
Discard] Discard]
 Mismatch of Ethernet  Mismatch of Ethernet
type and IP version type and IP version
 Truncated IP header  Truncated IPv6 header

 IP protocol number 0  Truncated IP packet (IP

 TTL zero payload buffer length less

 Land attack
than IP payload field)
 Jumbo Gram extension
 Ping of death
(RFC 2675)
 Martian IP address
 Truncated extension
 IP checksum errors
header
Packet Parsing (Cont.) – L4 Header
TCP [Matching Criteria - UDP [Matching Criteria -
Discard] Discard]

 TCP header is truncated.  UDP header truncated

 Data - offset field is less  UDP payload truncated
than 5 (not IP fragment
 Checksum error and UDP buffer length
 Port is zero less than UDP length
field)
 Invalid combination of
TCP flags  Checksum error
Ingress State [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
 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.
Ingress State [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).
Processing State[FIREWALL SESSION
LOOKUP]
A packet is subject to firewall processing depending on the
packet type and the interface mode.
 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).
Firewall Session Lookup
[Cont.]
 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.
 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.
 Interface operational modes
Packet Type
Layer-3 Layer-2 Virtual-Wire Tap

IPv4 unicast inspect & forward inspect & forward inspect & forward inspect & drop

IPv4 Multicast forward, but inspect

inspect & forward forward only (flood) only if multicast inspect & drop
(224.0.0.1 -
239.255.255.255) firewalling is on

forward, but inspect

IP broadcast
drop forward only (flood) only if multicast drop
(255.255.255.255) firewalling is on

forward, but inspect

only if multicast
IP local broadcast drop forward only (flood) drop
firewalling is on

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

process if applicable, not

Non-IP forward only forward only drop
forward
FIREWALL SESSION SETUP
 ZONE PROTECTION CHECKS

 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
TCP STATE CHECK [CONT.]
 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.
TCP STATE CHECK [CONT.]
Note to Remember

 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
 Processing State [Forwarding Setup]

Interface Mode Forwarding action

Egress interface/zone is the same as the ingress interface/zone from

Tap a policy perspective. The firewall discards the packet.

Virtual Wire Egress interface is the peer interface configured in the virtual wire

Egress interface for the destination MAC is retrieved from the

MAC table. If the information is not present, the frame is flooded
Layer - 2 to all interfaces in the associated VLAN broadcast domain, except
for the ingress interface .

The firewall uses the route lookup table to determine the next hop,
Layer - 3 or discards the packet if there is no match.
Processing State [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.
Processing State [User ID]

 The firewall uses the IP address of the packet

to query the User-IP mapping table
(maintained per VSYS)
 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
Processing State [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.
Processing State
[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 rule base.

Note : The firewall applies security rules to the

contents of the original packet, even if there are NAT
rules configured
Processing State [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 such as –
 VSYS session maximum reached
 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 .
SESSION ALLOCATION [Cont.]
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.
Processing State [FIREWALL SESSION
FAST PATH
A packet that matches an existing session will enter the
fast path.
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.
FIREWALL SESSION FAST PATH
[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 -

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

FIREWALL SESSION FAST PATH [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

Digest
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.
Processing State [Application Identification –
APP-ID]
The firewall first performs an application-override policy
lookup to see if there is a rule match.

 If matches, the application is known and content

inspection is skipped for this session.
 If it doesn’t match then application signatures are used
to identify the application

Nutshell:

The firewall uses protocol decoding in the content

inspection stage to determine if an application changes
from one application to another .
Application Identification – APP-ID
[Cont.]
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 .
Processing State [CONTENT
INSPECTION ]
The firewall performs content Inspection, if
applicable, where protocol decoders’ decode the flow
and the firewall parses and identifies known tunneling
applications
 If the identified application changes, the firewall

consults the security policies once again.

 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’.
FORWARDING/EGRESS STATE
Nutshell:
The firewall then re-encrypts the packet before entering
the forwarding stage, if applicable (SSL forward proxy
decryption and SSH decryption).
 The firewall identifies a forwarding domain for the

packet, based on the forwarding setup

 The firewall performs QoS shaping as applicable in the

egress process
 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.
 END OF SESSION

References:

Palo Alto Networks-PAN-OS Packet Flow