Create a Post
Showing results for 
Search instead for 
Did you mean: 

Blocking the connection before final rule match: CPEarlyDrop

Somehow missed this in the discussion of the Unified Policy Column-based Rule Matching discussion, but encountered it recently when testing IPS. The drop log Access Rule Name is CPEarlyDrop and the log points to sk111643 Early drop of a connection before the final rule match which covers it well. The explanation pasted below is from the SK and this is also mentioned in ATRG: Unified Policy. Think it explains it pretty well. Check out the SK for more info.

The Unified Policy may contain filter criteria that cannot be resolved on a connection's first packet, such as Application or Data. Therefore, on some connections the final rule match decision is reached only on the following data packets.

However, the Rule Base may decide to block the connection at an early stage without a final rule decision, if all potential rules of the layer for a specific connection have a Drop or Reject action. This drop will issue a log with Rule Name "CPEarlyDrop" and hits will be counted for

TO READ THE FULL POST it's simple and free

Nice one


So, is disabling optimization (as described in the SK) the only way to find out which rule is responsible for dropping the traffice?


Depending on the size of your rulebase you may be able to eyeball it, but yes you must disable this optimization to see the drop rule number.  Essentially what happened is all rules with an Accept/Allow action were "thrown out" by Column-based Matching leaving only rules with drop actions; this "early drop" rulebase behavior was covered in my book:


Click to Expand

One interesting side effect of this new column-based policy evaluation technique is
the possibility for what is known as an “early drop” to occur. Suppose that candidate
traffic is being column-matched against a rulebase, and all rules with an Accept/Allow
action were excluded. In other words, the only surviving rules after the column-based
evaluation had Drop/Block as an action. In that case the traffic will of course be dropped
and logged, but no matching rule number will be present in the log entry.

While we generally don’t care about this situation since the packet was dropped
anyway, the lack of a logged rule number that caused the drop action can be a bit
confusing when attempting to troubleshoot. This “early drop” behavior can be disabled
if needed by toggling the up_early_drop_optimization kernel variable as
specified here: sk111643: Early Drop - dropping connection before final rule match




I can see that I'm going to be disabling/enabling this multiple times a day, followed by unnecessary policy installs. Surely, there is a way of letting us know which of the rules are blocking it without jumping through all of these hoops?