|
Below is a scenario where FortiGate has triggered Session clash events.
Session clash events can occur when the two sessions are received with the same source destination IPs and Ports. In most of cases, the traffic initiated by the endpoints can cause such events. But in the below scenario, a misconfiguration in FortiGate has trigged this event.
Logs:
msg="session clash"
new_status="state=00012204
tuple-num=4
policyid=3
dir=0 act=2 hook=0 152.58.73.216:39888->115.245.112.234:443(192.168.0.157:443)
dir=0 act=1 hook=4 152.58.73.216:39888->192.168.0.157:443(192.168.0.1:39888)
dir=1 act=2 hook=0 192.168.0.157:443->192.168.0.1:39888(152.58.73.216:39888)
dir=1 act=1 hook=4 192.168.0.157:443->152.58.73.216:39888(115.245.112.234:443)"
old_status="state=00010204
tuple-num=4 policyid=3
dir=0 act=2 hook=0 157.38.145.22:39888->115.245.112.234:443(192.168.0.157:443)
dir=0 act=1 hook=4 157.38.145.22:39888->192.168.0.157:443(192.168.0.1:39888)
dir=1 act=2 hook=0 192.168.0.157:443->192.168.0.1:39888(157.38.145.22:39888)
dir=1 act=1 hook=4 192.168.0.157:443->157.38.145.22:39888(115.245.112.234:443)"
As the above logs show the incoming source public IP is getting translated.
The public IP is being NAT to interface IP which is the same: 192.168.0.1 in both scenarios. This is the reason the Firewall is considering this traffic as a session clash.
Hence NAT should be disabled in incoming VIP policies to prevent such events in the FortiGate.
Related article:
Technical Tip: Explanation of the session clash message.
|
