Skip to main content
cskuan
Staff
cskuan
Staff
November 25, 2019

Technical Tip: 'Dirty' session

  • November 25, 2019
  • 0 replies
  • 35802 views

Description

 

This article describes what a 'dirty' session is, and what the criteria are for a session to be marked as 'dirty'.

 

Scope

 

FortiGate.

Solution

 
When the FortiGate receives the first packet for a new session (for example, a SYN packet), the unit evaluates if the traffic should or should not be allowed based on the firewall policies. FortiGate performs route and firewall policy lookups for new sessions upon receiving the first packet (in the original direction).
FortiGate also performs a route lookup (not a firewall policy lookup) for the first reply packet.
FortiGate then saves the information from the route lookup (the outgoing interface and the gateway), the information from firewall policy lookup (the policy ID), and other information like address translation, inspection, authentication, logging, and so on, to the session. 
 
FortiGate does not perform additional lookups for the session unless the session is flagged as 'dirty'.
 
As long as there are no changes in the firewall policies and some other conditions, this evaluation is done only on the first session packet.
 
If the traffic is allowed by a firewall policy, the unit creates a session and flags it as 'may_dirty'.
 
After that, if there is a change in the firewall policies or any other condition that will trigger the state change, all the existing sessions with the 'may_dirty' flag will be marked with the 'dirty' flag.
 
This indicates to FortiGate that it needs to reevaluate the next session packet:
  •  If the session is still allowed/valid and matches the expected firewall policy to be allowed, the 'dirty' flag is removed and the 'may_dirty' flag is kept.
  •  If the session was re-evaluated as not allowed, it is marked with the 'block' flag and remains in the session table until it expires.
 
Any packet matching a session with the 'block' flag is dropped.
When a session is reevaluated, the offloaded sessions are sent to the CPU for processing. An extensive number of reevaluated sessions may result in high CPU utilization.
 
Below are the conditions that will trigger a session to be marked as 'dirty':
  1. Any changes in the firewall policies.
  2. Routing changes.
  3. Any network-related config changes.
  4. FortiGuard scheduled updates are performed (only when new definitions are downloaded and the policy has a relevant security profile attached). 
  5. If a session is synchronized via the FGSP protocol.

 

To check the session state, run the following in the VDOM:

 

diagnose system session list 

 

Example with a TCP session:

session info: proto=6 proto_state=01 duration=3734 expire=3553 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=5
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log dirty may_dirty npu synced f00
statistic(bytes/packets/allow_err): org=27778/181/1 reply=17956/154/1 tuples=2
tx speed(Bps/kbps): 3/0 rx speed(Bps/kbps): 2/0
orgin->sink: org pre->post, reply pre->post dev=71->72/72->71 gwy=192.168.0.5/10.20.101.19
hook=pre dir=org act=noop 10.20.101.19:53468->192.168.0.5:445(0.0.0.0:0)
hook=post dir=reply act=noop 192.168.0.5:445->10.20.101.19:53468(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=00:50:56:a0:5a:b5 dst_mac=00:0c:29:34:3f:07
misc=0 policy_id=328 auth_info=0 chk_client_info=0 vd=0
serial=241c1135 tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id = 00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x000c00
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000
vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0
no_ofld_reason: 

    Terms & ConditionsAccessibility statement