> Source: [sk184786](https://support.checkpoint.com/results/sk/sk184786)

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

| Property | Value |
|----------|-------|
| Solution ID | sk184786 |
| Date Created | 2026-03-12 |
| Last Modified | 2026-07-23 |
| Technical Level | General |
| Products | Security Gateway, Scalable Platforms |
| Versions | R82.10, R82, R81.20, R81.10 (EOS), R82.10, R82, R81.20, R81.10 (EOS) |

## 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](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82.10/Default.htm) starting from Take 36
* [Jumbo Hotfix Accumulator for R82](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/Default.htm) starting from Take 118
* [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 158

If you choose not to upgrade, Check Point can supply a **Hotfix** . [Contact Check Point Support](https://www.checkpoint.com/support-services/contact-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](http://supportcontent.checkpoint.com/solutions?id=sk92739) from the Security Management Server and Security Gateways involved in the case.

**Hotfix installation instructions:**   
Refer to [sk168597 - How to install a Hotfix](https://support.checkpoint.com/results/sk/sk168597).

**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`

---

# 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