Azure Security Management Server - Status problem - Lost

[Don_Paterson]

The R81.20 image/template of the SMS deployed into Azure has a problem (still) with the any new SMS deployed from the Marketplace right now.

It reports a Status as Lost ( Status: Connection with 'cpmgmt' is lost ). Screenshots attached.

I hoped that the new R81.20 image upload on 30th September would fix that but it does not appear to have fixed it.

https://support.checkpoint.com/results/sk/sk132192

Solution Template / Image	Version	Release Date	What's New
R81.20- images for Gateway & Management	-	30 Sep, 2024	Integrated CME Take 279 R81.20 New Recommended Jumbo - Take #84 Resolved an issue with CloudGuard CME not being pre-installed in Public Cloud Management images B991001648

The status does not appear to affect functionality. It did not last time and so far no problem this time.

 

 

[Nir_Shamir]

Hi,

that's because you are connected for the first time to the Management Server's Public IP and he put that IP in the Management Server Object. The management server can't monitor it's own public IP because it's not attached to it , it's on Azure which is doing the NAT.

To solve it edit the Management Server object and change its IP address to its private IP, which is configured on the instance , and publish the changes. The issue will be resolved.

This won't affect your connectivity to the Management Server through the Public IP.

[Don_Paterson]

Thanks Nir, that has fixed it.
But this is a new issue and I have not seen it in the years before when deploying the SMS into Azure.

Is that documented?
I cannot see anything in Check Point Reference Architecture for Azure or Deploying a Security Management Server (checkpoint.com)

Regards,

Don

[Nir_Shamir]

I don't think it's something new, although I don't remember if it was before R81.20.

bottom line , the Management object is configured with the IP address you are connecting to it in the first time.

with On-Premise we don't usually connect to a NAT IP , because usually you are connecting to the management server from the same network.

in the Cloud it's usually different.

[Don_Paterson]

Understood, but... comms were broken to the gateways which were managed over the public IP.

I changed it back to fix it.

[Nir_Shamir]

So you need to use Management behind NAT option.

Activate NAT on the Management Server object with its public IP and install policy on the GW's.

There are a few SK's on it:

https://support.checkpoint.com/results/sk/sk66381

https://support.checkpoint.com/results/sk/sk171665

[Don_Paterson]

Cool. I completely understand and I did that configuration to fix it.
It is fairly common in the on-prem classic deployment.

BUT the problem is that this was not an issue before and the NAT configuration procedure is not documented.
I have deployed quite a few SMS instances into Azure in the last 4 or 5 years and I never saw this OOB behaviour until last month.

The deal here is that something changed and it's pretty obvious, and whatever magic was there has gone away, or Azure changed something.

The SMS deployment in Azure has never been documented in an SK or dedicate Admin Deployment Guide.
What there is is not easy to find and it is now inaccurate so that a new deployment has this status problem and it doesn't look good if it's not documented, even in the outdated documents and videos.

In the ideal situation sk109360 would include steps to deploy the SMS in Azure (including the new extra NAT steps required), or even better a link to a dedicated SK.
The minimum should be that the Azure Reference SK is updated with a Note or line to say that the OOB (Marketplace SMS) needs extra configuration for the public IP configuration.

The Marketplace template (Azure Portal)  does not give an option for private IP address only, so that this is always going to happen with an R81.20 deployment of the SMS in Azure. 

I know that Smart-1 Cloud is the recommended management platform for customers who do not have regulations or requirements that prevent it.

There are two Check Point CloudGuard certification training courses and they have never had to include documentation to setup the Static NAT on the SMS object.
I will update the courseware team since that will need to be added to the training course lab steps.

https://community.checkpoint.com/fyrhh23835/attachments/fyrhh23835/CloudNetworkSecurityforum-board/3...

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_Azure_VMSS_GWLB/Content/Topics-Azure-...

https://support.checkpoint.com/results/sk/sk109360

Regards,

Don

[Jeff_Engel]

Hi @Don_Paterson  Likely a dumb question but is the latest recommended jumbo applied on this mgmt server?

BR!

Jeff

[Don_Paterson]

I like to believe that there is no such thing as a dumb question 🙂

Yes, we did try to install the latest recommended JHFA onto the R81.20 Azure SMS. The behaviour did not change.

Only changing the Main IP to private and setting up NAT worked.

I managed to mangle the SMS by messing around with those settings and the topology and lost confidence, so that the new deployment needed to be abandoned. I started again and stuck to the procedure of changing the Main IP to private and settings the Static NAT, leaving everything else as is.

Regards,

Don

[yairra · Accepted solution]

Hi,
We have identified the issue, which caused by the migration of our public IP SKU in the templates (Basic to Standard) that we released a few months ago.
According to Azure documentation on Public IP SKUs, there are differences in the default security settings:

We are currently working on updating the deployment templates to include an explicit inbound NSG rule (on the management’s eth-0 NSG) to allow inbound traffic from the management public IP.

Meanwhile as a workaround, you can add such an NSG rule:

Thanks,
Yair

[Don_Paterson]

Thank you.