> Source: [sk115657](https://support.checkpoint.com/results/sk/sk115657)
# sk115657 - ATRG: CloudGuard Controller
| Property | Value |
|----------|-------|
| Solution ID | sk115657 |
| Date Created | 2017-10-21 |
| Last Modified | 2026-02-18 |
| Technical Level | General |
| Products | Cloud Firewall |
| Versions | R82.10, R81 (EOS), R81.10 (EOS), R81.20, R82 |
| OS | Gaia |
## Solution
**Introduction \| Glossary \| Architecture \| Configuration Options
Error Handling \| Logging \| Troubleshooting**
Click Here to Display the Entire Article
Introduction {#Introduction}
----------------------------
The CloudGuard Network Security solution delivers advanced threat protection to private or public cloud infrastructures.?
With trusted APIs, the CloudGuard Controller connects to the Software-Defined Data Center (SDDC) and integrates the virtual cloud environment with Check Point Security Gateways.
After using the vendor's API to connect to the Software-Defined Data Center (SDDC), CloudGuard Controller regularly polls connected environments for changes in objects and object attributes used in the Security Policy. Changes are automatically pushed to the Security Gateway.
For additional information, refer to the [CloudGuard Controller Administration Guide](https://support.checkpoint.com/product/573) of your version.
Glossary {#Glossary}
--------------------
Show / Hide the Glossary Section
This section provides definitions of the main terms used in the CloudGuard Controller documentation.
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Term | Definition |
| CMS | The Cloud Management Server is the main process of the CloudGuard Controller. |
| Scanner | This CMS component regularly retrieves objects from the Data Center. |
| DC Repository | This CMS component enables in-memory storage of scan results. |
| Enforcement | This CMS component sends Data Center updates to the Security Gateways based on the Policy. |
| Notifier (Auto-update) | This CMS component updates the Check Point Management (CPM) process with changes made to Data Center objects. |
| CPM | A separate Check Point Management process. |
| Import window | In this SmartConsole window, you can view the scan results from a Data Center. You can also select Data Center Objects to import and use in the security policy. |
Architecture {#Architecture}
----------------------------
Show / Hide the Architecture Section
These are the main components of the CloudGuard Controller:
|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Component | Description |
| Scanners | For each defined Data Center server, there is a Scanner component that automatically connects and retrieves all relevant objects and properties from that Data Center. * After each scanning cycle, the Scanner component waits according to the `scannerInterval` value in `vsec.conf`. * Scanners run independently and do not affect each other. * The DC Repository component stores the results of each scan. * If multiple Data Centers in the same Domain or in multiple Domains (in the MDS (System) environment) have the same properties (for example, connection properties - name, password, key, region, and so on), only one Scanner is created for all these Data Centers. |
| DC Repository | An in-memory storage of the scan results from all Scanners. The repository is not permanent and is deleted when the process stops. The Scanners add data to it, and the Enforcement components read from it. |
| Enforcement updates | For each Domain, there is an Enforcement component that checks the DC Repository for changes since the last scans and then sends the updates to Security Gateways of these Domains. * Security Gateways from the same Domain are updated simultaneously according to the `enforcementThreadPool` value in `vsec.conf`. * After each enforcement update cycle, the Enforcement component waits according to the `enforcementUpdateIntervalTime` value in `vsec.conf`. * Each Data Center object on the Security Gateway has an expiration time set according to the `enforcementSessionTimeoutInMinutes` value in `vsec.conf`. * If the connection between the Security Management Server and the Security Gateway is lost, the Data Center object will automatically expire and be removed from the Security Gateway. * As long as the Security Management Server and the Security Gateway are connected, the Enforcement component will continue to extend the expiration of the Data Center objects, even if there are Scanner failures. * The Identity Awareness (IDA) blade handles policy enforcement on the Security Gateway. * The Security Gateway is updated with Data Center objects information by running local commands on the Security Gateway via a script that interacts with the IDA blade's PDP component on that Security Gateway. * The Security Management Server sends the commands to the Security Gateway using Check Point CPRID connectivity. |
| Notifier | This component keeps track of the current properties (such as Name, IP address, and so on) of Data Center Objects used in the Security Policy based on the most recent scan results. The CPM process regularly polls this list to make these properties available in SmartConsole and management APIs. |
Configuration Options {#Configuration_Options}
----------------------------------------------
Show / Hide the Configuration Options Section
CloudGuard Controller uses only one configuration file -- `vsec.conf`:
* On a Security Management Server, the file is located at `$FWDIR/conf/vsec.conf`.
* On a Multi-Domain Server, the file is located at `$MDSDIR/conf/vsec.conf`.
After making changes to the file, you must restart the process to apply the new values by running `vsec stop ; vsec start`.
The file contains documentation for each configuration option.
When you upgrade the Security Management Server or a Multi-Domain Server, the original file is preserved to keep the user's settings.
For more details, refer to the [Configuration Parameters](https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_CloudGuard_Controller_AdminGuide/Content/Topics-CGRDG/Configuration-Parameters.htm?TocPath=_____9) section in the CloudGuard Controller Administration Guide.
Error Handling {#Error_Handling}
--------------------------------
Show / Hide the Error Handling Section
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Component | Error Handling |
| Scanners | A failed scan shows this log in SmartConsole:  * After each scan failure, the Scanner increases the delay before the next scan cycle. * The `scanSleepUpperLimitInSeconds` setting in `vsec.conf` determines the maximum delay between scans. * A successful scan following a failed scan decreases the delay before the next scan cycle until it returns to the normal value set in `scannerInterval` in `vsec.conf`. * The log of a successful scan has an "Informational" severity. * The log of failed scan has an "Error" severity. * After a specified number of failed scans, the log of the failed scan will have a "Critical" severity. The `consecutiveNumOfScanFailureToCriticalLog` setting in `vsec.conf` controls this behavior. |
| Enforcement updates | A failed enforcement cycle shows this log in SmartConsole:  * There is a dedicated Enforcement update thread for each Domain. * After each enforcement update cycle, there is short delay according to the `enforcementUpdateIntervalTime` setting in `vsec.conf`. * The log of a successful enforcement update has an "Informational" severity. * The log of a failed enforcement update has an "Error" severity. * After a specified number of failed enforcement updates, the log of the failed enforcement update will have a "Critical" severity. The `consecutiveNumOfGWFailureToCriticalLog` setting in `vsec.conf` controls this behavior. |
Logging {#Logging}
------------------
Show / Hide the Entire Logging Section
CloudGuard Controller has two types of logs for monitoring and troubleshooting purposes:
1. Logs that are sent to SmartConcole.
* To view these logs, filter them using `blade:"CloudGuard Network"`.
* To focus on failures, filter the logs using `blade:"CloudGuard Network" AND severity:Critical`.
Many of the monitoring capabilities are build around the "Severity" field. Refer to the [Monitoring](https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_CloudGuard_Controller_AdminGuide/Content/Topics-CGRDG/Monitoring.htm?TocPath=CloudGuard%20Controller%20Monitoring%7C_____0"%20\l%20"CloudGuard_Controller_Monitoring) section in the CloudGuard Controller Administration Guide for more information.
2. Runtime logs for troubleshooting.
* These logs are written to the file `$MDS_FWDIR/log/cloud_proxy.elg`.
* To focus on failures or errors, search the file for the keyword "ERROR".
Troubleshooting {#Troubleshooting}
----------------------------------
Show / Hide the Entire Troubleshooting Section
**Table of Contents:**
|------------------------------------------------------------------------------------------------|
| * **Enforcement Update Issues** * **Data Center Query Issues** * **Data Center Status Issues** |
### Enforcement Update Issues {#Update and Enforcement Issues}
* Scenario 1: Shorten Security Gateway update time on environments with many Security Gateways.
> **Cause:**
> For each management Domain, there is a dedicated thread that updates the Security Gateways in that Domain. After each update cycle, there is a 10-second delay before the next cycle, as specified by the `enforcementUpdateIntervalTime` value in `vsec.conf`.
>
> The update cycle updates multiple Security Gateways simultaneously according to the `enforcementThreadPool` value.**Solution:** You can increase the value of `enforcementThreadPool` to update more Security Gateways simultaneously.
* Scenario 2: "Failed to update the GW..." error message in the `cloud_proxy.elg` file.
> **Symptoms:**
> 1. The CloudGuard Controller fails to update the Security Gateway.
>
> 2. The `cloud_proxy.elg` file contains multiple `cprid_util` failures on the `putfile` command, indicating a failure to send the script file to the Security Gateway:
>
> `ERROR datacenter.util.CommandExec [gateway-updater_****]: Command '[/opt/CPshrd-R81.20/bin/cprid_util, -server, *.*.*.*, putfile, -local_file, /opt/CPsuite-R81.20/fw1/tmp/****_vsecUpdate.sh, -remote_file, /etc/fw/tmp/****_vsecUpdate.sh]' failed ... `
> ` `
> `ERROR ida.api.IDACpridRequestSenderClient [gateway-updater_****]: Failure 3/3 to send script file to gateway ...`
>
> **Cause:** `cprid_util` errors on the `putfile` command are usually caused by connectivity issues.**Solution:**
> 1. Test connectivity with the Security Gateway by running the command:
>
> `$CPDIR/bin/cprid_util -server getarch`
>
> The expected result should be "gaia". If the output is "unknown", then check the connectivity on CPRID port 18208 using the telnet command.
> 2. Enable `cprid_util` debug according to [sk174346](https://support.checkpoint.com/results/sk/sk174346) and try sending a dummy file.
>
> Example:
> 1. Run: `touch /home/admin/test.txt`
>
> 2. Transfer the `test.txt` file from the Security Management Server to the Security Gateway using the CPRID command:
>
> `$CPDIR/bin/cprid_util -server putfile -local_file /home/admin/test.txt -remote_file /tmp/test.txt`
* Scenario 3: The IP address is not enforced.
> **Symptom:** Traffic to or from an IP address is not correctly enforced by the Security Gateway.**Causes:**
> * The Data Center scan did not detect the IP address.
>
> * The IP address does not match the rule base definitions and was not sent to the Security Gateway. For example:
>
> * The IP address does not match a Data Center Query used in the policy.
>
> * The IP address does not match a Tag used in the policy.
>
> * The IP address was sent to the Security Gateway but was later deleted.
>
> **Troubleshooting steps:**
>
> To troubleshoot this issue, start from the Security Gateway and work backward to the CloudGuard Controller on the Security Management Server:
> 1. Check if the IP address is in the PEP tables on the Security Gateway by running:
>
> `# pep show user query cid `
>
> 2. Check if the IP address is in the PDP tables on the Security Gateway by running:
>
> `# pdp m ip `
>
> 3. Search for this IP address in `cloud_proxy.elg` files on the Security Management Server to see if it was sent to the Security Gateway:
>
> `# zgrep $FWDIR/log/cloud_proxy.elg*`
>
> Then open each location and see if it related to the problematic Security Gateway. The log line will contain the Security Gateway name and IP address.
>
> For example, when searching for 10.11.12.13 we can see that it was pushed to the Security Gateway 10.200.200.110 at 29/03/24 19:29:18:
>
> `29/03/24 19:29:18,230 INFO ida.api.IDACpridRequestSenderClient [gateway-updater_domainA_Cloudguard_GW]: Sending update to gw 10.200.200.110: #!/bin/bash `
> `quote=\' `
> `response=$(curl_cli -s -H "Content-Type: application/json" -w "%{response_code}" -X POST http://localhost:5908/_IA_API/idasdk/add-identity -d @-<< EOF `
> `{ `
> ` "empty" : false, `
> ` "addRequestsNum" : 42, `
> ` "shared-secret" : "$2", `
> ` "requests" : [ { `
> ` "ip-address" : "10.11.12.13", `
> ` "machine" : "$(echo 'i-123abc123abc123a (fronend-web-server)')", `
> ` "machine-groups" : [ "$(echo 'chkp:aws:service:prod=allow')" ], `
> ` "roles" : [ "Ve2f4f0c6-844a-4312-8824-b6ff55ff7707" ], `
> ` "session-timeout" : 604800, `
> ` "fetch-machine-groups" : false, `
> ` "calculate-roles" : false, `
> ` "identity-source" : "CloudGuard Controller" `
> ` } `
>
> And after 2 seconds we see a correct response from the Security Gateway for that IP address:
>
> `29/03/24 19:29:20,008 INFO ida.api.IDACpridRequestSenderClient [gateway-updater_domainA_Cloudguard_GW]: Response from gw 10.200.200.110 is '`
> `{`
> ` "http_code" : 200, `
> ` "raw_response":{ `
> ` "responses" : [ { `
> ` "count" : "1", `
> ` "ipv4-address" : "10.11.12.13", `
> ` "message" : "Association sent to PDP." `
> `}`
>
> 4. If the requested IP address is not found in `cloud_proxy.elg`, the next step is to check if it appears in the Data Center scan results.
>
> 5. Right-click on the relevant Data Center and select "Import". Then, search for the IP address.
>
> 
>
> 6. Connecting to and scanning AWS, Azure, GCP, and OCI Data Centers is done using a Python script (`vsec.py`), which can be run manually. Redirect the script's output to a file and search for the requested IP address within that file.
>
> 1. First, verify that the output is a valid JSON file. If it is not, the scan did not complete correctly. This could be due to authentication or authorization issues. The errors will be present in the output.
>
> 2. How to manually run the vsec.py:
>
> **Examples**
> **AWS using Access and Secret keys:**
>
> `# AWS_API_DEBUG=true AWS_ACCESS_KEY= AWS_SECRET_KEY= $FWDIR/Python/bin/python3 $VSECDIR/scripts/aws/vsec.py `
>
> **AWS using the Management server IAM role:**
>
> `# AWS_API_DEBUG=true AWS_KEY_FILE=IAM $FWDIR/Python/bin/python3 $VSECDIR/scripts/aws/vsec.py `
>
> **AWS using STS Assume Role (R81.10 and higher):**
>
> `# AWS_API_DEBUG=true AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_STS_ROLE= AWS_STS_SESSION=test AWS_STS_EXTERNAL_ID= $FWDIR/Python/bin/python3 $VSECDIR/scripts/aws/vsec.py `
>
> **GCP (Google Cloud Platform):**
>
> `# export GCP_CREDENTIALS=$(cat ); GCP_DEBUG=true $FWDIR/Python/bin/python3 $VSECDIR/scripts/google/vsec.py __ALL__ `
>
> **Azure:**
>
> `# AZURE_REST_DEBUG=true AZURE_CREDENTIALS='{"client_id": "","client_secret": "","grant_type": "client_credentials","tenant": ""}' $FWDIR/Python/bin/python3 $VSECDIR/scripts/azure/vsec.py`
>
> You can provide the Azure credentials from a JSON file with the same format as in the above example:
>
> `# AZURE_REST_DEBUG=true AZURE_CREDENTIALS=creds.json $FWDIR/Python/bin/python3 $VSECDIR/scripts/azure/vsec.py`
> 7. If the IP address is expected to be part of a DCQ (Data Center Query), open the DCQ object, click "Preview", and search for the IP address:
>
> 
>
> 8. Check for errors when updating the relevant Security Gateway:
>
> * Check SmartConsole logs -- see the Logging section above.
>
> * Check for `cprid_util 'rexec'` errors in the `cloud_proxy.elg` file:
>
> `20/02/24 03:51:18,959 ERROR
> datacenter.util.CommandExec [gateway-updater_domainA_Cloudguard_GW]: Failed to execute '[/opt/CPshrd-R81.20/bin/cprid_util, -server, 10.200.200.110, -timeout,
> 120, -verbose, rexec, -rcmd, /bin/bash, /etc/fw/tmp/Cloudguard_GW_vsecUpdate.sh, Cloudguard_GW, PassC0d3]' from domain 10.20.30.40`
>
> If there are errors related to `cprid_util`, follow these troubleshooting steps:
> 1. Connect to the Security Gateway using SSH.
>
> 2. Backup the `vsecUpdate.sh` file:
>
> `# cp /etc/fw/tmp/_vsecUpdate.sh /etc/fw/tmp/_vsecUpdate_test.sh`
>
> 3. Add executable permissions to the file:
>
> `# chmod +x /etc/fw/tmp/_vsecUpdate_test.sh`
>
> 4. Run the script with the bash debugging flag -x:
>
> # /bin/bash -x /etc/fw/tmp/\_vsecUpdate_test.sh \ \ \> vsec_out.txt?2\>\&1
>
> The shared secret is found in the `cloud_proxy.elg` log line -- 'PassC0d3' in the example above.
>
> Examine the output in the `vsec_out.txt` file. The expected output is a valid JSON file with the `http_code` field equal to `200`.
>
> If the output is not a valid JSON file or if the value of the `http_code` field in this JSON file (which comes from the PDP process running on the Security Gateway) is not `200`:
> 1. Enable PDP debugging on the Security Gateway:
>
> # pdp d s IDP all
> # pdp d s IDA_API all
>
> 2. Repeat the step above to re-run the `vsecUpdate.sh` file located at `/etc/fw/tmp/_vsecUpdate_test.sh`
>
> 3. Disable PDP debugging:
>
> # pdp d u IDP
> # pdp d u IDA_API
>
> 4. Collect the `$FWDIR/log/pdpd.elg*` files and the `vsec_out.txt` file, then contact Support.
* Scenario 4: Scan failures after changing Data Center credentials.
> **Symptoms** :
> * After changing Data Center credentials, "Test Connection" in SmartConsole shows "connected", but logs show scan failures.
>
> * After changing Data Center credentials, "Test Connection" in SmartConsole shows "connected", but Security Gateways are not updated with the correct data.
>
> **Cause** : The Data Center credentials are not updated for all Security Gateways.
>
>
>
> **Solution** :
> * For versions before R81.20 Jumbo Take 43: Install the policy on all Security Gateways that include assets from the affected Data Center.
>
> * For versions after R81.20 Jumbo Take 43: Install the policy on one of the Security Gateways that include assets from the affected Data Center
>
* Scenario 5
> **Symptoms** :
> * Opening the Data Center object, or selecting "Test Connection" in SmartConsole shows "disconnected."
>
> * Running # cpstat vsec from the Security Management Server shows the Data Center as "disconnected."
>
> **Cause** : A connectivity issue between the Security Management Server and the cloud platform exists.
>
>
>
> **Solution** :
> * Review the $MDS_FWDIR/log/cloud_proxy.log files for additional errors.
>
> * Investigate the network for potential causes.
>
> * Test connectivity to the Cloud provider by using the curl command to the relevant endpoint.
>
> Azure: curl_cli --verbose https://management.azure.com --cacert $CPDIR/conf/ca-bundle-public-cloud.crt
>
> AWS: curl_cli --verbose https://ec2.amazonaws.com --cacert $CPDIR/conf/ca-bundle-public-cloud.crt
>
> For example: curl_cli --verbose https://ec2.eu-west-1.amazonaws.com --cacert $CPDIR/conf/ca-bundle-public-cloud.crt
>
> Note: For checking connectivity using curl, the expected result is any response other than "timeout." HTTP 400 response is OK.
### Data Center Query Issues {#DCQ Issues}
* Scenario 1: IP addresses associated to DCQ are not enforced.
> **Symptom:** IP Addresses are not sent to the Security Gateway or not enforced by the Security Gateway even though they are seen in the **DCQ \> Preview** .
>
> **Cause:**
> * The DCQ is using the "All Data Centers" option.
>
> * The relevant Data Center was added after the policy was installed on the Security Gateway.
>
> 
>
> **Solution:**Install the policy on all Security Gateways that have this DCQ in their policy.
### Data Center Status Issues {#DCS Issues}
* Scenario 1: Data Center in "Disconnected" status, when its connectivity to the Management sever is fine.
> **Symptoms:**
> * The Data Center status is "Disconnected" in the "`cpstat vsec`" command output and in SmartConsole.
> * The Status and Type fields appear as "N/A".
> * There are no actual connectivity issues between the Management Server and the Data Center.
>
>
>
> **Cause:**
>
> This occurs when the Data Center contains no imported objects.
> Because CloudGuard Controller does not scan Data Centers with zero imported objects, SmartConsole currently treats such Data Centers as "Disconnected".
> **Solution:**Delete unused Data Center objects, or initialize the scan by right-clicking the Data Center object and selecting "Import".
---
# 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