Kernel debug shows that TCP traffic is "<code>dropped by fwhold_expires Reason: held chain expired</code>"

Support Center > Search Results > SecureKnowledge Details

Kernel debug shows that TCP traffic is "dropped by fwhold_expires Reason: held chain expired" Technical Level

Solution ID	sk44711
Technical Level
Product	Quantum Security Gateways, ClusterXL, Cluster - 3rd-party, VSX
Version	R80.20 (EOL), R80.30 (EOL), R80.40, R81, R81.10, R80.20.x, R81.10.x
Platform / Model	All
Date Created	13-Oct-2010
Last Modified	18-Mar-2023

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

The Security Gateway inspects incoming packets and decides to accept/drop/reject them. Sometimes, the Security Gateway needs more information (authentication, database updates, etc.).

A hold kernel table mechanism in the Check Point kernel keeps a packet and waits for additional information to arrive. An expiration timer controls how long the Security Gateway waits for the additional information before it deletes the packet.

The drop message "Reason: held chain expired" shows that the packet was discarded since the additional data did not arrive in time.
The message "Reason: held chain expired" can be followed by the message "Reason: Rulebase drop - rule N;", where N is the number of a rule with "Action" set to "accept". In this case, the involved rule can contain the Domain Object.

For each packet that is matched by the rule with the Domain Object, the Security Gateway needs to perform a Reverse DNS Query to see if the Source IP address / Destination IP address (depends 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 at or near the top of the rulebase, then the Security Gateway could potentially perform a DNS lookup on almost every packet. If the involved rule with Domain Object is located at or near the bottom of the rulebase, the timeout for holding the packet could expire before a reply from the DNS Server arrives.

Though it is possible to adjust the hold timer, Check Point strongly does not recommend this because it addresses only the symptom and not the problem.

Solution

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