Disable TCP SYNC check

[#1]

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

[UkWizard]

i havent seen this issue with any of my installs, which are configured like this. i presume you are using a static route for that traffic and NOT policy routing? Should work fine, are you sure it isn' t a client firewall thats dropping it?

[UkWizard]

Do you have a INT -> INT rule to allow the traffic by the way?

[#4]

Thanks for the response. Yes we do have a static route on the fortigate for the target subnet. Yes we do have a rule internal to internal allow all any No client firewall being used and tried on multiple machines I have checked all DoS settigns and have no protection profiles so assuming no IPS is being applied (even through i created one and disabled all and applied just in case). Im going to have a closer look at the cisco unit. As it stands TCP connection attempt results in the following: Initiator: TCP ESTABLISHED Fortigate: TCP ESTABLISHED Receivor: TCP SYN_RECEIVED By this i am led to beleive that the final ACK (for TCP handshake) from the initiator is not reaching the receiver (hence TCP SYN_RECEIVED). being blocked by either the fortigate or cisco due to the different return path. Will check cisco device over.

[UkWizard]

the fortinet has a packet sniffer, which is useful in these scenarios. example usage below; diag sniff packet internal ' host 192.168.1.10' or diag sniff packet internal ' icmp'

[#6]

Yes very handy. Used the packet sniffer to verify the return flow of traffic was not passing through the firewall.

[UkWizard]

should still work though, as the host thats pinging should still receive the replies. i havent come across this issue before, without it being a routing or client firewall issue. And make sure you have NAT Disabled on the INT -> INT policy.

[#8]

I beleive this problem can be refered to as an asymetric routing issue. I have tried to disable SPI using ' set asymroute enable' command but this had no affect. However i could not try reboot. No i do not have NAT set on the firewall policy. Also you are correct in that ping should work. As stated earlier ICMP works fine. This confirms that at a routing level everything is fine which just points to a possible IPS, DoS or AV problem at a higher level. I have tried many different clients and appolagies as forgot to mention something important. This problem only occurs on Vista/2008. After a round of testing i found that for some strange reason windows XP machines automatically create a host route entry to the remote device pointing it to the other gateway (bypassing the fortigate). So for example. Check routing table on xp machine and only the usual + default gateway exists (no routes to remote subnet). After ping (or any traffic at that matter) i check the routing table and magically a new route has been added for the remote HOST (not subnet) which bypasses the windows xp machines default gateway and goes straight to the second gateway. Im thinking that the only solution to this problem is to publish a route to all clients via DHCP. Forcing them to bypass the fortigate for that particular subnet. Didnt really want to do this though.

[UkWizard]

The new route is called an ICMP redirect and is normal behavior, its basically the fortinet telling the client there is a better route to use. And this isn' t asymmetrical routing, thats when the return traffic comes back through a different route via an stateful inspection device, like the fortigate.

[#10]

Very interesting. I have just checked ICMPRedirect on the Vista machine and this is enable. However the vista machine does not modify its routing in the way expected. Im guesssing some new security feature in vista. Just to be sure i tried a different vista machine with fresh install, no AV and windows firewall OFF. no luck Anyway, moving on. The issue remains and only solution at present is to bypass the fortigate. I agree, the term ' asymetric routing' usually refers to a complety different return route. However a similar issue to mine is documented in a fortinet technical note on page 6: http://kc.forticare.com/tmp/2008-8-14_5-48_9643_183_01-28005-0113-20040928_v2.80_Asymmetric_Routing_&_Layer-2_Tech_Note.pdf I have logged a call with fortnet and will post the fix