topic Re: how to explain the following ? in General Topics

how to explain the following ?

Gongya_Yu — Mon, 10 Jun 2024 04:03:36 GMT

why does CP treat them differetly ?

The second and the third packets are dropped ?

thanks !!

Re: how to explain the following ?

Chris_Atkinson — Mon, 10 Jun 2024 04:37:09 GMT

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)

Re: how to explain the following ?

Gongya_Yu — Mon, 10 Jun 2024 04:41:41 GMT

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 !!

Re: how to explain the following ?

emmap — Mon, 10 Jun 2024 07:20:45 GMT

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.

Re: how to explain the following ?

Gongya_Yu — Mon, 10 Jun 2024 14:58:13 GMT

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 !!

Re: how to explain the following ?

Bob_Zimmerman — Mon, 10 Jun 2024 15:13:54 GMT

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.

Re: how to explain the following ?

Gongya_Yu — Mon, 10 Jun 2024 16:17:37 GMT

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.

Re: how to explain the following ?

the_rock — Mon, 10 Jun 2024 17:19:32 GMT

@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-p/216402#M35976

Re: how to explain the following ?

PhoneBoy — Mon, 10 Jun 2024 18:59:08 GMT

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.

Re: how to explain the following ?

Gongya_Yu — Mon, 10 Jun 2024 20:30:01 GMT

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

thanks so much !!

Re: how to explain the following ?

the_rock — Mon, 10 Jun 2024 22:06:00 GMT

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

Re: how to explain the following ?

PhoneBoy — Mon, 10 Jun 2024 22:49:25 GMT

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.

Re: how to explain the following ?

the_rock — Mon, 10 Jun 2024 23:07:03 GMT

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

Re: how to explain the following ?

Gongya_Yu — Tue, 11 Jun 2024 00:38:04 GMT

thanks !!

Re: how to explain the following ?

Gongya_Yu — Tue, 11 Jun 2024 00:40:04 GMT

thanks a lot !!

Re: how to explain the following ?

emmap — Tue, 11 Jun 2024 01:53:11 GMT

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.

Re: how to explain the following ?

Gongya_Yu — Tue, 11 Jun 2024 04:17:52 GMT

"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 ?

Re: how to explain the following ?

the_rock — Tue, 11 Jun 2024 14:40:56 GMT

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

Andy

Re: how to explain the following ?

Gongya_Yu — Tue, 11 Jun 2024 15:29:59 GMT

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.

Re: how to explain the following ?

the_rock — Tue, 11 Jun 2024 16:07:32 GMT

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