Who rated this post

It appears that Checkpoint has issued sk148432 for this issue.  The recommendation is to apply a hotfix.

Symptoms

• The following drop is seen in /var/log/messages file:
  [kern];[tid_0];[SIM-];simi_reorder_enqueue_packet: reached the limit of maximum enqueued packets for conn

Cause

As part of the changes made in R80.20, SecureXL behave asynchronicaly with the Firewall. This means that Firewall and SecureXL might handle the connections separately. In order to avoid situation where SecureXL forward packets to the network before the FW finished the inspection, SecureXL will hold the packets in a queue, so we will have order for the packets.

This new mechanism is called: "simi_reorder".

In case that the queue is full, all the packets will be released and dropped. The main impact is for UDP packets, as TCP will never get the queue to be full.

Solution

Contact Check Point Support to get a Hotfix for this issue. 
A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix. 
For faster resolution and verification please collect CPinfo files from the Security Management and Security Gateways involved in the case.

There are 2 SIM module kernel parameters which control this bevaviour (please refer to sk147392, on how to set the SIM parameters) :

1. simi_reorder_max_packets
2. simi_reorder_hold_udp_on_f2v

simi_reorder_max_packets is controlling the maximum packets which the Q can hold - it is less recommended to change it, as it will consume additional memory, depending on how much the Q is increased.

simi_reorder_hold_udp_on_f2v controls the mechanism for UDP packets, it's value could be 0 or 1. 1 will enable the simi_reorder mechanism for UDP packets, 0 will disable it, so all the packets will be sent for the network, and might have some asynchronism between FW and SecureXL.

The hotfix is changing the mechanism behavior, in a way that when the queue is full, the packets will be released and not dropped.