FIREWALL SESSIONS. FORTINET TROUBLESHOOTING.
Let´s continue talking about firewall sessions.
Once we understand what is it and some basic knowledge of them (explained in FIREWALL SESSION.INTRO post), we can start troubleshooting.
First of all, we have to know the session timers configured (it vary between manufacturers). In fortigate, we can check as below:
# config system global
# show full-configuration | grep tcp
set tcp-halfclose-timer {integer} Number of seconds the FortiGate unit should wait to close a session after one peer has sent a FIN packet but the other has not responded (1 - 86400 sec (1 day), default = 120). range[1-86400]
set tcp-halfopen-timer {integer} Number of seconds the FortiGate unit should wait to close a session after one peer has sent an open session packet but the other has not responded (1 - 86400 sec (1 day), default = 10). range[1-86400]
set tcp-timewait-timer {integer} Length of the TCP TIME-WAIT state in seconds. range[0-300] , default = 120.
# config system session-ttl # show
set default {string} Length of time a TCP, UDP, or SCTP session can be idle before being dropped by the FortiGate unit, default = 3600.
NOTE: TTL can be configured by port and this configuration takes advance over default settings.
Once we have clear the session timmers, we can check firewall sessions:
# get sys session status ==> to see the session count
NOTE: compare the output with datasheets to discard Firewall reaching its limits.
We have two command options to list the entire session list:
# get sys session list ==> active sessions brief
# diag sys session list ==> active sessions extended
In case of any of this commands, the output could be too longer so the best practice in this case is to set filters to list only the sessions we want to check, it could be done as follow:
# diag sys session filter clear ==> in order to delete any previous filter configured
# diag sys session filter ? ==> to see all posible filters
# diag sys session filter dst 1.2.3.4 ==> destination host example
# diag sys session filter dport 53 ==> destination port example
# diag sys session list ==> to list active session which match filters
In case you need to clear a session, you can do it as below:
# diag sys session filter clear ==> in order to delete any previous filter configured
# diag sys session filter dst 1.2.3.4 ==> destination host example
# diag sys session clear ==> to clear active session which match filters
EXAMPLE OUTPUT:
session info: proto=6 proto_state=01 duration=3368 expire=3368 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty npu none
statistic(bytes/packets/allow_err): org=31660/187/1 reply=30734/171/1 tuples=2
tx speed(Bps/kbps): 9/0 rx speed(Bps/kbps): 9/0
orgin->sink: org pre->post, reply pre->post dev=112->127/127->112 gwy=10.15.119.106/192.168.13.78
hook=pre dir=org act=noop 10.18.3.191:60715->10.15.119.106:8080(0.0.0.0:0)
hook=post dir=reply act=noop 10.15.119.106:8080->10.18.3.191:60715(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=10963 auth_info=0 chk_client_info=0 vd=2
serial=1941b75d tos=ff/ff app_list=0 app=0 url_cat=0
dd_type=0 dd_mode=0
npu_state=0x000c00
npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=170/170, ipid=170/170, vlan=0x800d/0x8070
vlifid=170/170, vtag_in=0x000d/0x0070 in_npu=2/2, out_npu=2/2, fwd_en=0/0, qid=5/5
Protocol: It could be TCP 6, UDP 17, ICMP 1 or SCTP 132.
Session State: (see FIREWALL SESSIONS. INFO)
TTL: 3600 seconds by default.
Traffic shaping: matching traffic shaping policies to optimize bandwidth usage.
State: The session is flagged with some states which mean the following:
Traffic counts: number of bytes, packets and error in this session.
NAT operation: If there is any kind of NAT.
Policy match: Fw policy rule which matched traffic for this session.
Session id: Session identificator.
HW Acceleration:
First, you must see the flag:
flag 0x81 means regular traffic.
flag 0x82 means IPsec traffic.
Then you must see the following depending the NP of the Firewall:
offload=0/0 for non accelerated traffic.
offload=1/1 for NP1(FA1) sessions.
offload=2/2 for NP1(FA2) sessions.
offload=3/3 for NP2 sessions.
offload=4/4 for NP4 sessions.
offload=5/5 for XLR sessions.
offload=6/6 for Nplite/NP4lite sessions.
offload=7/7 for XLP sessions.
offload=8/8 for NP6 sessions.
NOTE: offload=x/y where x is the output and y is the input. If you see something like offload=0/8 or offload=8/0 it means that HW acceleration is failing in one way (0) and working in the other way (8).
NOTE: if you see offload=0/0 (traffic not accelerated) it appears a field called no_ofld_reason: which explain the reason because this session is not accelerated
There is a particular no_ofld_reason I would like to explain in detail. Sometimes you can see that traffic is not being accelerated (offload=0/0) and the no_ofld_reason shows “dirty”.
Well, there is a Fortinet feature which is called firewall-session-dirty which is a mechanism to make sure that active sessions always stay relevant, I mean, the Fortigate is continuosly checking its firewall sessions when there is a config change. There are three options for this feature:
check-all (default): Flush all sessions and evaluate them anew. This is the default setting.
check-new: Keep existing sessions and check new connections only. This reduces CPU load and the possibility of packet loss.
check-policy-option: Use the option selected in the firewall-session-dirty field of the firewall policy.
By default, when a config change is performed in routing, object, firewall policy, etc. The Fortigate checks all active sessions and marked them as “dirty” for further firewall policy validation. It cause that all of them cannot be accelerated by hardware because it should validate again trough kernel (FortiOS). In case we manage more tan 2.000 policy rules, there is a Fortinet warning because it could cause a CPU penalty depending of Fortigate hardare device, and could be recommended to change firewall-session-dirty default setting.
The way you can change this setting is the following:
#config system settings #set firewall-session-dirty { check-all | check-new | check-policy-option } #end
That´s all for today, I hope you are/have enjoying/enjoyed your holidays. see you in the next post!!
