Sessions

View Session

• get system session status view number of sessions

• get system session list: view list of sessions

• diagnose sys session list

  • sdwan_service_id =0: session matched the SDWAN implicit rule

  • sdwan_mbr_seq: SDWAN member ID

  • sdwan_service_id: SDWAN rule ID in use

TCP Protocol States

• protocol_state = xx

  • left digit: server-side state: 0 = no inspection, non-zero = proxy or flow

  • right dgit: client-side state

TCP State	Value
None	0
ESTABLISHED	1
SYN_SENT	2
SYN & SYN/ACK	3
FIN_WAIT	4
TIME_WAIT	5
CLOSE	6
CLOSE_WAIT	7
LAST_ACK	8
LISTEN	9

ICMP and UDP Protocol States

• UDP is stateless, but Fortigate uses two protocol_state:

UDP State	Value
UDP traffic one way only	0
UDP traffic both ways	1

• ICMP has no state, protocol_state always 00

Session Flags

Flag	Description
log	session is being logged
local	session is to/from local stack
ndr	Session will be checked by IPS signature
nds	Session will be checked by IP anomaly
npu	Session can be offloaded by NPU
wccp	web caching
npd	Session cannot be offloadded to NPU
redir	Session is being processed by an application layer proxy
authed	Session was successfully authenticated
auth	Session requires (or required) authentication

May Dirty Sessions

• New firewall sessions created after matching a firewall policy with accept action

  • a firewall lookup is done (top-down)

  • Flagged as may_dirty

• Lookup process

  • First original packet (route and firewall policy lookup)

  • First reply packet (route lookup only)

  • No additional lookups unelss session is flagged as dirty

Dirty Sessions

• A session is flagged as dirty after a routing, firewall policy, or interface change

  • Each direction of a dirty session must be re-evaluated

  • Routing changes are common in SD-WAN

  • Session routing information is flushed (routing change

Interface Stickiness

• Force Sessions to keep using outgoing interface and gateway after a route change

• Current route must still be present in FIB. Otherwise, Fortigate flags the session as dirty and re-evaluates it

config system interface
  edit <interface>
    set preserve-session-route enable
  next
end

Routing Changes and SNAT sessions

• By default, SNAT sessions are not flagged as dirty after a routing change. Exception: route in use is removed from FIB

• Force re-evaluation of SNAT sessions after a routing change (default = disable):

config system global
  set snat-route-change enable
end

• If SNAT IP changes during re-evaluation, packet is dropped and sessions is cleared

Auxiliary Sessions

• Dirty sessions are also triggered by a change in the reply traffic interface

  • Sesions handled by system CPU (no hardware offload)

• By default (auxiliary session disabled), route lookup for reply traffic considers routes over original ingress interface only

  • Reply traffic can't be routed over another member with better performance

• Auxiliary sessions solve the two above issues by enabling Fortigate to:

  • Offload asymmetric sessions to hardware by creating an auxiliary session (aka reflect session)

  • Select the best route for reply traffic through any member, not necessarily the same interface where the original incoming traffic was received.

config system settings
  set auxiliay-session enable

Firewall Policy Changes and Sessions

• Firewall policy changes can lead to high CPU utilization

Reference

• https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dirty-session/ta-p/197748