CPNotEnoughDataForRuleMatch

[meliux]

Since we upgraded to R81.10 we've noticed that the introduction of the "CPNotEnoughDataForRuleMatch" log entry due to sk113479, and it is now populating our logs with extra events that would otherwise not have any log entry created at all - either for a Security policy rule that is set to Track None, and/or for traffic passing through the separate Application & URL filtering policy layer where the connection is dropped by the client or server during a state of "possible match".

Question: is it possible to disable the creation of the "CPNotEnoughDataForRuleMatch" log entries for possible rule matches in 81.10?

[_Val_]

I am not sure these kinds of logs can be disabled. Are they causing you an inconvenience?

[meliux]

yeah, it is inconvenient because all our logs are being exported out to Splunk which has a real cost associated with it... was hoping these unnecessary logs could be removed prior to any manual filtering in the log exporter etc. We're talking millions of additional log entries that weren't there prior to 81.10.

[PhoneBoy]

The reason you're probably seeing this is because one or more rules are possible matches for the traffic (based on source/destination/service) that contain App Control/URLF objects in the Services column.
You may need to create an explicit rule near the top of the rulebase to permit this traffic without logging.

[CheckPointerXL]

Yes, that's the only workaround that it worked for me (sometimes not)

[PhoneBoy · Accepted solution]

If multiple ordered layers are used, make sure to check each layer to ensure the rule that matches the relevant traffic does not include logging.

[the_rock]

Its essentially a way of telling you that 3-way handshake is not completing properly.

Andy

[meliux]

yep.... so can these be ignored/unlogged?

[the_rock]

Thats what TAC told me couple of years back, correct.

Andy

[rzsuarez]

Should the URL Filtering /App Control be inside the Internet Layer or not?

[PhoneBoy]

Depends on how your layers are constructed.
A top-level "Firewall Only" layer with one or more inline layers with App Control/URL Filtering enabled is an approach I've used/recommended, particularly for customer moving from R7x releases where there were separate policies (layers) for Firewall and App Control/URL Filtering.