> Source: [sk113479](https://support.checkpoint.com/results/sk/sk113479) # sk113479 - Logs from a Security Gateway show "Connection terminated before" in the "Reason" field | Property | Value | |----------|-------| | Solution ID | sk113479 | | Date Created | 2016-09-21 | | Last Modified | 2025-02-11 | | Technical Level | General | | Products | Security Gateway, Scalable Platforms | | Versions | R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS), R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS) | ## Symptoms - The Security Gateway log in SmartConsole / SmartView shows one of these messages in the "**Reason**" field: * `Connection terminated before the Security Gateway was able to make a decision` (from a Security Gateway R81.10 and higher) * `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` ## Solution **No fix or workaround is required. This behavior is by design (see the "Explanation" section).** **On Security Gateways R81.10 and higher, you can enable the "Reason" field of a log card to show more information (see the "Extended Reason" section).** ### Explanation > **Important Notes:** > > * The Security Gateway did not drop the connection. > * There is no drop print in the kernel debug. > * The reason for the log is not necessarily because of unwanted behavior of the edge client or the server. > > A Unified Policy can 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 occurs on the following data packets. Until the final decision is reached, the rule base accepts the incoming data packets if a rule allows it (meaning: if one of the possibly matched rules does not have a Drop/Reject action). > > In scenarios where the connection ends without application data content (no data packets), or the data quantity is not sufficient for the required engine detection, the rule base issues an Accept log with the first rule that allows the traffic. This rule might not have all the applicable criteria because some have not been detected. > > The corresponding log contains one of these "Reason" strings: > > |---------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | **Reason Message** | **Explanation** | > | `Connection terminated before detection: No TCP payload` | The TCP connection was established, but after the 3-way handshake, packets containing data did not arrive 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 server. | > | `Connection terminated before detection: No SSL applicative data` | The SSL handshake started or finished, but packets containing encrypted applicable data have not arrived at the Security Gateway. | > | `Connection terminated before detection: Insufficient data` | Data packets arrived, but the data quantity was not sufficient for engine detection. The string states the number of data bytes (TCP/UDP payload) that can pass the Security Gateway. | > | `Connection terminated before the Security Gateway was able to make a decision` | See the section "Improvements in versions R81.10 and higher" below | > > Watch this video for a detailed explanation: > Show the Entire Article ### Improvements in versions R81.10 and higher Show / Hide this section * To make the "**Reason**" message clearer, the text changed to: `Connection terminated before the Security Gateway was able to make a decision: ... To learn more see sk113479` **Example:** > `Connection terminated before the Security Gateway was able to make a decision:` > ` > Insufficient data passed.` > ` > To learn more see sk113479.` * If the Access Control Rulebase does not reach a final match to a rule with the "Accept" action, then the Security Gateway generates a log with a new unique rule specific for this case '`CPNotEnoughDataForRuleMatch`' and the "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 the "Accept" action?** 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. **Note** - If the first layer in the Access Control Rulebase does not reach a final match to a rule with the "Accept" action, the new unique rule also appears in the main log card section, not only in the "`Matched rules`" section. **Example:** > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk113479/log_Card_example202102041548333.jpeg) * In the "`Matched Rules`" section of the log, for each Access Control Policy Layer that does not reach a final match to a rule with the "Accept" action, there is a new unique rule **name**(the rule number does not appear). **Example:** > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk113479/matched_rules_fixed202102041547552.jpeg) ### How to Enable / Disable the "Reason" Log Messages Show / Hide this section > * On Security Gateways R81.10 and higher: > > By design, the log card always contains the "`Reason`" section for each connection that does not reach a final match to a rule with the "Accept" action. > * On Security Gateways R81 and lower: > > Use the kernel parameter "`up_log_reason_for_incomplete_match`". > * To enable the "Reason" log messages, set the value of this kernel parameter to `1` (one) on the Security Gateway / each Cluster Member: > > `fw ctl set -f int up_log_reason_for_incomplete_match 1` > * To disable the "Reason" log messages, set the value of this kernel parameter to `0` (zero) on the Security Gateway / each Cluster Member: > > `fw ctl set -f int up_log_reason_for_incomplete_match 0` > > **Example from a log card:** > > `Connection terminated before the Security Gateway was able to make a decision:` > > ` > > Insufficient data passed.` > > ` > > To learn more see sk113479.` ### Extended Reason Show / Hide this section > The logs from Security Gateways R81.10 and higher can show more information in "`Reason`" field of a log card. This extended information in the "`Reason`" field explains why the traffic reached the "Finalize rulebase" flow. > > * To enable the extended reason text in logs, set the value of this kernel parameter to `1` (one) on the Security Gateway / each Cluster Member / Scalable Platform Security Group: > > `fw ctl set -f int up_log_extended_reason_for_incomplete_match 1` > * To disable the extended reason text in logs, set the value of this kernel parameter to `0` (zero) on the Security Gateway / each Cluster Member / Scalable Platform Security Group: > > `fw ctl set -f int up_log_extended_reason_for_incomplete_match 0` > > In addition to the "regular" reason message, the extended reason message includes: > > * The first Policy Layer in the Access Control Rulebase that does not reach a final match to a rule with the "Accept" action and its first possible rule. > > * A list of the missing required Classifier Objects (CLOB) for this connection. > > There may be no missing CLOBs in the extended reason. Before this log is generated, some observers (for example, Application Control, Identity Awareness) are asked if they have new CLOBs to notify. > > If there are new CLOBs, a final Access Control Rulebase run is attempted. After this final run, the Security Gateway can, for example, reach a final match to a rule with the "Drop" action. As a result, the log shows "`Connection terminated before..`", but there are no missing CLOBs. > > **Example 1 from a log card:** > > `Connection terminated before the Security Gateway was able to make a decision: Insufficient data passed.` > > ` > > To learn more see sk113479.` > > ` > > First possible rule:` > > ` > > Layer: Network, Rule: 12.` > > ` > > Missing classifier objects:` > > ` > > None` > > > > In this example log, "`Network`" is the first Policy Layer in the Access Control Rulebase that does not reach a final match to a rule with the "Accept" action. > > The first possible rule in this Policy Layer is the rule number 12. > > There are no missing Classifier Objects (CLOBs). > > **Example 2 from a log card:** > > `Connection terminated before the Security Gateway was able to make a decision:` > > ` > > Insufficient data passed.` > > ` > > To learn more see sk113479.` > > ` > > First possible rule:` > > ` > > Layer: pre_Network, Rule: 2.` > > ` > > Missing classifier objects:` > > ` > > <1: APPLICATION> <16: XFF_SOURCE_ACCESS_ROLE> <26: PROTOCOL> <41: FILE> <42: CONTENT> <43: DIRECTION>.` > > > > In this example log, "`pre_Network`" is the first Policy Layer in the Access Control Rulebase that does not reach a final match to a rule with the "Accept" action. > > The first possible rule in this Policy Layer is the rule number 2. > > In addition, there is a list of the missing Classifier Objects (CLOBs) - Application, XFF Source Access Role, Protocol, File, Content, Direction. > > **CLOB Table:** > > These CLOBs might appear in the extended reason in the "`Connection terminated before the Security Gateway was able to make a decision`" logs: > > |---------|--------------------------|---------------------|-------------------------------------------------------------------------------------------| > | CLOB ID | CLOB Name | Software Blade | Explanation | > | 1 | `APPLICATION` | Application Control | Matched the Application/Site object | > | 16 | `XFF_SOURCE_ACCESS_ROLE` | Identity Awareness | Matched a Source IP address from the "X-Forwarded-For" header to the HTTP request headers | > | 26 | `PROTOCOL` | Application Control | Matched the signature | > | 40 | `CONTENT_FILE` | Data Awareness | Matched Content and the File type | > | 41 | `FILE` | Data Awareness | Matched a File type | > | 42 | `CONTENT` | Data Awareness | Matched the Type of content | > | 43 | `DIRECTION` | Data Awareness | File transfer direction ("`up`" for upload, "`down`" for "download") | ### Light Kernel Debug Show / Hide this section > The light kernel debug gives concise and important information about the "`Connection terminated before...`" flow. > > This light kernel debug is available in: > > * R81.10 and higher > * R81 Jumbo Hotfix Accumulator Take 51 and higher > > For the complete kernel debug procedure, see the [Security Gateway Guide](https://support.checkpoint.com/product/73) for your version \> Chapter "Kernel Debug". > > In the kernel debug procedure, enable these debug flags: > > `fw ctl debug -m UP + probtrc info` > > **Example of a debug output:** > > ` > > [fw4_4];===> FINALIZE rulebase START (0x7fd84da36008).;` > > ` > > [fw4_4]; Required CLOBS: [<1: APPLICATION> <16: XFF_SOURCE_ACCESS_ROLE> <26: PROTOCOL> <41: FILE> <42: CONTENT> ];` > > ` > > [fw4_4]; Active CLOBS: [<1: APPLICATION> <16: XFF_SOURCE_ACCESS_ROLE> <26: PROTOCOL> <41: FILE> <42: CONTENT> ];` > > ` > > [fw4_4]; Layer 'pre_Network'. Possible rules: { 2 3 4 };` > > ` > > [fw4_4]; Saving first possible layer and rule: [pre_Network, 2];` > > ` > > [fw4_4]; Layer 'first_inline'. Possible rules: { 1 2 4 5 };` > > ` > > [fw4_4];<=== FINALIZE rulebase END (0x7fd84da36008).; > > ` > > Explanations: > > * The connection enters the '`Finalize rulebase`' flow and does not reach a final match to a rule with the "Accept" action. > > * There is a list of the required and active CLOBs. For example, "`APPLICATION`" and "`PROTOCOL`". > > * There is a list of the layers that do not reach a final match to a rule with the "Accept" action. > > * Each layer has a list of possible rules. --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content