Support Center > Search Results > SecureKnowledge Details
Kernel debug shows that TCP traffic is "dropped by fwhold_expires Reason: held chain expired"
Symptoms
  • Kernel debug ('fw ctl debug -m fw + drop') shows that TCP traffic is dropped:

    fw_log_drop: Packet proto=6 Source_IP:Source_Port -> Dest_IP:Dest_Port dropped by fwhold_expires Reason: held chain expired

    Example - Traffic is dropped on a rule with "Action" set to "accept":

    ;fw_log_drop_ex: Packet proto=6 192.168.10.20:61196 -> 172.16.30.40:443 dropped by fwhold_expires Reason: held chain expired;
    ;fw_log_drop_ex: Packet proto=6 192.168.10.20:61197 -> 172.16.30.40:443 dropped by fw_handle_first-packet Reason: Rulebase drop - rule N;
    ;fw_log_drop_ex: Packet proto=6 192.168.10.20:61198 -> 172.16.30.40:443 dropped by fw_handle_first-packet Reason: Rulebase drop - rule N;
    ;fw_log_drop_ex: Packet proto=6 192.168.10.20:61199 -> 172.16.30.40:443 dropped by fw_handle_first-packet Reason: Rulebase drop - rule N;
    
Cause
  1. When the Security Gateway receives a packet, it inspects the packet to decide whether to accept/drop/reject the packet. Sometimes, more information is required to make the decision (authentication, database updates, etc.).

    There is a mechanism in the Check Point kernel, which is used to keep a packet until the additional information arrives (a hold kernel table).
    When Security Gateway waits for the additional data, there is an expiration timer that controls when the packet should be discarded in case the additional required data does not arrive.

    The drop message "Reason: held chain expired" indicates that this hold had expired, and the packet was discarded since the additional data did not arrive in time.

  2. The message "Reason: held chain expired" might be followed by the message "Reason: Rulebase drop - rule N;", where N is the number of a rule with "Action" set to "accept". In such case, the involved rule might contain Domain Object.
    For each packet that is matched by the rule with the Domain Object, Security Gateway needs to perform a Reverse DNS Query to see if the Source IP address / Destination IP address (depending on how the rule is constructed) matches the Domain Object.

    The resolved results are cached, but not indefinitely. Each time the Security Gateway performs this lookup, it has to hold the packet until it gets a reply from the DNS Server.

    If the involved rule with Domain Object is located towards the top of the rulebase, then Security Gateway could be potentially performing a DNS lookup on almost every packet. If the involved rule with Domain Object is located towards the end of the rulebase, the timeout for holding the packet might expire before a reply from the DNS Server arrives.

While adjusting the hold timer is possible, it is strongly not recommended, because it will address only the symptom and not the problem.
Understanding what information the Security Gateway is waiting for, and why it is timing out is paramount.


Solution
Note: To view this solution you need to Sign In .