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

# sk177603 - ATRG: CME (Cloud Management Extension) for Cloud Firewall

| Property | Value |
|----------|-------|
| Solution ID | sk177603 |
| Date Created | 2022-02-15 |
| Last Modified | 2026-05-07 |
| Technical Level | General |
| Products | Security Management Server, Multi-Domain Security Management Server, Cloud Firewall |
| Versions | R82.10, R82, R81.20, R82.10, R82.10, R81.10 (EOS), R81.10 (EOS), R81.10 (EOS), R81.20, R82, R81.20, R82 |
| OS | Gaia |
| Platform | AWS, Azure, GCP, OCI |

## Solution

**Introduction \| Glossary \| FAQ \| Troubleshooting**  
Click Here to Show the Entire Section

Introduction {#Introduction}
----------------------------

**CME (Cloud Management Extension)** for Cloud Firewall (formerly CloudGuard Network) is a tool that runs on Check Point's Security Management Server and Multi-Domain Servers.

CME allows cloud-native integration between Check Point Cloud Firewall solutions and Cloud platforms.

As a service, it continuously monitors Cloud Firewall solutions deployed at different cloud vendors and synchronizes them with the Security Management Server.

**For additional information about CME, refer to:**

* [Cloud Management Extension (CME) Administration Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Default.htm)
* [CME for Cloud Firewall - Latest Updates](https://support.checkpoint.com/results/sk/sk157492)

Glossary {#Glossary}
--------------------

This section details the definitions of the main terms used in CME. For more details, refer to the related Check Point documentation.

**Scale set** - A cloud resource that is used to deploy and manage identical Virtual Machines (VMs) groups. The Scale Sets increase or decrease the number of Virtual Machines based on the current needs. This article refers to Scale Set as a resource composed of Cloud Firewall Security Gateways.   
The Scale Sets are [VMSS](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview) for Azure, [Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) for AWS (Amazon Web Services), [MIG](https://cloud.google.com/compute/docs/instance-groups) for GCP (Google Cloud Platform), and [Instance Pool](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/autoscalinginstancepools.htm) for OCI (Oracle Cloud Infrastructure).

**Management**- Check Point Security Management Server or Check Point Multi-Domain Management Server.

Frequently Asked Questions {#FAQ}
---------------------------------

<br />

Click Here to Show the Entire Section

* How do I know that CME is installed?  
  Run:  
  `$ autoprov_cfg -v`  

  Valid response: *CME Version: Build: X Take: Y*   

  Alternatively, use the following CME API: `/generalConfiguration/cmeVersion`.  
  Valid response:  
  `{`  
  ` "result": {`  
  ` "take": "<take number>"`  
  ` },`  
  ` "status_code": 200`  
  `}`

  If you receive a valid response, it means that CME has been installed.  
  If not, follow the installation instructions in [sk157492](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk157492&partition=Advanced&product=Cloud Firewall) to install CME.
* How do I know that CME is configured correctly?  
  After you make sure that CME is installed, run the command:  
  `$ autoprov_cfg show all`
  * If the output is:

    "`configuration file was not initialized, please use init`"

    It means CME is not configured correctly.

    Refer to the relevant Administration guide mentioned above to configure CME.
  * When CME is configured correctly, the output contains the following mandatory sections.

    1. Controllers

    2. Delay

    3. Management

    4. Templates

    To make sure CME is configured correctly:
    * Run the tester:   
      `$ service cme test`   
      and make sure it passes the test.

    * Make sure there are no errors in */var/log/Cpcme/cme.log*.

* How can I check which CME values are inserted during the Scale Set deployment?  
  * **Azure**

    1. Click on the VMSS resource.

    2. Click on Tags.

       ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk177603/cme_atrg_azure_tags202202100936383.png)
  * **AWS**

    1. Click on Auto Scaling Groups.

    2. Click on the Auto Scale Group.

    3. Scroll to the bottom.

       ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk177603/cme_atrg_aws_tags202202161549531.png)
  * **GCP**

    1. Click on one MIG instance.

    2. The values are under Network tags.

       ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk177603/cme_atrg_gcp_tags202202100937255.png)

  The relevant tags are:
  * **x-chkp-template** - CME template name.

  * **x-chkp-management** - CME management name.

  * **x-chkp-ip-address** - public/private -- Indicates the communication type between the management and the scale set.

  * **x-chkp-management-interface** - Indicates the gateway interface that the management will communicate to.

* How do I open a ticket with Check Point support?  
  1. Collect the CME Log Collector file as described in [Cloud Management Extension (CME) Administration Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Default.htm) \> Troubleshooting \> CME Log Collector.

  2. [Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) and request to open a ticket that includes the CME Log Collector file collected in the previous step.

* How to return to the previous version of CME?  
  **Solution**: It is highly recommended that you use the latest CME Take.

  If you still want to revert to the previous Take, run this command in Expert mode on the Security Management Server:   
  `$ autoupdatercli revert CME`

  The revert takes up to 1 minute to complete.

  To make sure CME was reverted to the previous take, run this command in Expert mode on the Security Management Server:

  `$ cpinfo -y CPUpdates 2>&1 | grep BUNDLE_CME_AUTOUPDATE`

  The Take number in the output must be the one to which you reverted.

  **Notes**:
  * CME is upgraded automatically each time the new Take is released.
  * You can revert only to the previous version. Reverting to older versions completely reverts CME and removes it from the Security Management Server.
* How to totally remove CME?  
  **Solution**: Run this command in Expert mode on the Security Management Server:

  `$ autoupdatercli revert-completely CME`

  The removal operation takes up to 1 minute to complete.

  To make sure the CME was uninstalled completely, run this command in Expert mode on the Security Management Server:

  `$ cpinfo -y CPUpdates 2>&1 | grep -c BUNDLE_CME_AUTOUPDATE`

  The output must show "0".

  If you also want to stop receiving future CME updates after the removal, run this command in Expert mode on the Security Management Server:

  `$ autoupdatercli disable CME`

<br />

*** ** * ** ***

<br />

Troubleshooting {#Troubleshooting}
----------------------------------

**Table of Contents:**

|----------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------|
| * **General Issues** * **Installation Failure Issues** * **Policy and Database Issues** * **Error messages in the cme.log file** | * **CME API Errors** * **GCP (Google Cloud Platform) Issues** * **AWS (Amazon Web Services) Issues** * **Azure Issues** |

<br />

Click Here to Show the Entire Troubleshooting Section

### General Issues {#General Issues}

* Scenario 1: Logs are not sent to the Log Server.  
  > **Symptom** : User defined a Log Server using the *-sl* flag, but logs are not sent to the Log Server.  
  >
  > **Cause** : CME does not install database automatically on Log servers after provisioning.   
  >
  > **Solution** :
  > 1. Install [CME Take 250](https://support.checkpoint.com/results/sk/sk157492) or higher.
  > 2. Reconfigure the existing Log Server configurations (once per template). For instructions, see "[Examples of using Log Servers parameters.](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/CME_Structure_and_Configurations.htm?tocpath=CME%20Structure%20and%20Configurations%7C_____0#Examples)"
* Scenario 2: The `autoprov_cfg` command fails with "*error: argument \<Argument Name\>: expected one argument*".  
  > **Cause** : When using a hash symbol (#), a dollar sign symbol ($), or a dash symbol (-) at the start of a parameter value, the `autoprov_cfg` command fails.  
  >
  > Example:   
  >
  > The `autoprov_cfg add controller AWS -cn #name` command fails with "*error: argument -cn: expected one argument* ".   
  >
  > **Solution** :  
  > Use the equal sign (=) as a prefix for the parameter value.  
  >
  > Example:  
  > *# autoprov_cfg add controller AWS -cn=#name*
* Scenario 3: Scale-in operation fails with: "*Object \<Gateway Name\> could not be deleted because it is referenced by other objects, run where-used command for details* " message in */var/log/CPcme/cme.log*.  
  > **Cause** : The Host object was created manually and used in another policy.  
  >
  > **Solution**: Manually remove this object and wait for a few minutes for CME to complete the scale-in operation.
* Scenario 4: CME deletes the Security Gateway that was not scaled in.  
  > **Cause** : CME deletes Security Gateways if the relevant Controller does not have permissions for the relevant resource groups. CME does not pull the relevant VMSS resources and concludes that they are missing and can be deleted from the Security Management Server.   
  >
  > **Solution** :
  > 1. To avoid instances to be deleted, stop CME services by running:  
  >    ` # service cme stop`
  > 2. Check that the Controller has permission to the relevant resource group that contains the VMSS instances.
  > 3. Run service CME test and examine the output of the API call to understand which VMSS resources the Controller has permissions to.
  > 4. Start the CME service with `# service cme start`.
  > 5. To re-add the deleted Security Gateways to the Security Management Server, scale out new instances and scale in the deleted instances manually.
* Scenario 5: The Multi-Domain Management Server cannot manage Scale Set instances through a public IP address.  
  > **Symptoms:**
  > * Connectivity issues causing TCP timeout.
  > * Policy installation fails.
  > * Not possible to establish SIC.
  >
  > **Solution** : In the Scale set deployment, set the Management interface for the Scale set to be the private IP address (the Security Management Server must have access to this address):
  > * [sk174186 - Multi-Domain Management Deployment on Google Cloud Platform](https://support.checkpoint.com/results/sk/sk174186)
  > * [sk143213 - Multi-Domain Management Deployment on AWS](https://support.checkpoint.com/results/sk/sk143213)
  > * [sk154436 - Multi-Domain Management Deployment on Azure](https://support.checkpoint.com/results/sk/sk154436)
* Scenario 6: CME does not find public IP addresses for a Scale Set.  
  > **Symptoms:**
  > * CME does not provision Gateways that are up and running.
  > * The */var/log/CPcme/cme.log* file shows:  
  >   `VMSS <VMSS Name, is managed by public IP address through eth1`  
  >   `There is no address for <Gateway Name>`
  >
  > **Cause** :   
  > The tags of the scale set were changed incorrectly. For example, a scale set was deployed with a backend NIC for the Management interface by mistake. Trying to fix that, the resource tags were changed incorrectly. **Solution** :   
  > Make sure that both tags: *x-chkp-ip-address* and *x-chkp-management-interface* are correct. For public IP communication, it should be *x-chkp-ip-address: public and x-chkp-management-interface: eth0*

<br />

### Installation Failure Issues {#Installation Failure Issues}

* *Scenario 1: Installation failed with the error message "*Failed to download the latest CME package.* If you have no internet access, please follow the instructions for offline installation in sk157492.*"  
  > **Solution:** CME package failed to download. Make sure there is a connection to the Internet, or follow these steps for offline installation:
  > 1. Connect to the command line on the Security Management Server.
  >
  > 2. Log in to Expert mode.
  >
  > 3. Get the AutoUpdater Build Number:
  >
  >    `$ cpvinfo /opt/AutoUpdater/latest/bin/AutoUpdater | grep "Build Number"`
  >
  >    If the value of the "*Build Number* " in the output is lower than 990180162, do the procedure for **Issue # 3** and only then continue with the next steps below.
  > 4. Get the latest CME version from the "Availability" section.
  >
  > 5. Transfer the CME package to the Security Management Server (to some directory).
  > 6. Run:
  >
  >    `$ autoupdatercli install /<Full Path>/<Name of Package>`
* Scenario 2: The CME installation script fails with the error message "*A version of CME is already installed via AutoUpdater.*.."  
  > **Solution:** CME has already been installed for the first time and is configured to receive updates automatically. If you have no internet access, follow the instructions for offline installation as described in the solution to Scenario 1.
* Scenario 3: "*AutoUpdater is not installed on the machine - please install the minimal JHF version as described in sk157492 and try again.*"  
  > **Solution**: Install the correct Jumbo Hotfix Accumulator as described in the beginning of the Known Limitations section. If the correct Jumbo Hotfix Accumulator is installed but the issue persists, follow these steps and then try again:
  > 1. [Get this AutoUpdater RPM](https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=106362).
  >
  > 2. Transfer the package to your Security Management Server (to some directory).
  >
  > 3. Connect to the command line on the Security Management Server.
  >
  > 4. Log in to Expert mode.
  >
  > 5. Updated the current RPM package:
  >
  >    `$ rpm -Uhv --force <Full Path to AutoUpdater RPM>`
  > 6. Stop the AutoUpdater service:
  >
  >    `$ autoupdatercli stop`
* Scenario 4: "Failed to verify if CME installation completed successfully..."  
  > **Cause:** The installation could not verify if CME has been successfully downloaded and installed.  
  >
  > **Solution** : Contact [Check Point Support](https://www.checkpoint.com/support-services/contact-support/) and attach these log files:
  > * */opt/CPInstLog/AutoUpdateLogs/CME*
  > * */var/log/CPcme/cme_installation.log*
* Scenario 5: When you run the script, you get an output that instructs you to contact Check Point Support.  
  > **Solution** : Contact [Check Point Support](https://www.checkpoint.com/support-services/contact-support/) and attach these log files:
  > * */opt/CPInstLog/AutoUpdateLogs/CME*
  > * */var/log/CPcme/cme_installation.log*
* Scenario 6: CME cannot start or cannot revert to an old CME Take.  
  > **Symptoms** :
  > * "*Starting CME: failed to run*" error appears during CME revert.
  > * CME installation fails after CME uninstalled.
  > * CME fails to start with a */var/log/CPcme/cme.log* contains "*bad decrypt* " or "*Failed to load CME configuration due to incompatible schema*" error.
  > * CME Take 212 or higher is installed only on the active member, and CME on the standby member fails to start.
  >
  > <br />
  >
  > **Cause** :  
  > 1. Starting from CME Take 212, CME configuration has a schema version.
  > 2. The schema version attribute ensures that only compatible CME runs with the given CME configuration.
  > 3. CME does not run when the CME configuration schema version is incompatible.
  > 4. Example scenarios that can cause incompatibility:
  >    1. Revert to an older CME Take.
  >    2. Upgrade -- export configuration and import it on a server with an older CME Take.
  >    3. High Availability Management/Multi-Domain servers where the CME on the two members is not from the same Take.
  >
  > <br />
  >
  > **Note** - CME configuration file is not reverted.  
  >
  > **High Availability Scenario** :  
  >
  > 1. CME configuration file is synchronized between the members.
  > 2. CME loads the configuration during CME boot.
  > 3. If the CME on the standby member is from an older take, it will fail to start because CME is not compatible with the schema version.
  >
  > <br />
  >
  > **Notes** :  
  > * Because CME configurations are stored in *$MDSDIR/conf*, the active server is the member with the active global domain.
  > * CME must not run on the standby member of a Security Management Server.
  >
  > <br />
  >
  > **Downgrade scenario** :   
  > When reverting to old CME take (revert or revert-completely + install) and the old CME is not compatible with the schema version, CME does not start.   
  >
  > **Solution** :  
  >
  > **High Availability scenario** :   
  > Install the same CME take in all the High Availability servers.  
  >
  > **Downgrade scenario** :   
  > Run `autoprov_cfg show all` and examine the schema version value, install a CME that supports the existing schema version value.
* Scenario 7: CME installation fails with "*Incorrect parse of hf.config*" error.  
  > **Symptoms:**
  > * The */opt/AutoUpdater/AutoUpdater.log* file shows this log:   
  >   `"Incorrect parse of hf.config> file /var/log/AutoUpdater/metadata/Cloud Firewall_IaaS/CME/cme_AutoUpdate/<take number>//hf.config`".
  >
  > **Cause:** The import of the CME Package was not completed successfully.  
  >
  > **Solution:**
  > 1. Open an SSH connection to the Security Management Server.
  > 2. Stop AutoUpdater:
  >    1. Run:  
  >       `$ bash /opt/AutoUpdater/latest/bin/AutoUpdaterWDUnReg.sh`
  >    2. Run:  
  >       `$ autoupdatercli stop`
  > 3. Run:  
  >    `$ rm --rf /var/log/AutoUpdater/metadata/Cloud Firewall_IaaS/CME/cme_AutoUpdate/<CME_TAKE_NUMBER>/`
  > 4. Run:  
  >    `$ rm --rf /var/log/AutoUpdater/repository/Cloud Firewall_IaaS/CME/cme_AutoUpdate/<CME_TAKE_NUMBER>/`
  > 5. Run:  
  >    `$ autoupdatercli show`  
  >    Make sure that there is a CME component but no packages.
  > 6. Proceed with CME installation.

<br />

### Policy and Database Issues {#Policy and Database Issues}

* Scenario 1: Policy installation fails.  
  > **Cause** : The version of the Security Gateway object in SmartConsole does not match the version installed on the Security Gateway.  
  >
  > **Solution** :
  > 1. Verify the installed version by running the "`cpinfo -y all`" command on the problematic Security Gateway.
  > 2. Correct the version property of the Security Gateway object in the CME template.
* Scenario 2: Database installation from SmartConsole repeatedly fails during provisioning.  
  > **Cause** : The Database installation fails on one of the Log Servers that is defined in the Security Gateway Template configuration.  
  >
  > **Solution** :
  > 1. Verify the Log Server and the Security Gateway configuration in Template parameters.
  > 2. Make sure the defined Log Servers are healthy in SmartConsole.
* Scenario 3: Policy installation fails with the "*Policy installation is not supported for the target* " message while attempting to uninstall Autonomous Threat Prevention (-*atp* ) with the generation flag (-*g*).  
  > **Solution**: As a workaround, scale-in and scale-out.
* Scenario 4: Restrictive policy installation fails with "*TCP connectivity failure (port = 18191)*"...  
  > **Solution** :
  > 1. Make sure that the Management Server object in SmartConsole is configured using its public IP address.
  > 2. Make sure that the Management Server has a valid license.
* Scenario 5: CME logs show that Threat Prevention policy installation fails with "*Policy installation failed on the gateway. If the problem persists, contact Check Point support.*"  
  > **Additional symptom:** CME logs show "Info: Firewall policy installation must be performed before blade-specific policy installation."  
  >
  > **Cause:** This is the first policy installation on the Security Gateway, and the Access policy installation failed, causing the Threat Prevention policy to fail.  
  >
  > **Solution**: Open SmartConsole, search in the "Recent Tasks" for the Access policy that failed, and resolve this failure.

### Error messages in the /var/log/CPcme/cme.log file {#Error messages in the /var/log/CPcme/cme.log file}

* Scenario 1: "*No gateways were found in controller*" message.  
  > **Additional Symptom** : Instances do not show in SmartConsole.  
  >
  > **Cause** : Possible root causes for this issue are:
  > * Connectivity issue from the Security Management / Multi-Domain Management Server.
  > * CME misconfiguration.
  > * Insufficient permissions for the relevant cloud account.
  >
  > <br />
  >
  > **Solution** :
  > 1. Run these commands on the Security Management / Multi-Domain Management Server to verify that there is connectivity and sufficient permissions:  
  >    `$ curl_cli < URL (for example, www.checkpoint.com) >`
  > 2. Verify that the scale set has deployed successfully and that there are running instances.
  > 3. Verify connectivity between the Security Management Server and Security Gateway (try to connect to it with SSH).
  > 4. If the Security Management Server is behind a Check Point or third-party gateway, verify that Firewall rules allow access to and from the Security Management Server.
  > 5. Verify that the CME Account (controller) has the relevant permissions and that the scale set is included in the permissions scope.
  > 6. Verify that public cloud platform configuration is correct:
  >    1. Test CME scanning by running: `# service cme test`.
  >    2. Verify that *x-chkp-management* and *x-chkp-template* tags values are identical to Security Management Server and Template names that appear when running `$ autoprov_cfg show all`.
  >    3. Make sure there are no redundant spaces in Security Management Server and Template names. Validate there are no spaces before or after the values.
  >    4. Verify that cloud platform security groups allow access to and from the Security Management Server.
  >
  > <br />
  >
  > If the problem still persists, [contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/). For faster resolution and verification, collect this data:
  > 1. Output of the [CME Log Collector](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/Troubleshooting.htm).
  > 2. Collect screenshots of Auto Scale and relevant Load Balancers tags.
* Scenario 2: Scale-out fails with "*No such file or directory: \<File Path\>*" message.  
  > **Additional Symptom** : Provisioning of new instances fails.  
  >
  > **Cause** : Incorrect configuration. A full path to the file should be written when specifying a script.   
  > **Solution** :   
  > Run this command to allow provisioning to finish the scale-out of Security Gateways:   
  > `$ autoprov_cfg set management -cs /home/admin/<script name>`
* Scenario 3: "*SIC port is not yet open between..*." appears more than 10 minutes after the new Security Gateway has scaled out.  
  > **Cause** : The Security Management Server cannot communicate with the new Security Gateway instance.  
  >
  > **Solution** : Check the uniqueness:
  > * Make sure that the template configuration name is unique in the subscription (Azure) / project (GCP) / region (AWS).
  >
  > * Make sure, only one Security Management Server manages this specific scale set.
  >
  > Check connectivity:
  > <!-- -->
  >
  > * If the Security Management Server is deployed in the cloud and manages at minimum one Security Gateway or scale set with its public IP address, make sure that the Management object in SmartConsole is configured with its public IP address.
  >
  > * Verify the tags values of scale *sets x-chkp-ip-address* and *x-chkp-management-interface*.
  >
  > * If *x-chkp-ip-address=public* and *x-chkp-management-interface=eth0*, make sure that the instances are deployed with public IP addresses.
  >
  > **Note:**You can examine this in the respective cloud platform.
  > If the issue persists:
  > * Remove this Security Gateway.
  >
  > * Deploy a new one and see if the issue occurs again.
  >
  > * If it does, [contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/).

* Scenario 4: "*Failed to initialize SIC with gateway instance \<Gateway name\> - SIC port is closed* " or "*Failed to initialize SIC with the gateway instance \<Gateway name\> (sic-state= {initialized})*." message.  
  > **Explanation** :  
  > There was connectivity between the Security Management Server and the Security Gateway. After five failed attempts to establish SIC, the SIC port on the Security Gateway is closed and will not accept further attempts.  
  >
  > **Cause** :
  > * Wrong password was set in the configuration template.
  > * Code limitations in CME Takes 212 and 216.
  > * Security Gateway was deleted by CME and added again.
  > * AWS only - The user-data script invoked by the deployment template fails to complete because of a Database lock.
  >
  > <br />
  >
  > <br />
  >
  > **Solution** :
  > 1. Upgrade to the [latest CME Take](https://support.checkpoint.com/results/sk/sk157492).
  > 2. Verify that the SIC password in configuration template is correct.
  > 3. Scale out a new Security Gateway.  
  >    If the new Security Gateway is provisioned without errors, scale in the Security Gateway with the SIC errors.
  >
  > If the issue persists, [contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/).  
  >
  > For AWS deployments made with Cloudformation / Terraform template version 20221027 and lower, see [sk180606](https://support.checkpoint.com/results/sk/sk180606).
* Scenario 5: "*Failed to scan for Gateway instances in the Cloud account \<cloud account name\>*" error in the AWS environment.   
  > **Cause** : AWS was not able to validate the provided access credentials.   
  >
  > **Solution**: Check if access key and secret key or IAM are configured correctly in configuration of the \<cloud account name\> controller.

<br />

### CME API Errors {#CME API Errors}

* Scenario 1: CME API command fails with *"Missing header: \[X-chkp-sid\]".*  
  > **Symptom** :   
  > When running the "*https://\<mgmt_ip\>:443/web_api/cme-api/accounts* " command using Web devices syntax:   
  > "*\<HTTP-Method\> https://\<mgmt-server\>/web_api/cme-api/\<cme-api-version\>/\<cme-command\>* "  
  > or mgmt_cli syntax:  
  > *mgmt_cli cme-api/\<cme-api-version\>/\<cme-command\> --method \<HTTP-Method\>*   
  > the execution fails with   
  > `{`  
  > ` "code": "`**generic_err_missing_required_header**`",`  
  > ` "message": "`**Missing header: [X-chkp-sid]**`"`  
  > `}`**Cause** : There is no session ID attached to the request.  
  >
  > **Solution** :
  > 1. Create a session ID by running this command:  
  >    *https://\<mgmt_ip\>/web_api/login.* (POST).
  > 2. Save the SID received from the response.
  > 3. Run the previous command and attach the SID to the headers of the request.
* Scenario 2: CME API error "*Gateway configuration is not associated with any Account*".  
  > **Symptom** :   
  > When trying to invoke an API request for CME API using  
  > Web Services syntax: *\<HTTP-Method\> https://\<mgmt-server\>/web_api/cme-api/\<cme-api-version\>/\<cme-command\>*   
  > or  
  > mgmt_cli syntax: *mgmt_cli cme-api/\<cme-api-version\>/\<cme-command\> --method \<HTTP-Method\>* action fails with   
  > `{`  
  > ` "result": {},`  
  > ` "error": {`  
  > ` "details": "`**Error while loading configuration file. GW Configuration with id <TEMPLATE NAME> is not associated with any Account. Please use the autoprov_cfg command to associate your GW Configuration to the relevant Accounts: autoprov_cfg set controller <AWS/Azure/GCP> -cn <Account name> -ct <TEMPLATE_NAME>**`",`  
  >
  > ` "error-code": 804,`  
  > ` "message": "`**GW configuration is not associated with any accoun**`t"`  
  > ` },`  
  > ` "status-code": 404`  
  > `}`  
  >
  > **Cause** : The CME configuration file that was generated by the *autoprov_cfg* tool is not compatible with CME API. The CME API expects to see the template(s) inside the CME configuration file associated with an account.  
  >
  > **Solution** :  
  > Associate the template with the account using this command:   
  > *autoprov_cfg set controller \<AWS/Azure/GCP\> -cn \<Account name\> -ct \<TEMPLATE_NAME\>*
* Scenario 3: CME API error "*Credentials file is not located in the expected folder*".  
  > **Symptom** :  
  > When trying to invoke an API request for CME API to add/set GCP account using  
  > Web Services syntax: *\<HTTP-Method\> https://\<mgmt-server\>/web_api/cme-api/\<cme-api-version\>/\<cme-command\>*   
  > ?r  
  > mgmt_cli syntax: *mgmt_cli cme-api/\<cme-api-version\>/\<cme-command\> --method \<HTTP-Method\>* action fails with  
  > `{`  
  > ` "result": {},`  
  > ` "error": {`  
  > ` "details": "`**Credentials file is not located in the expected folder: $FWDIR/conf**`",`  
  > ` "error-code": 400,`  
  > ` "message": "`**General Error**`"`  
  > ` },`  
  > ` "status-code": 500`  
  > `}`   
  >
  > **Cause** : The credentials file can be located not in the correct folder, or the existing credentials in the *autoprovision.json* file are not located properly.   
  >
  > **Solution**
  > 1. Check if the credentials file is located in the expected location - *$FWDIR/conf* directory.
  > 2. Verify the *autoprovision.json* file to ensure that the credentials file is correctly placed in the designated folder. If it is not, edit the *autoprovision.json* file and provide the correct full path location.
* Scenario 4: "*Access denied, IAM role ARN (on management) is not authorized to perform sts:AssueRole on resource IAM role ARN (in another account)*".  
  > **Cause** : The customer account is missing permissions to allow the management account access.   
  >
  > **Solution** :   
  > * **Step 1 - AWS Accounts**   
  >   **Management account:**   
  >   The instance profile role should have thisg permission policy:  
  >   `{`  
  >   ` "Effect": "Allow",`  
  >   ` "Action": "sts:AssumeRole",`  
  >   ` "Resource": "arn:aws:iam::CUSTOMER-ACCOUNT-ID:role/customer-ROLENAME"`  
  >   `}`  
  >
  >   **Customer account** :  
  >   Must trust the management instance profile role to assume it. Therefore, the IAM role must have this trust policy:  
  >   `{`  
  >   ` "Version": "2012-10-17",`  
  >   ` "Statement": [`  
  >   ` {`  
  >   ` "Effect": "Allow",`  
  >   ` "Action": "sts:AssumeRole",`  
  >   ` "Principal": {"AWS": "arn:aws:iam::MANAGEMET-ACCOUNT-ID:root"}`  
  >   ` }`  
  >   ` ]`  
  >   `}`  
  >
  > * **Step 2 - CME** :  
  >   Add sts role ARN by using the -sr flag:   
  >   `-sr arn:aws:iam::<customer account id>:role/<customer_role>`
* Scenario 5: "*Wrong session id \[\<OLD SID\>\]. Session may be expired. Please check the session id and resend the request*" error when trying to invoke any CME API request.  
  > **Cause** : The Session Identifier (SID) that was used, has expired.  
  >
  > **Solution** : Log in and obtain a new session ID. To do so, log in through this API endpoint:  
  > `POST https://<SERVER IP address>/web_api/login`  
  >
  > With this body:  
  > `{"user" : "<USER>", "password" : "<PASSWORD>"}`  
  >
  > The SID should be taken from the output:  
  >
  > `{`  
  > ` "uid": "<UID>",`  
  > ` "sid": "<SID>",`  
  > ` "url": "https://<SERVER IP address>:443/web_api",`  
  > ` "session-timeout": 600,`  
  > ` "last-login-was-at": {`  
  > ` "posix": 1688303543297,`  
  > ` "iso-8601": "2023-07-02T13:12+0000"`  
  > ` },`  
  > ` "api-server-version": "1.9",`  
  > ` "user-name": "<USER>",`  
  > ` "user-uid": "<USER_ID>"`  
  > `}`
* Scenario 6: Error in adding Security Gateway configurations by running the CME API POST command `/gwConfigurations/<cloud provider>`.  
  > **Symptom** :  
  > When running the `/gwConfigurations/<cloud provider>` POST command with this Web Services syntax:   
  > *POST https://\<mgmt-server\>/web_api/cme-api/\<cme-api-version\>/gwConfigurations/\<cloud- provider\>*   
  > Or  
  > mgmt_cli syntax: *mgmt_cli cme-api/\<cme-api-version\>/\<cme-command\> --method POST* The action fails with:  
  > `{`  
  > ` "result": {},`  
  > ` "error": {`  
  > ` "details": "`**Bad parameter related_account. Got value of <account name>, should be of Existing <cloud provider> account**`",`  
  >
  > ` "error-code": 751,`  
  > ` "message": "`**Bad Value of Parameter**`"`  
  > ` },`  
  > ` "status-code": 400`  
  > `}`   
  >
  > **Cause** : It is mandatory to add an account before adding gateway configurations.  
  >
  > **Solution** : Run the CME API `/accounts/<cloud provider>` before adding Gateway configurations.  
  >
  > After that, rerun the API with "`related_account`" key attached to the body.   
  >
  > For example:  
  > `{`  
  > ` "name": "awsGwConfiguration",`  
  > ` "version": "R81.10",`  
  > ` "base64_sic_key": "XXXXX",`  
  > ` "policy": "Standard",`  
  > ` "related_account": "my-account",`  
  > ` "blades": {`  
  > ` "anti-bot": true`  
  > ` }`  
  > `}`  
  >
* Scenario 7: CME API Error: "*Unrecognized parameters were received*".  
  > **Symptom** :  
  > When you try to add/set GCP account using an API request in this Web Services syntax:  
  > *\<HTTP-Method\> https://\<mgmt-server\>/web_api/cme-api/\<cme-api-version\>/\<cme-command\>*   
  > Or  
  > *mgmt_cli syntax: mgmt_cli cme-api/\<cme-api-version\>/\<cme-command\> --method \<HTTP-Method\>*   
  > The action fails with:  
  > `{`  
  > ` "result": {},`  
  > ` "error": {`  
  > ` "details": "`**Unrecognized parameters were received. Parameters names: \{'universe_domain'}**`",`  
  >
  > ` "error-code": 756,`  
  > ` "message": "`**Unrecognized Parameter Received**`"`  
  > ` },`  
  > ` "status-code": 400`  
  > `}`   
  >
  > **Cause** : The request to add/set up a GCP account with *credentials_data* in the API request body contains an unknown field (*universe_domain* in this example).  
  >
  > **Solution** :  
  > 1. Edit the service account JSON file.
  > 2. Remove the unknown field.
  > 3. Run the API command again.
  >
  > <br />
  >
  > <br />
  >
* Scenario 8: CME fails to provision a Security Gateway.  
  > **Symptoms** :
  > * For R82 and higher:  
  >   The "`API call failed with command: add-simple-gateway`" message appears in the `cme.log` file.
  >
  > * For R81.20 and lower:  
  >   Policy installation fails with this message: "`Target is not defined in the database`".
  >
  > **Cause** :  
  > Security Gateway object name cannot be longer than 100 characters.  
  >
  > CME creates the Security Gateways object using this naming convention:
  > * For AWS:   
  >   **\<controller-name\>-\<auto-scaling-group-name\>-\<region-name\>**
  >
  > * For Azure:   
  >   **\<controller-name\>-\<scale-set-name\>_\<instance-id\>-\<resource-group=name\>**
  >
  > **Note:** The \<instance-id\> in Azure cannot be longer than 4 characters.
  > **Solution** :  
  > If there are already Security Gateways configured in the Security Management Server from the same Auto Scaling Group/Virtual Machine Scale Set (VMSS), [contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/).   
  >
  > In the new environment, follow these instructions until the issue is resolved (not all steps might be required):
  > 1. If the Configuration Template is configured with a `prefix-name`, remove it by running:  
  >
  >    `autoprov_cfg delete template -tn <TEMPLATE-NAME> -pn`  
  >
  >    `restart cme service`
  >
  > 2. Replace the Controller name with a shorter name:  
  >
  >    `autoprov_cfg delete controller <PLATFORM> -cn <CONTROLLER NAME>`  
  >
  >    `autoprov_cfg add controller <PLATFORM>`  
  >
  >    `restart cme service`
  > 3. Re-deploy the Auto Scaling Group/VMSS and use shorter names for the Auto Scaling Group, Scale Set and Resource Group.
  >
  > <br />
  >
  > <br />
  >
<br />

### GCP (Google Cloud Platform) Issues {#GCP (Google Cloud Platform) Issues}

* Scenario 1: GCP MIG instances do not answer Google Health Probes  
  > **Symptom** : The Gateway is in "Unhealthy" state in the GCP Portal.   
  >
  > **Cause** : Configuration issue - Health check port was set to listen to all-ports in the LB backend configuration.   
  >
  > **Solution** : In GCP Portal, set the Health check port to 8117:  
  > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk181510/HEalthCheck202311121844591.png)
* Scenario 2: In a Multi-Domain Management Server environment, GCP MIG instances do not answer Google Health Probes.  
  > **Cause** : Incorrect *user.def.FW1* file location. The file *user.def.FW1* should be located in the */opt/CPmds-R81.10/customers/**domain_server_name**/CPsuite-R81.10/fw1/* directory, but instead was found in the global domain context.   
  >
  > **Solution** :  
  > This problem was fixed. The fix is included starting from:
  > * [CME (Cloud Management Extension) for Cloud Firewall](https://support.checkpoint.com/results/sk/sk157492) - Take 227

<br />

### AWS (Amazon Web Services) Issues {#AWS (Amazon Web Services) Issues}

* Scenario 1: Failed to scan for the Security Gateway instances in the sub-account.  
  > Symptom:
  > * In sub-creds configuration, there are sts-role and keys (access and secret keys).  
  >   For example:  
  >   `sub-creds:`  
  >   `
  >   custom:`  
  >   `
  >   access-key: *********I`  
  >   `
  >   secret-key: *********`  
  >   `
  >   sts-role: "arn:aws:iam::Custom-Account-Id:role/Role-Name"`
  > * The */var/log/CPcme/cme.log* file shows:  
  >   `RoleException: `  
  >   `
  >   "403 Forbidden: AccessDenied: `  
  >   `
  >   User: arn:aws:iam::Account-Id:user/Name-User is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::Customer-Account-Id:role/Role-Name"`
  >
  > **Cause** : Invalid configuration, failed to scan for Gateway instances in sub-creds.  
  >
  > **Solution** : Choose either *sts-role* or keys (access and secret keys).
* Scenario 2: "*UnauthorizedOperation: You are not authorized to perform this operation* " error in the *cme.log* file during the synchronization of subnets with the Gateway Load Balancer.  
  > **Additional Symptom** : Configuration works in GWLB (Gateway Load Balancer) scan subnet mode without tagging the correct subnet.   
  > **Solution** :   
  > Tag the correct subnet (subnet in *vpc gwlb-endpoint* )   
  > OR  
  > Remove the *-ss* flag from CME configuration.
* Scenario 3: "*Exception: Throttling: Rate exceeded*" message in the cme.log file.  
  > **Cause** : Some object has sent a lot of API requests, and it is more than what AWS allows.  
  > **Solution** :   
  > 1. To understand which object sending those API requests, check the API request in CloudWatch tab \> Metrics. Filter by API type.
  > 2. Open a ticket to AWS Support to increase the API quota.
* Scenario 4: Automatic Access and NAT policy for AWS ASG solution are not created/changed based on internal Load Balancer tags.  
  > **Cause** :
  > * The *x-chkp-template* and *x-chkp-management* tags values on internal load balancer do not reflect template and management names in CME configuration.
  > * If internal load balancer stored in sub-account (with sub-creds), CME goes over sub accounts one by one and scan their resources. In case one of the accounts fails, CME does not continue to another one.
  >
  > <br />
  >
  > **Solution** : Align the `x-chkp-template` and `x-chkp-management` tags values with CME configuration values.  
  > Note: Sub-account scan can fail because the authentication keys are expired or missing permissions, therefore they should be fixed.
* Scenario 5: Security Gateway provisioning is complete according to CME logs, but the Security Gateway instance remains unhealthy in the Target Group configuration after several minutes.  
  > **Additional Symptom** : There is no task mentioning `lb_healthcheck` on SmartConsole's "Recent Tasks" pane.
  >
  > **Solution** : Make sure that `x-chkp` tags associated with the EC2 Security Gateway instance are added to the GWLB tags and ASG tags. This allows CME to whitelist load-balancer's probes in the Security Gateway configuration.  
  >
  > In the case of NLB or ALB, `x-chkp` tags must be added to the Internal Load Balancer tags and ASG tags.
* Scenario 6: CME Sub-Account Scan Failure Results in Missing Gateway Objects after installing CME Take 319 or 320.  
  > **Additional Symptoms**:
  > * Sub-account scans fail and the following messages appear in the CME logs:  
  >   `YYYY-MM-DD hh:mm:ss,SSS CME_SERVICE INFO Request failed for sub account: <sub_account_name>`  
  >   `YYYY-MM-DD hh:mm:ss,SSS CME_SERVICE INFO Failed to retrieve subnets from sub account <sub_account_name>, continuing for the next sub account`
  > * Policy objects associated with gateway instances are deleted and recreated. In some cases, some objects may be missing after the recreation process.
  >
  > **Cause:** A failure during sub-account scanning causes CME to reset gateway-related objects.
  >
  > **Solution**: Revert the CME to Take 318 or lower.

### Azure Issues {#Azure Issues}

* Scenario 1: CME fails to configure new instances.  
  > Symptom:
  > * You can see this log in the *cme.log* file:  
  >   `"Error during synchronization with Security Gateways: TypeError: str, bytes or bytearray expected, not NoneType"`
  >
  > **Cause** : The NIC name in the Azure portal was altered from eth0, which is not supported.  
  >
  > **Solution**: Undo the changes made to the NIC name.

---

# 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