Packet replying does not match initial connection (R80.10)

[minhhaivietnam]

Hello ,

I have a problem about checkpoint R80.10 like this:

I create a rule like below:

From IP_SOURCE to IP_DST, service : TCP_8082

But when I search log drop from DST to SRC, I saw that replying packet get dropped because CP does not see it as a replying packet; (Checkpoint think this is new connection from DST to SRC and simply drop it by cleanup rule)

So please let me know why or any step to troubleshoot it?

Thank a lot!!

[Timothy_Hall]

The firewall is dropping this reply probably because it has no record of it in the state table. 

For the screenshot you provided, can you find the earlier log entry for this particular connection showing when the connection started (Accept action)?  Source port will be 36366 and destination port will be 8082 for the connection start.  To get more visibility into how these connections are starting and ending enable Accounting on the rule in the Track column which will show you how long the connection lasted and when it ended, standard logging of a connection only shows when the connection started. 

For even more info about connection state transitions see sk101221: TCP state logging.

[minhhaivietnam]

Thank for reply Hall,

I search log from SRC to DST with port 8082,36366 

=> see that the time is same as the time of dropped packet of replying direction(1:46:53PM) . So maybe the initial connection was closed right after it was established, then replying packet was dropped because of no connection exist. 

=> Do you agree with my guess?

[Matthias_Haas]

the logs are from two different FWs: DC-Internet-Fw-01 and  DC-Internet-Fw-02

may be Async Routing, misconfigured VRRP etc.

[minhhaivietnam]

Thanks Haas,

In my situation, 2 FWs are cluster with each other(using load sharing mode). How can I adjust for replying packet to go through DC-Internet-Fw-02 (same as intial direction) ?

or any solutions for this dropping?

(Now I am having to add a explicit rule to allow replying packet (from DST to SRC , service: tcp-high-port))

Thanks!!

[Matthias_Haas]

just curious: is the packet droped because of "out of state" or just by the cleanup rule ?

or did you disable to drop out of state packets:

[minhhaivietnam]

Hi,

It is dropped by cleanup rule (as pic in #1 my post)

Here is my screen (already disable drop out of state)

[Benedikt_Weissl]

You can enable the Sticky Decision Function, but be careful, this will disable SecureXL.