CPNotEnoughDataForRuleMatch first possible match is Cleanup Rule and is allowing traffic the Cleanup

[Zeppln]

CPNotEnoughDataForRuleMatch first possible match is Cleanup Rule and is allowing traffic the Cleanup rule should Block:

Hello everyone,

A client currently has an infrastructure in which an inline layer is used for all Internet access policies (#30 e.g). From there, there are specific rules based on AD roles and static IP addresses. The issue is that all traffic that does not match any rules should be dropped by the Cleanup rule (#30.50 e.g).

I have read in different posts that this logs work as intended, and the reason for no rule matches is that the server on the Internet side closed the connection or didn't respond with a SYN/ACK. I have read in some other posts that inside the inline layer there is a rule that can possibly match so the traffic will be accepted, and we have searched every possible rule for a match and blocked some access to certain services, but some still remain. When enabling the option to check for possible rule matches with sk113479, the first possible match for an "Accept" log is the Cleanup rule. 

What does this mean? All traffic that shouldn't be authroized should be left for the Cleanup rule but since the first possible match is that Cleanup rule, shouldn't it be matching there and dropping the traffic? 

I would greatly appreciate your insight on this, thanks

[_Val_ · Accepted solution]

It is a common practice to keep cleanup rule for an inline layer with ACCEPT action. Otherwise, it may be too restrictive and won't serve the purpose for the sublayer.

See some examples in the cdocumentation: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuid...

[emmap · Accepted solution]

It usually means that it's trying to match an application type rule or do some URL/Application classification, but only saw a SYN packet that it allowed through so that the connection could be sufficiently established to be able to do the classification. The connection either didn't establish or was terminated (not by the firewall) before the classification could complete, hence it's logging that it allowed what it saw but couldn't determine a rule to match before it stopped.

[the_rock · Accepted solution]

See if below links help. Essentially, not to bore you with the whole "story" now, but really what all this boils down too is what somewhere along the lines, 3 way handshake is not completing, though its not fw dropping the connection.

I know wording can be (or is) little confusing to some.

Andy

https://community.checkpoint.com/t5/Security-Gateways/quot-CPNotEnoughDataForRuleMatch-quot-and-quot...