How to enable TCP out of state exceptions per network or host

[Eugene_Brown]

We are migrating from Cisco ASA's to CheckPoint (R80.10), and we have a requirement to permit TCP out of state packets. I know how to do this for a whole gateway (sk102491). However the Cisco ASA's had these exceptions per VLAN. Does anyone know of a way in CheckPoint to provide similar exceptions at a granular level, i.e. for a VLAN, inline layer, network or host?

[Vladimir]

[Dor_Marcovitch]

Try to re-think about this requirement. Maybe playing with the timers of the tcp service will do the trick, it might be that the idle timeout of.the application for example exceed the tineout and the fw remove the session while the application does not close the session.

[Eugene_Brown]

Would disabling Aggressive Aging also help, or is would that option be unrelated to these kind of timeouts?

[Dor_Marcovitch]

aggressive aging comes in when you are about to reach the size of the session table then the FW calculate which sessions to delete from the session table to free it up.

1) check that the session table is automatic / static

2) check the session table peak "fw tab -t connections -s"

3) check the TCP ports that you see that cause you the "asymetric traffic drops" 

4) configure special service for them and you can disable aggressive aging / play around with the timers / check the values on the connection table on an live session / check logs for the delta between the drop log and the correlated log of the session start. ** most important disable the "match for any"

5) create a rule between the relevant source and destination with this new special service and verify that the traffic hit this rule.

6) now give it a time , and monitor the application & FW resources and modify that special rule according to the findings

[Eugene_Brown]

I managed to get some stats from the for the application that specifically has had problems going through CheckPoint, and created services with aging disabled and max session timeouts (86400). So far feedback from the app owners is good. I may try playing with reducing the session timeout, but the app stats I've been given so far suggest 24 hours may be needed.