Troubleshooting Tip: Explanation of the session clash message
Description
This article describes a scenario where 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.
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 system session stat
FGVM080000-----2 # diagnose system 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
FGVM080000-----2 # diagnose system 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)"
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 IPs 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.
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 source port permits the firewall to have more than 65K sessions with only one public IP used for SNAT.
The fact that a tuple difference allows to reuse of the same NAT source port permits the firewall to have more than 65K sessions with only one public IP used for SNAT.
Note: The number of clashed sessions is a cumulative value over the duration of the firewall's uptime. To reset this counter, a reboot is required.
The diagram below illustrates the various fields contained within the log message.
Related article:
Technical Tip: Session Clash Events in FortiGate