The information you are about to copy is INTERNAL!
DO NOT share it with anyone outside Check Point.
"Connection terminated before detection" in log reason for Unified Rulebase
Quantum Security Gateways
R80.10 (EOL), R80.20, R80.30, R80.40, R81, R81.10
Platform / Model
The connection is terminated before detection of required filter criteria. The log shows the following reasons:
"Connection terminated before detection: No TCP payload."
"Connection terminated before detection: No UDP payload."
"Connection terminated before detection: No SSL applicative data."
"Connection terminated before detection: Insufficient data."
Or starting at R81.10 it shows the following:
"Connection terminated before the Security Gateway was able to make a decision: ..."
This is an expected behavior.
Important notes: - The Security Gateway did not drop the connection. - There will be no drop print in the debugs. - The log is not necessarily due to unwanted behavior of the edge client or the server.
A Unified Policy may contain filter criteria that cannot be resolved on the connection's first packet, such as Application or Data. Therefore, on some connections, the final rule match decision will occur on the following data packets. Until the final decision is reached, the incoming data packets are accepted by rule base, if there is a rule that allows it (meaning if one of the possibly matched rules is not with Drop/Reject action).
In scenarios in which the connection ends without application data content at all (no data packets), or the amount of data is not enough for the required engine detection, the rule base will issue an Accept log with the first rule that allows the traffic. This rule may not have complete adequacy with all the applicative criteria because some of them have not been detected yet.
The corresponding log will contain one of the following Reason strings:
Connection terminated before detection: No TCP payload.
The TCP connection was established but after the 3-way handshake, packets containing data have not arrived from one of the sides (client or server).
Connection terminated before detection: No UDP payload.
UDP packets containing data have not arrived from the client or from the server.
Connection terminated before detection: No SSL applicative data.
The SSL handshake has started or finished, but packets containing encrypted applicative data have not arrived at the Gateway.
Connection terminated before detection: Insufficient data. <X> bytes passed
Data packets have arrived, but the amount of data was not enough for the engine detection. The string will also state the number of data bytes (TCP/UDP payload) that may pass the Gateway.
The following video explains on what is possible match and on the mentioned logs -
Post R81.10 + jumbo takes (to be updated):
We wanted to make this flow more clear and understandable, therefore we decided to change the code logic and the log card information.
1. In order to make the 'Reason' message more clear, the text was changed to: "Connection terminated before the Security Gateway was able to make a decision: ... To learn more see sk113479." Example -
2. In case the Access Rulebase did not reach final match on accept, we will give a log with a new unique rule specific for this case 'CPNotEnoughDataForRuleMatch' and accept action. - Why new unique rule? Since the connection did not reach final match, we can't tell for sure which rule this connection should have match in case it would not terminate before detection. Thus, so we won't give a confusing rule in the log, we decided to give new unique rule which will indicate that this traffic reached "Connection terminated before..." flow. - Why accept? The Security Gateway did not drop the connection, the connection got terminated before a final match. The Security Gateway did accept the connection first packet (The rulebase was in possible match state). Therefore we give the log as accept, so it will reflect that the traffic of the first packet was accepted due to possible match. * In case the first layer in the Access Rulebase did not reach final match on accept rule, the new unique rule will appear in the main log card section also (and not only in the 'matched rules' section). Example -
3. In the 'Matched Rules' section in the log, for each layer that did not reach final match on accept rule, we will use our new unique rule name (rule number will not show). Example -
1. Pre R81.10 : The kernel parameter that controls if these messages (Connection terminated before detection: XXXXX) are seen within the logs is: up_log_reason_for_incomplete_match
it needs to be set to "1" for these messages to be seen: fw ctl set int up_log_reason_for_incomplete_match 1
2. Post R81.10 : up_log_reason_for_incomplete_match does not exist anymore. We will give the 'Reason' section in the log for each connection that did not reach final match on accept.
> Extended Reason: For extended reason in the log, use kernel parameter up_log_extended_reason_for_incomplete_match
it needs to be set to "1" for these extended reason to be seen: fw ctl set int up_log_extended_reason_for_incomplete_match 1
Other than the 'regular' reason message, the extended reason also includes - A. List of the missing required classifier objects (clobs) for this connection. B. The first layer in the Rulebase that did not reach final match on accept rule and it's first possible rule.
In the example we can see that pre_Network is the first layer in the Access Rulebase that did not reach final match on accept rule. Also it's first possible rule is rule number 2. We can also see a list of the missing clobs - Application, XFF Source Access Role, Protocol, File, Content, Direction.
This extended information helps us to better understand why this traffic reached the "Finalize rulebase" flow on the first place. Moreover, in case of tasks we (or TAC/support/CFG) could detect faster whether it's legit log or not.
Notes: 1) It's possible that in the extended reason there will be no missing clobs. How? Before we give this log, we ask certain observers (e.g. APPI IDA Protocol) whether they have new clobs to notify. In case that we have new clobs, we will try one final Rulebase run. After this final run, we can for example reach a final match on Drop, so we still will give the "Connection terminated before.." log, but there will be no missing clobs. Example -
2) It's possible that the "First possible rule" is a drop rule and that's ok.
3)Clobs table: The following clobs might appear in the extended reason for the "Connection terminated before..." logs:
Source IP from the 'X-Forwarded-For' header in the HTTP request headers.
Content + File type.
Type of content.
Whether it's in or out going traffic.
(Note - it can happen due to more type of clobs but it's more rare so we decided to skip those)
> Light debugs (this flag is only available in R81.10 and R81 with Jumbo Take 51 or higher): New 'light' debugs which gives concise and important information for the 'Connection terminated before...' flow. How to activate: Add the following debug flags - 'fw ctl debug -m UP + probtrc info'. Example of debug prints -
From the debugs we can learn - - The connection entered the 'Finalize rulebase' flow and it didn't reach a final match on accept. - We can see the list of the required and active clobs, for example APPLICATION PROTOCOL and more. - We can see a list of the layers that did not reach full match on accept. - For each layer we can see a list of it's possible rules.
Since this debug flag is only available in R81.10 and R81 w/ Jumbo Take 51 or higher, other versions will have to use alternate debug flags in the UP module.
Give us Feedback
Thanks for your feedback!
Are you sure you want to rate this stars?