CloudGuard GCP auto-provisioning error

[AyGit]

Hi guys

I'm trying to launch auto-provisioning of the GWs ceratd in GCP environment, however I cannot see the GWs in the SMS and I have an error following the command 'service cme test'.

I'll be pleased for your help.

The autoprov command:

autoprov_cfg init GCP -mn check-point-mgt -tn my-configuration-template -otp AZERTY1234 -ver R80.30 -po ProdPolicy -cn GCP-PRod -proj xxxxxx -cr $FWDIR/conf/xxxxxx-yyyyyyyy.json

service cme test output:

provisioned gateways:

Testing management configuration...
Testing management connectivity...
run_local Executing: ['mgmt_cli', '--root', 'true', '--format', 'json', 'login'] with:
data=None
env=None
Return code= 0
Output={
"api-server-version" : "1.5",
"last-login-was-at" : {
"iso-8601" : "2020-05-04T15:08+0000",
"posix" : 1588604896
},
"read-only" : false,
"session-timeout" : 600,
"sid" : "aaaaa",
"standby" : false,
"uid" : "bbbbb",
"url" : "https://127.0.0.1:443/web_api"
}
New management session: bbbbb
The take-over-session API failed: : Unrecognized parameter [__no_such_parameter__]
Discarding management session: ccccc
The get-interfaces-sync API failed: : Unrecognized parameter [__no_such_parameter__]
**********
All tests passed successfully
**********

[Dmitry_Gorn]

Hi,
There are no actual errors in the output. The following lines can be ignored (this is a known issue that will be fixed in future CME versions):
New management session: bbbbb
The take-over-session API failed: : Unrecognized parameter [__no_such_parameter__]
Discarding management session: ccccc
The get-interfaces-sync API failed: : Unrecognized parameter [__no_such_parameter__]

In order to check the exact issue please open a support ticket to have a support engineer confirm correct CME configurations.

Regards,
Dmitry

[Shay_Levin]

Hi,

where is the SMS ? ( network topology)

what did you choose in the cloudguard MIG template, configure the gateways with the public ip or private ip ?

[AyGit]

Hi Shay

The architecture is the same as the document. I put the SMS in a dedicated VPC named 'mng', subnet 10.2.0.0/24.
The peering is established between 'External VPC' security-subnet (10.1.0.0./24) and 'mng' VPC. So internal flow is OK.

I choosed public IP for SMS and GWs.
The template is include in the attached file.

Regards

[Shay_Levin]

Hi Again, 

Few comments:

1. In the auto-provisioning command, you used sic:  AZERTY1234  , which I believe that you choose.

On GCP, After you start deployment of CloudGuard AutoScale Template , on the deployment manager output you will see a SIC key that was generated automatically, you will need to take the value and use it on the template.

You can create new template easily 

autoprov-cfg add template -tn my-configuration-template-2 -otp <SIC-Value-You-Got-After-AutoScale-Depoyment> -ver R80.30 -po ProdPolicy

 ** On AWS and Azure , you have a filed to put your own SIC when you fill the template parameters for AutoScaling 

      In GCP you don't have this option.

2. Regarding the Management, When you deploy Management on GCP , you don't have the option to choose if you want that the management object would use the public IP. ( it always use the private IP)

On the Autoscaling template for the gateways you choose to use for managing the public IP

In this case, when you will open SmatConsole, you will see that the Management object has private IP and the gateways objects have public ip.

The management will access the GW from outside to the public IP of the GW and the gateways know only the private IP of the Management so they will access the private IP of the Management.

It will not work.

A workaround would be to edit the Management object and to replace the private ip with the public ip.

3. Also, On the management, did you install the latest CME ?  https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[AyGit]

Hey,

1. Indeed, I retrieved in the deployment manger section the correct SIC and put the value in the command injected in the SMS.

2. I will use the workaround, as soon as I can retrieve the GWs I created in GCP. Tried again but still nothing ...

3.Done also

Hope, I'll have a solution 🙂

[Shay_Levin]

Pls drop me an email when you are available next week.
Let’s look on it together.
shayl@checkpoint.com

[AyGit · Accepted solution]

Thanks Shay

Issue resolved through the 2 actions:

1. Activate API & Services in GCP
2. Add a Data Center object in order to retrieve the components in GCP 
   New >> Servers >> Data Centers >> name 'GCP' >> Import Service Account json file >> Test Connection

Then the autoprov command is a success! 
A reminder of the command:
         autoprov_cfg init GCP -mn check-point-mgt -tn my-template -otp AZERY1234 -ver R80.30 -po Standard -cn GCP -proj AAAAAAA -cr $FWDIR/conf/AAAAAAA-BBBBBBB.json

[chethan_m]

Hi @Shay_Levin,

I have a quick question about GCP Autoscaling MIG deployment.

Let's say in the GCP environment there are two GCP Projects (e.g., 'Project A' and 'Project B'), each deployed with different configuration templates (-tn) and managed by the same management server.

The 'Project A' MIG instances are already deployed during autoprov_cfg initialization with the -proj parameter set to 'Project A's project ID and -tn being the configuration template name used during 'Project A' MIG deployment.

autoprov_cfg init GCP -mn <MANAGEMENT-NAME> -tn <CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME> -cn <CONTROLLER-NAME> -proj <GCP-PROJECT> -cr <GCP-SERVICE-ACCOUNT-KEY-PATH>

Now, if we want to add the second MIG deployed in 'Project B', we use:

autoprov_cfg add template -tn <CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME>

But in this command, we are not specifying the project ID at all. How is the management server going to identify the MIG instances without the project ID? Is it only based on the template name and the network tags associated with the MIG instances?

Since the controller for GCP is already added and authenticated with the credentials used during initialization, the guide states:

"Each controller in the configuration must have unique credentials, with the exception of the Multi-Domain Security Management Server configuration."

Or either of the below commands are supported to use?

autoprov_cfg add template -tn <CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME> -cn <CONTROLLER-NAME> -proj <GCP-PROJECT> -cr <GCP-SERVICE-ACCOUNT-KEY-PATH>

or

autoprov_cfg add template -tn <CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME> -cn <CONTROLLER-NAME> -proj <GCP-PROJECT>

Could you please suggest.

Regards,

Chethan

[Shay_Levin · Accepted solution]

Hi, sorry for the delay, I’ve been traveling for the past two weeks.

The answer is that you don’t need to associate a template with a controller.

Each time the CME runs, it fetches data from all configured controllers. Each MIG, VMSS, or ScaleSet is tagged with the CME management name and template, allowing it to determine the correct gateway configuration.

[chethan_m]

No worries, @Shay_Levin. Thank you very much for the response. Understood.