how to explain the following ?

[Gongya_Yu]

why does CP treat them differetly ? 

The second and the  third packets are dropped ?

thanks !!

[Chris_Atkinson · Accepted solution]

Did you review the full log card and corresponding SK article for more information?

"Connection terminated before detection" in log reason for Unified Rulebase (checkpoint.com)

[Gongya_Yu]

I did, but I still do not understand other than theory.  sorry.
which configuration enables this?  I do not see this on all our other firewalls.

thanks !!

[emmap]

From the article Chris linked:

If the Access Rulebase does not reach a final match on accept, a log appears with a new unique rule specific for this case 'CPNotEnoughDataForRuleMatch' and accept action.

Why a new unique rule?
Because the connection does not reach a final match, you cannot be sure on which rule this connection should have a match if it does not terminate before detection. To avoid a confusing rule in the log, a new unique rule indicates that this traffic reached the "Connection terminated before..." flow.

Why accept?
The Security Gateway does not drop the connection. The connection terminated before a final match. The Security Gateway does accept the connection first packet (the rule base is in a possible match state). The log is "accept," reflecting that the traffic of the first packet was accepted because of a possible match.

Basically, the gateway saw a UDP packet on port 514 and accepted it as it can match a configured rule in your policy (rule 104, by the looks of your logs) but a single packet was not enough to confirm. As the packet was accepted as part of trying to figure out whether it matched the rule, we have an accept log with this notice that the packet was accepted, but we weren't able to finalise a rule match as no further packets came through on a matching session. 

[Gongya_Yu]

A little complicated.
Can I understand this way ?
Either Drop or Accept won't tell whether the user connection is drop and accepted finally. 
If yes,  what is the benefit for this log message ?

thanks a lot !!

[Bob_Zimmerman]

This log message almost always means the firewall isn't the problem. It accepted the traffic, and something later (e.g, a routing problem) caused the traffic to not actually work.

[Gongya_Yu]

This second log accepts the packet without reaching the final match, if some drop matches later, the connection will be dropped, right ?

thanks !!

So confusing. Based on my previous post, I was told  this log tells the connection is terminated.

[emmap · Accepted solution]

We only generate the log on the final decision, we don't log 'accepts' and then later log a 'drop' for the same connection. The reason you see an accept like this is as others have explained in this thread - some packets occurred, we accepted them because we needed more than simple IP/proto/port information to make a policy decision (due to advanced inspection being configured in the policy) but the connection stream stopped before we received this additional information. We don't want to just silently accept things as that would be a pretty terrible thing for a security device to do (unless it's explicitly configured to) so we send you these logs so that you know that these packets occurred. 

[Gongya_Yu]

"we accepted them because we needed more than simple IP/proto/port information to make a policy decision (due to advanced inspection being configured in the policy) but the connection stream stopped before we received this additional information."

The connection attempts for the second and the third logs will be conditionally dropped ? 

[emmap]

When that log is generated, there are no more packets on that connection. The packets that we associated with that connection stopped flowing before we could match a rule. There are no more packets on that connection, hence there is nothing to drop.

[Gongya_Yu]

thanks so much !! 
We open the log to our users. That is why I like to be clear before the users ask.  Seems I have a long way to go.

[the_rock]

@Bob_Zimmerman explained it PERFECTLY below, which was also your question btw 🙂

Andy

https://community.checkpoint.com/t5/General-Topics/When-does-CPEarlyDrop-occur-with-ACCPET-action/m-...

[PhoneBoy · Accepted solution]

To understand why this phenomenon occurs, you need to understand how rules are matched.
See: https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/m-p/9888 
See also: https://phoneboy.org/2016/12/14/which-comes-first-the-ports-or-the-application-id/ 

The first "Accept" log is because there are one or more rules that potentially match this traffic (based purely on Layer 3 information).
If any of those rules involve Application Control (either due to the services/applications listed or because of the log setting on the rule), then additional traffic is required to properly classify it to find the matching rule.

The fact you got CPNotEnoughDataForRuleMatch means that the traffic stopped flowing before we were able to properly classify it.
This is expected behavior depending on the order of the rules in your rulebase.
You can also eliminate the extra logs by creating an explicit rule early in your rulebase using the service syslog (which is a UDP object).
This way, the first rulebase match can be done entirely on the first packet.

[Gongya_Yu]

How do the same source, destination, and port using the same firewall rules get different filtering ? timing ? payload or etc ?

thanks so much !!

[the_rock]

I know that may seem confusing, but as everyone said, its most likely NOT the fw issue, as the other side does not send response back, thus not allowing the firewall to fully classify the application, for the lack of better term.

Andy

[PhoneBoy · Accepted solution]

The first rule that matches the connection (based on rulebase order) is the one that generally applies.
However, some services/applications can NOT be identified on the first packet (i.e. the TCP SYN).
Consider the following example:

Let's assume we are making an HTTP connection (port 80) to a given website.
The first packet does not contain enough information to determine which of these rules will ultimately apply as:

• No files have been transferred yet
• We don't know what website you are accessing until the HTTP Host header is seen

In this context, all three rules are potential matches.
Since at least one of them has an Accept action, we allow the traffic until we have enough to properly classify the connection.
If we do not receive enough information before the connection ultimately terminates (e.g. TCP FIN/FIN-ACK), you get the  CPNotEnoughDataForRuleMatch message.

In your case, I'm guessing the first rule that "potentially matches" the relevant traffic includes either:

• Something that is NOT a TCP/UDP Service Object
• Contains the tracking "Detailed" or "Extended" (these logs activate App Control)
• Uses Content Awareness (less likely, but possible)

Rules with these characteristics cannot be matched on the first packet.

[Gongya_Yu]

thanks a lot !!

[the_rock]

I will see if I have an email with explanation TAC guy gave when we had a case for this while back, I found it to be an EXCELLENT one. If I "dig it out", will update.

Andy

[Gongya_Yu]

thanks !!

[the_rock]

I cant sadly find it, as its been some time, but it was very similar to what Phoneboy sent you.

Andy

[Gongya_Yu]

thanks a lot for many responses. Unfortunately I still don't know how I tell my users whether the second or the third logs indicate their connection attempts succeed or fail. If the log does not tell exactly the connection attempt succeeds or fails. why there ?
As a user, what I care most is my connection attempt succeeds or fails based on the firewall rules configured.
 

[the_rock]

If you read carefully what @emmap and @PhoneBoy wrote, I dont think it even matters in this case what those entries show, whole point is there was NOT enough data to classify session as successful, thus the reason why you see that.

Andy

[the_rock]

Personally, what I always do if there is ever a customer who wants an official CP response about anything, I open the case, let TAC tell them EXACTLY the same thing...case closed 🙂

[Gongya_Yu]

Last question for this.

Based on your experience and theory, 3 options for you to choose for the second and the third logs, which one do you select ?

1. Drop at last
2. Might drop or might accept conditionally at last
3. Accept at last

I do not mean drop or accept for that log particular timeframe when Checkpoint does not have enough data to make final decision,  but for the connection final status.

[PhoneBoy]

Accept means it was allowed.
The connections should be successful in all cases.

[Gongya_Yu · Accepted solution]

thanks !!

As I asked this, sometimes I was told it might be dropped.

Why accept?
The Security Gateway does not drop the connection. The connection terminated before a final match. The Security Gateway does accept the connection first packet (the rule base is in a possible match state). The log is "accept," reflecting that the traffic of the first packet was accepted because of a possible match.

Basically, the gateway saw a UDP packet on port 514 and accepted it as it can match a configured rule in your policy (rule 104, by the looks of your logs) but a single packet was not enough to confirm. As the packet was accepted as part of trying to figure out whether it matched the rule, we have an accept log with this notice that the packet was accepted, but we weren't able to finalise a rule match as no further packets came through on a matching session. ( This leads me to think the session might be dropped)

[the_rock]

EXACTLY! Thats section of the sk that explains it.

Andy

[Gongya_Yu]

That section confuses me. especially those highlighted words. 

possible, final, finalize and etc. All these words leave room to either drop or accept.  That's my understanding !!

[the_rock]

If you can fully understand what @PhoneBoy said in below link, I think it will 100% make sense.

Andy

https://community.checkpoint.com/t5/Management/Difference-between-Session-and-Connection/td-p/35462