Intermittent "First packet isn't SYN" drops on a Maestro Security Group

Product

Maestro HyperScale Firewall, Security Gateways

Version

R81.10 (EOS), R81.20, R82, R82.10

Last Modified

2026-07-23

Symptoms

• In a Scalable Platform Security Group, the output of the commands "asg search" and "dxl" may show that return traffic is distributed to a different Security Group Member (SGM) than the one that processed the initial packet.

Return traffic may be dropped with the message:

First packet isn't SYN

• In ClusterXL, similar drops may occur after a cluster failover.

• In both Scalable Platform Security Groups and ClusterXL, debug output may show incorrect synchronization flags for some firewall instances.

The output in $FWDIR/log/fwk.elg or dmesg may contain entries similar to these after running cphaconf debug_data:

[fw4_12]fwlddist_get_stat: sending state: 1a;

[fw4_13]fwlddist_get_stat: sending state: 1a;

[fw4_14]fwlddist_get_stat: sending state: 1a;

[fw4_15]fwlddist_get_stat: sending state: 1a;

[fw4_16]fwlddist_get_stat: sending state: 21a;

[fw4_17]fwlddist_get_stat: sending state: 21a;

[fw4_18]fwlddist_get_stat: sending state: 21a;

[fw4_19]fwlddist_get_stat: sending state: 21a;

Or:

[vs_0];fwlddist_state is (1a): Receiving, Not Saving, Sending

[vs_0];fwlddist_state is (1a): Receiving, Not Saving, Sending

Cause

During a zero-downtime cluster upgrade, Multi-Version Cluster (MVC) maintains traffic flow while cluster members run different software versions.

After upgrading the first cluster member, the number of CoreXL firewall instances may change.

For example, in R81.20SP, Dynamic Balancing is enabled automatically, which may increase the number of CoreXL instances.

Because the second cluster member has not yet been upgraded, it continues to operate with fewer CoreXL instances.

This mismatch causes firewall instances on the upgraded member that exceed the number of instances on the pre-upgrade member to be assigned an incorrect synchronization state.

Solution

This problem was fixed. The fix is included in:

• Jumbo Hotfix Accumulator for R82.10 starting from Take 36
• Jumbo Hotfix Accumulator for R82 starting from Take 118
• Jumbo Hotfix Accumulator for R81.20 starting from Take 158

If you choose not to upgrade, Check Point can supply a Hotfix. 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 Server and Security Gateways involved in the case.

Hotfix installation instructions:

Refer to sk168597 - How to install a Hotfix.

Mitigation:

Perform a corrective synchronization reset on the applicable SGMs. After the reset, all firewall instances should correctly report the full synchronization state ( 1a). After you restore synchronization, traffic distribution and stateful inspection behavior return to normal.

Procedure:

1. Connect to the CLI on the Security Group.
2. If your default shell is gclish mode, switch to Expert Mode:

expert 3. Isolate the affected SGMs. On each affected SGM (for example, 1_02 and 1_03), run this command to verify the synchronization flag:

cphaconf debug_data; grep -E 'fwlddist_(state|get_stat)' $FWDIR/log/fwk.elg

Note: If any output does not show the correct flag 1a, the SGM is affected. 4. Bring the cluster member down:

clusterXL_admin down 5. Reset synchronization:

fw ctl setsync off

fw ctl setsync start 6. Validate the synchronization state:

cphaconf debug_data; grep -E 'fwlddist_(state|get_stat)' $FWDIR/log/fwk.elg

Note: All firewall instances must report: state: 1a. 7. Bring the cluster member back up:

clusterXL_admin up

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Article Properties

Access Level: General

Status: Approved by TAC

Date Created: 2026-03-12

Last Modified: 2026-07-23