DescriptionSession clash messages appear in the logs when a new session is created but a conflicting similar session already exists.
When 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.
SolutionTo monitor the sessions clashes over time, there is a counter available in 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.
So there is no way to associate the return traffic (to 172.31.19.186:5001) to the target 10.129.0.25 or 10.129.0.98.
Example 2.
If in the example 1/, if the source IP 10.129.0.98 would try 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, 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 the same NAT src port, permits the firewall to have more than 65K sessions with only one public IP used for SNAT.
