- CheckMates
- :
- Products
- :
- General Topics
- :
- how to explain the following ?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
how to explain the following ?
why does CP treat them differetly ?
The second and the third packets are dropped ?
thanks !!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Bob_Zimmerman explained it PERFECTLY below, which was also your question btw 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How do the same source, destination, and port using the same firewall rules get different filtering ? timing ? payload or etc ?
thanks so much !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks a lot !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I cant sadly find it, as its been some time, but it was very similar to what Phoneboy sent you.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Last question for this.
- Drop at last
- Might drop or might accept conditionally at last
- Accept at last
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Accept means it was allowed.
The connections should be successful in all cases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
EXACTLY! Thats section of the sk that explains it.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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