We found "session clash" in the Fortigate model 600E with FortiOS v7.0.3, the eventlog as below:
1. Fortigate eventlog (internet IP: 100.19.44.39; Fortigate VIP (46.96.186.1 ->10.113.1.115, currently is VIP static NAT :(
1: date=2022-06-10 time=09:48:54 eventtime=1654825734757941183 tz="+0800" logid="0100020085" type="event" subtype="system" level="information" vd="root" logdesc="Session clashed" status="clash" proto=1 msg="session clash" new_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28674->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28674)" old_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28618->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28618)"
2: date=2022-06-10 time=09:47:51 eventtime=1654825671783553340 tz="+0800" logid="0100020085" type="event" subtype="system" level="information" vd="root" logdesc="Session clashed" status="clash" proto=1 msg="session clash" new_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28434->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28434)" old_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28422->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28422)"
3: date=2022-06-10 time=09:46:51 eventtime=1654825611508397542 tz="+0800" logid="0100020085" type="event" subtype="system" level="information" vd="root" logdesc="Session clashed" status="clash" proto=1 msg="session clash" new_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28233->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28233)" old_status="state=00010200 tuple-num=2 policyid=258 dir=0 act=2 hook=0 100.19.44.39:28258->46.96.186.1:8(10.113.1.115:8) dir=1 act=1 hook=4 10.113.1.115:8->100.19.44.39:0(46.96.186.1:28258)"
The sniffered message is :
DGD_Forti600E_03 # diag sniffer packet Ext_Zone 'host 10.113.1.115 and port 8' 4 0 a
interfaces=[Ext_Zone]
filters=[host 10.113.1.115 and icmp]
....
2022-06-13 04:23:02.216904 Ext_Zone -- 100.19.44.39 -> 10.113.1.115: icmp: echo request
2022-06-13 04:23:02.216982 Ext_Zone -- 10.113.1.115 -> 100.19.44.39: icmp: echo reply
2022-06-13 04:23:02.294267 Ext_Zone -- 100.19.44.39 -> 10.113.1.115: icmp: time stamp query id 13 seq 0
2022-06-13 04:23:02.294302 Ext_Zone -- 100.19.44.39 -> 10.113.1.115: icmp: echo request
2022-06-13 04:23:02.294340 Ext_Zone -- 10.113.1.115 -> 100.19.44.39: icmp: time stamp reply id 13 seq 0 : org 0x0 recv 0xf0d15b xmit 0xf0d15b
2022-06-13 04:23:02.294357 Ext_Zone -- 10.113.1.115 -> 100.19.44.39: icmp: echo reply
Any problem suspected in my Fortigate ( VIP configuration, Fortigate hardware, FortiOS... ) ? any recommendation, thanks.
With regards
Benson LEI
Solved! Go to Solution.
Usually, not a reason to worry, in most of the cases it is either port exhaustion for PAT or short time-outs for session table. Anyway, this will cause client to retransmit the failed packet, that is it. On a busy FGT especially with multiple VDOMs it happens.
More details: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Explanation-of-the-session-clash-message/t...
Yuri
https://yurisk.info/ blog: All things Fortinet, no ads.
Usually, not a reason to worry, in most of the cases it is either port exhaustion for PAT or short time-outs for session table. Anyway, this will cause client to retransmit the failed packet, that is it. On a busy FGT especially with multiple VDOMs it happens.
More details: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Explanation-of-the-session-clash-message/t...
Yuri
https://yurisk.info/ blog: All things Fortinet, no ads.