Troubleshooting

General troubleshooting guidelines

Run these commands on the Security Management Server or Multi-Domain Server (in the Expert mode) to test the CME service.

Command	Description
service cme stop	Stops the main CME service.
service cme test	Starts the test. Examines the output of this command to confirm that the setup works properly.
service cme start	Starts the main CME service (it if was stopped before the test).

• Make sure that the clock on the Security Management Server is set correctly.

  The best way to set the clock is with the NTP.

  You need a synchronized clock to make API calls into a cloud environment.

• Review logs are created by the CME on the Management Server:

  /var/log/CPcme/cme.log*

• To enable or disable Debug mode:

  1. Connect to the command line on the Security Management Server.

  2. Log in to the Expert mode.

  3. Launch the CME menu:

     cme_menu

  4. Navigate to Debug Mode.

  5. Select Enable Debug mode.

  Note - The Debug mode significantly increases the number of logs messages written to the CME log files.

CME cannot start or revert to an old CME Take

Symptoms:

1. "Starting cme: failed to run" error appears during CME revert.

2. CME installation fails after CME revert-completely.

3. CME fail to start, and /var/log/CPcme/cme.log contains "bad decrypt" or "Failed to load CME configuration due to incompatible schema" error.

4. CME from Take 212 or higher is installed only on the active server, and CME on the standby member fails to start.

Cause:

Starting from CME Take 212 the CME configuration has a schema version.

The schema version attribute ensures that only compatible CME runs with the given CME configuration.

CME does not run when the CME configuration schema version is incompatible.

Example scenarios that can cause incompatibility:

• Revert to older CME Take.

  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.

  Note - CME configuration file is not reverted.

• Upgrade – export configuration and import it on a server with an older CME Take.

• In Management High Availability, the CME Take is not the same on the Management Servers.

  1. CME configuration file is synchronized between the Management Servers.

  2. CME loads the configuration during the CME boot.

  3. If the CME on the Standby Management Server is from an older Take, it fails to start because CME is not compatible with the schema version.

  Notes: Because CME configurations are stored in $MDSDIR/conf/, the Active Management Server has the Active Global Domain. CME must not run on the Standby Management Server.

Solution for the Management High Availability scenario:

Install the same CME Take on all the Management Servers.

Solution for the Downgrade scenario:

• Option 1 - Install the supported CME Take (recommended):

  1. Run "autoprov_cfg show all" and examine the schema version value.

  2. Follow sk157492 and install a CME Take that supports the existing schema version value.

• Option 2 - Initialize the CME:

  • Run "autoprov_cfg init" as described in the Using the autoprov_cfg Command Line Configuration Tool section.

    Note - This command overrides the existing configuration. If the “init” command fails, and the error message contains “bad decrypt” , contact Check Point Support.

CME cannot establish SIC with the Security Gateway

Scenario 1

Symptom:

CME logs message "SIC port is not yet open between..." appears more than 10 minutes after the new Security Gateway has scaled out.

Explanation:

The Security Management Server cannot communicate with the new Security Gateway instance.

Solution:

1. Check the uniqueness:

   • Make sure that the template configuration name is unique in the subscription (Azure) / project (GCP) / region (AWS).

   • Make sure, only one Management Server manages this specific scale set.

2. Check connectivity:

   • If the 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:

1. Remove this Security Gateway

2. Deploy a new one and see if the issue occurs again.

3. If it does, contact Check Point Support.

Scenario 2

Symptom:

These CME log messages appear:

• Failed to initialize SIC with gateway instance <gateway name> - SIC port is closed

• Failed to initialize SIC with the gateway instance <gateway name> (sic-state= {initialized}).

Make sure the One-Time Password configured in CME is correct

Explanation:

There was connectivity between the Security Management 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 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.

Solution:

1. Upgrade to the latest CME Take.

2. Verify that the SIC password in configuration template is correct.

3. Scale-out a new Security Gateway, if the new one provisioned without errors, scale-in the gateway with the SIC errors.

If the issue persists, contact Check Point Support.

For AWS deployments made with Cloudformation / Terraform template version 20221027 and lower, see sk180606.