- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Rules with GCP Datacenter objects (tags) dropped o...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rules with GCP Datacenter objects (tags) dropped on the instances of Cloudguard MiG
We successfully connected CME to GCP, all is done per the process. Identity Awareness API enabled and configured. Datacenter object are visible on the Management server. Now, the rules with GCP Datacenter objects (tags) are not being hit. If we enter the subnet manually, the rule is hit. How to troubleshoot this issue, specifically on the gateways in GCP ?
version: R81.20
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had some sessions with TAC. It was the TTL set in vsec.conf that was too high, so the datacenter objects were not updated correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, did you see any errors in SmartConsole logs (blade:"CloudGuard IaaS") or in $FWDIR/log/cloud_proxy.elg?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Filter @tomlev mentioned is very useful, I got similar issue solved before with it.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the useful info.
I had already checked the blade='Cloudguard IAAS" filter and it shows that "Mapping of DataCenter GCP finished.. Mapping took 52 seconds etc..."
Also the $FWDIR/log/cloud_proxy.elg reflects the same.
Is there any log on the gateway instances I can check ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not certain, but maybe see if there are any other files with names that include words proxy or cloud in $FWDIR/log or /var/log dir
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There seems to be a file on the gateways: cloud_config.log, but apart from this:
2023-10-12 05:29:22,864::INFO::run_cmd Executing: dbget installer:self_update_in_progress with:
data=None
env=None
expected_return_codes=(0,)
2023-10-12 05:29:22,872::INFO::Handling error:
Output:
Retry number 1 out of 3
happening twice (it seems the third time it was successfull )
There is also a file, which is a symbolic link cloud-user-data -> /opt/CPcge/log/user_data, but that file doesn't exist.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Under the same filter, are there any errors related to the GW update?
Try adding to the filter "AND severity:Critical"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see errors with that filter from a couple of weeks ago:
Failed to update Data Center objects on gateway gcp-controller--vm-checkpoint-gateway-szrc
And this for all three instances of the GCP MiG.
But when I look at the logs of today, I see that the instances have updated the Data Center objects successfully:
Data Center objects were successfully updated on gateway gcp-controller--vm-checkpoint-gateway-szrc. 1 IPs updated, 0 IPs removed.
Still, the rules with the data center object is not hit. I have put a rule under it, with explicit IP (manually created) of the object, and that one is hit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would try do remote with TAC to see if there is something we might be missing here...
Cheers,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had some sessions with TAC. It was the TTL set in vsec.conf that was too high, so the datacenter objects were not updated correctly.