The information you are about to copy is INTERNAL!
DO NOT share it with anyone outside Check Point.
Early drop of a connection before the final rule match
Quantum Security Gateways
R80.10 (EOL), R80.20, R80.30, R80.40, R81, R81.10
Platform / Model
Log with Rule Name "CPEarlyDrop".
Log with Rule Name "N/A".
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 we have a full match on 'Block' rule and all potential rules of the layer above it, 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 all the potential rules.
Layer potential rules are a list of rules that have matched the connection so far, according to filter criteria that were resolved for arrived packets (IP, port, VPN tunnel etc).
Consider the following policy:
When FTP connection is opened, the potential rules that match the first packet criteria are (3,4,6,7). Why those are the possible rules? 1. The reason for rules 3 and 4 is since that by default we match application/category on any port when used in 'Block' rule (i.e drop reject etc). 2. The reason for rule 6 is since FTP service should match FTP traffic. 3. The reason for rule 7 is since it's Any service/application. Nevertheless, since all potential rules have a Drop action, the connection will be blocked on the first packet, although final decision of the rule-base was not made.
UserCheck actions such as "Drop with Blocked Message" or "Inform" do not participate in the optimization, in order to ensure that the user will receive the reply page. Likewise, potential rule that have service with resource cancel the optimization for the connection as well.
Furthermore, when Early Drop occurs in one of the layers, previous layers matching process is stopped (because the final action of the connection is known), and the log record for these layers will either display the matched rule or "N/A" incase the layer has not reach final rule match yet.
The following video explains further on this type of logs -