Azure Data Center Objects - Inaccessible - Check Point CheckMates

R81.20 CloudGuard Controller Administration Guide

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

14 Replies

avivs

Employee

‎2025-03-1412:03 PM

Show option menu

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Hello,

1. Data Center Objects has caching on the gateway.

The time this cache is stored varies according to the configuration. by default, it is 1 week (10080 minutes), and can be changed to be up to 1 month.

The configuration should take place in the file $FWDIR/conf/vsec.conf and uses the following values;

# TTL (mins) for objects expiration on GW in case there are no updates

# from the Controller

# min value=5

# max value=43200

# Default value: 10080

enforcementSessionTimeoutInMinutes=10080

See CloudGuard Controller configuration parameters documentation for additional information

This is a security feature that aims to prevent cases of obsolete data being used in firewall rule enforcement.

2. $FWDIR/log/cloud_proxy.elg file exists in R81.20 and is the first log to look at when facing issues with data center objects.

If you wish to attach it here (or send it privatly) we will be happy to have a look and advise our inputs on it.

3. If you have already opened an SR, I will be happy to take a look if you can share the SR # of a dm.

Thanks,

Aviv Shabo

CloudGuard Network R&D

3\ \ \ Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-03-1401:11 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Thanks for the reply Aviv,

I have opened a case but it is with our Collaboration Support partner just now.

So cloud_proxy.elg is on the CloudGuard Controller i.e. the management server? (We have Smart-1 Cloud)

I just found the CloudGuard Controller ATRG (sk115657) and just checked the logs (blade:CloudGuard IaaS). It shows mapping ok with failures every few minutes.

I'll attach a few screenshots that might help.

inaccess_objs.png

Preview file

17 KB

No Azure Objects.png

Preview file

19 KB

test_success.png

Preview file

4 KB

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

AaronCP

Advisor

‎2025-03-1401:13 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Your first point is relevant if the SMS/MDS loses connectivity to the Data Centre Object. My understanding is if the SMS/MDS loses trust with the Generic Data Centre object (remote certificate is changed, certificate in local certificate store gets deleted/corrupted), then by design the gateway will clear the object cache, impacting traffic until trust is re-established - so worth bearing in mind.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

avivs

Employee

‎2025-03-1508:52 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to AaronCP

So there are indeed 2 scenarios here:

Mgmt is no longer able to complete data center scanning
Mgmt is no longer able to communicate with the gateway

In the first case, as long as communication between mgmt and gw is working, Data Center Objects (DCOs) time to live (TTL) will get extended, this is because the CloudGuard Controller that is running on the Management, understands that this is a scanning issue, so enforcement should continue working using existing information.

In the second case, the Management is no longer able to send updates to the gateway, on the gateway side, we cannot assume the reason for this, so once the TTL will expire, these DCOs will not longer be enforced.

For this reason, our best practice is to use DCOs for whitelisting (allow rules) rather than blacklisting (blocking rules).

Looking at the validation errors you are getting suggest that the access you provided for scanning your Azure data center was enough to properly establish a connection, but not enough to scan any supported Data Center Object.

Our best practice for providing Azure access to CloudGuard Controller is to create a service principal.

The minimum recommended permission is Reader.

You can assign the Reader permission in one of these ways:

Assign to all Resource Groups, from which you want to pull an item

Add the permission on a subscription level

If you hadn't had a chance to have a look at the CloudGuard Controller for Azure section of the CloudGuard Controlelr admin guide, I might be worth your while to do so now.

1\ \ \ Kudo

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-03-1702:34 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

So I logged in this morning and the Azure integration is working as expected again. The logs I posted showing failures on the afternoon of 14th March are the only ones and correlate with the object outage.

I will follow up with the support ticket and try and get a reason.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-03-1404:36 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Seems like the issue started on at the time of the first mapping failure (13.14:29).

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

In response to wanartisan

Contributor

‎2025-03-1711:52 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Another query I have is over the log entries for these mapping failures. On the day of the issue there were lots of these that say "Mapping of Data Center [Azure-DC_Integration] failed. Next mapping is in 300 seconds." (usually the time is 32 seconds). However, most of these are High severity alert and only a few were Critical.

I want to set up a SmartTask to alert us about issues with CloudGuard (as per the documentation). I understand the built-in trigger responds to critical alerts only. Can anyone advise on the difference between High and Critical in what looks like the same alert?

Kudos

In response to wanartisan

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

tomlev

Employee

‎2025-03-1803:28 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Hi @wanartisan, you can open the object of the Data Center in SmartConsole and click 'test connection' to see possible reason for the failure, or look in cloud_proxy.elg for more information on the failure.

As for the logs level, there is no difference in the error type, CG Controller will send High level errors on cloud mapping failures or GW update failures, and if they failed for some number of times in a row, it would send a critical log.

The reason is that some failures may happen once in a while due to network or even the cloud vendor.

The reason that you got next scan in 300 seconds is due to a backoff mechanism that delays the next scan after a failure, and 300 is the default max value for the backoff.

2\ \ \ Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-03-1805:44 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to tomlev

Thanks for the clarification, Tom.

Check Point support are looking at the cloud_proxy.elg file now (Smart-1 Cloud; I have no access).

On the bright side, I have learned a lot from the forum on this. I've checked the TTL on our gateways and it is 7 days, as aviv suggested (I just rewatched a Cloudguard Controller Unleashed webinar and I'm sure it said 3 days...).

I can proceed now with more confidence that production traffic would be unaffected by these event and that we will have more assurance around catching them happening. All that is missing is a reason why........

I'll let you know how that goes.

Kudos

In response to wanartisan

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

AaronCP

Advisor

‎2025-03-2402:39 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

Hey @wanartisan,

As I mentioned previously, if there is a loss of trust between your management platform and the remote server (https cert renewal on the remote server, for example), there will be an impact (this was confirmed to us by our Diamond Engineer). In the event of a loss of trust, the cache for the cloud object on the gateway will be cleared until trust is re-established. This is by design. You'll need a way of monitoring the renewal of the https certificates.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-03-2510:48 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to AaronCP

TAC are looking at this issue with another case and I will be having a remote session with them this week.

The issue appeared again on Monday but this time without any errors(?) so my SmartTask didn't let me know.... It is intermittent, so it's not due to https certs as far as I can tell.

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

(1)

PEO

Participant

‎2025-11-1304:53 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

This is more a question than an answer:

I see, that you checked the connection by "curl_cli --verbose https://management.azure.com --cacert $CPDIR/conf/ca-bundle-public-cloud.crt"

Is access from the SMS to https://management.azure.com sufficient to get full functionality?

I'm going to use a proxy for this access and expect it only to allow this access then.

Thanks in advance.

Kudos

- https://login.windows.net

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Eliba

Employee

‎2025-11-1608:00 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

In response to PEO

Hi @PEO,

No, we use the curl command to https://management.azure.com only to test basic connectivity to the cloud provider. In reality, the Cloudguard Controller talks to several endpoints.

For a basic CloudGuard Controller setup, the management server must be able to reach at least:

- https://management.azure.com

Tags:
controller

Kudos

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Contributor

‎2025-12-0405:01 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

To close this off - TAC had a look at this but it was difficult replicate. As mentioned, they were looking at the same/similar issue with another customer. Eventually the problem just went away, so I assume a fix was put in on the Smart-1 platform (that we use for management).

Kudos