Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Not applicable

Disable TCP SYNC check

Hi Does anyone know how to disable the TCP SYNC check on a frotigate 50B? The fortigate acts as default gateway for the majority of traffic. However i need to bounce some traffic to a different gateway on the same internal subnet. This works fine for ICMP traffic but not TCP. This i beleive is due to the fact traffic takes a different return path since on return there is no need to bounce through the fortigate. I had a similar issue when doing this with a netscreen but was able to resolve the issue by disable TCP SYNC check. Since firewals monitor TCP sessions and if packets try and pass out of sequence or with no SYNC flag then they are dropped. thanks
14 REPLIES 14
UkWizard
New Contributor

its not the windows firewall blocking these is it?
UK Based Technical Consultant FCSE v2.5 FCSE v2.8 FCNSP v3 Specialising in Systems, Apps, SAN Storage and Networks, with over 25 Yrs IT experience.
UK Based Technical Consultant FCSE v2.5 FCSE v2.8 FCNSP v3 Specialising in Systems, Apps, SAN Storage and Networks, with over 25 Yrs IT experience.
Not applicable

I dont beleive so. I disable the windows firewall service at both ends and no AV or firewall clients have been installed
Not applicable

It appears that the issue was as thought. The SPI engine in the fortigate was dropping the final ACK. using the ' diag debug flow' command we were able to see the fortigate dropping the reply as replay attack. The two options to resolve this issue are: 1. Disable SPI using the ' set asymroute en' 2. Enable NAT on the firewall policy Unless someone knows how to disable SPI per interface then disabling this on the internal interface is an acceptable solution. But as it stands it appears an all or nothing and therefore enabling NAT for the internal -> internal policy was the safest solution. Problem resolved. Thanks for the help
UkWizard
New Contributor

have missed some info somewhere, as the initial ack to my understanding would pass through the fortinet. for it to pass through the fortinet, i am presuming the initiator is either NOT on the internal lan (which is where i presumed it was located).
UK Based Technical Consultant FCSE v2.5 FCSE v2.8 FCNSP v3 Specialising in Systems, Apps, SAN Storage and Networks, with over 25 Yrs IT experience.
UK Based Technical Consultant FCSE v2.5 FCSE v2.8 FCNSP v3 Specialising in Systems, Apps, SAN Storage and Networks, with over 25 Yrs IT experience.
Not applicable

appologies. i tried to attach diagram but didnt work for some reason. - Client Initiator has default gateway of fortigate - Fortigate has policy route which directs 10.100.100.0/24 traffic to cisco - Cisco sits on the same subnet as client - All other traffic flows either to VPN or WAN interface on fortigate Client send SYN to client 10.100.100.90 which goes to the fortigate and is routed back out the same interface to the cisco. The cisco routes packet as usual to the 10.100.100.0 subnet. reciever 10.100.100.90 reveives the SYN and send a SYN/ACK back to client subnet and waits in TCP SYN_RECEIVE state. cisco recevies SYN/ACK and forwards it straight to the client since its subnet is directly connect to the cisco. Thus bypassing the fortigate. Client receives SYN/ACK and adopts TCP ESTABLISHED state and sends final ACK in reply which goes to the fortigate since this is its defualt gateway. However, the fortigate SPI is too clever and drops the packet since it did not see the ACK/SYN packet flow from 10.100.100.90 to client. Solutions to overcome this are: 1. Static route on client 2. Disable SPI on fortigate 3. Enable NAT on relevant firewall policy Enabling NAT simply ensure return traffic is send to the fortigate by the cisco.
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors