Description
This article describes that Session clash messages appear in the logs when a new session is created but a conflicting similar session already exists.
When a session clash happens, the old session will be closed and replaced by the new one.
The only consequence is that it may cause some re-transmissions.
Scope
FortiGate.
Solution
To monitor the session clashes over time, there is a counter available in the following CLI output:
diagnose sys session stat
FGVM080000-----2 # diagnose sys session stat
misc info: session_count=27 setup_rate=0 exp_count=0 clash=1
memory_tension_drop=0 ephemeral=0/65536 removeable=0
delete=0, flush=0, dev_down=0/0
TCP sessions:
3 in ESTABLISHED state
1 in SYN_SENT state
firewall error stat:
error1=00000000
error2=00000000
error3=00000000
error4=00000000
tt=00000000
cont=00000000
ids_recv=00000000
url_recv=00000000
av_recv=00000000
fqdn_count=0000001c
tcp reset stat:
syncqf=1 acceptqf=0 no-listener=559 data=0 ses=0 ips=0
global: ses_limit=0 ses6_limit=0 rt_limit=0 rt6_limit=0
Example 1.
date=2015-09-04 time=05:54:03 logid=0100020085 type=event subtype=system level=information vd="root" logdesc="session clash" status="clash" proto=6 msg="session clash"
new_status="state=00000200 tuple-num=2 policyid=1 dir=0 act=1 hook=4 10.129.0.25:5001->10.58.2.61:5001(172.31.19.186:5001) dir=1 act=2 hook=0 10.58.2.61:5001->172.31.19.186:5001(10.129.0.25:5001)"
old_status="state=00000200 tuple-num=2 policyid=1 dir=0 act=1 hook=4 10.129.0.98:5001->10.58.2.61:5001(172.31.19.186:5001) dir=1 act=2 hook=0 10.58.2.61:5001->172.31.19.186:5001(10.129.0.98:5001)"
In this example, a session clash message is generated because the tuple (NAT_srcip, NAT_srcport, destip, destport) is the same for both source IP 10.129.0.25 and 10.129.0.98.
There is no way to associate the return traffic (to 172.31.19.186:5001) with the target 10.129.0.25 or 10.129.0.98.
Example 2:
If in example 1/, the source IP 10.129.0.98 tries to establish a session on a different target IP (10.58.2.62) but with the same other characteristics (NATed_address=172.31.19.186, NAT_sport=5001, dstport=5001), this would not have generated a session clash message.
Session: 10.129.0.98:5001->10.58.2.62:5001(172.31.19.186:5001)
This is because the tuple (NAT_srcip, NAT_srcport, destip, destport) is different, and the destip changes, so the srcport randomly chosen can be the same, it will not generate a session clash message.
The fact that a tuple difference allows to reuse of the same NAT src port permits the firewall to have more than 65K sessions with only one public IP used for SNAT.
Related article:
Technical Tip: Session Clash Events in FortiGate
