topic CloudGuard NVA ingress traffic in Cloud Firewall

CloudGuard NVA ingress traffic

Lars_de_Mooy — Thu, 12 Dec 2024 15:53:38 GMT

Hi all,

I am working on a cloudguard test environment and most of my setup is working. I now come to the point that i want to create a ingress rule and i am using the cme_menu in expert mode. Afer a lot of testing and rebuilding i now finaly have the menu working, I tryed using the postman method but that keeps giving me the 401 error and i am not sure what to fill in the Base64-encoded SICClosed key.

now i am not sure what to fill in the menu. The menu is "seeing" my external IP address so i can use that to nat traffic to my server. The source IP should be any so i guess i fill in 0.0.0.0/0 ? Do i also need to create a nat rule on the filewall itself with the same ? I

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Thu, 12 Dec 2024 15:57:50 GMT

When i install the policy it gives me an error..

I hope someone can help me out here that would be great

Re: CloudGuard NVA ingress traffic

Jeff_Engel — Thu, 12 Dec 2024 16:02:24 GMT

Hi @Lars_de_Mooy

I have a meeting right now but did you by chance catch the Under the Hood webinar on Tuesday regarding this topic?

https://www.brighttalk.com/webcast/16731/624271

I will check back in with you afterwards.

BR!

Jeff

Re: CloudGuard NVA ingress traffic

Don_Paterson — Thu, 12 Dec 2024 16:02:29 GMT

Are you using a specific Deployment Guide?

What version are you using?

Where is the management server positioned?

Is this a POC, so you should get in touch with your local Check Point SE or cloud expert?

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/Azure_Virtual_WAN.htm?TocPath=Azure%20Virtual%20WAN%7C_____0#Azure_Virtual_WAN

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_vWAN/Content/Topics-Azure-vWAN/Introduction.htm

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Thu, 12 Dec 2024 16:09:17 GMT

Hi Jeff, i found that usefull webinar, and used it for a part of my setup, i did not yet watched it all to the end. I will watch the webinar till the end when ik find some time to do. Hopefully you can point me in the direction i get the feeling all is almost working. I allready have my vnets pointing to the NVA and i see all the trafic in my logs and i can filter the traffic. Now i need the ingress so i can test the solution and create some inbound nat rules and stuff.

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Thu, 12 Dec 2024 16:11:56 GMT

Hi Don,

For the management i use open server R82, and the NVA GW's i use R81.20. For deplyment i used the guides you posted, and the webinar that Jeff mentioned. All is working almost so i dont think i need the cloud expert for now.

Re: CloudGuard NVA ingress traffic

Don_Paterson — Thu, 12 Dec 2024 16:16:28 GMT

Great.

You could try to tail the cme.log and look for errors.

tail -f /var/log/CPcme/cme.log

It may be too much but since the CME talks to the management server API and then the API goes to the CPM process, you could also tail their enhanced log files.

tail -F $FWDIR/log/cpm.elg

tail -F $FWDIR/log/api.elg

Could it be IAM (permissions | roles ) in the Resource Groups?

Re: CloudGuard NVA ingress traffic

Jeff_Engel — Thu, 12 Dec 2024 16:52:25 GMT

Great to hear you found the webinar. To answer your NAT question, yes you need a corresponding NAT rule in your security policy.

Re: CloudGuard NVA ingress traffic

Don_Paterson — Thu, 12 Dec 2024 16:57:10 GMT

Maybe the other issue is SMS API remote access (GUI Clients/Trusted Clients) (?)

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuide/Content/Topics-SECMG/Managing-Security-through-API.htm?Highlight=management%20api

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Thu, 12 Dec 2024 18:52:08 GMT

I was able to run the oython script so could that indicate that there is no issue with permissions on the resource group?

I need to dig into the logs thanks for pointing me to it.

I need more understanding on how the solution works and what the CPM CME and API are for could someone share some detailed documentation about it ?

I will dive into it in the morning and watch the webinar

the service cme test is also running without any error

python3 /opt/CPcme/features/vWAN/vWAN_automatic_script.py "tenant="<Active-Directory-Tenant-ID>"" "client_id="<Client-ID>"" "client_secret="<Client-Secret>"" "subscription="<Azure-Subscription>"" "managed_app_resource_group_name="<Managed-App-Resource-Group-Name>"" "nva_name="<NVA-name>"" "sic_key="<SIC-key>"" "policy="<Policy-Name>"" "atp="<True/False>""

Re: CloudGuard NVA ingress traffic

Don_Paterson — Thu, 12 Dec 2024 18:51:56 GMT

Cool. I may have been completely off the mark on the IAM front.

Will put some text together for understanding CME and API from my perspective.

Re: CloudGuard NVA ingress traffic

Don_Paterson — Thu, 12 Dec 2024 20:38:08 GMT

The Check Point Security Management Server (SMS) has the Postgres database system running in it.

Stored inside the Postgres DB are all the Check Point objects, policies and config. Pretty much everything you see in the SmartConsole apart from the logs.

Customer specific config on top of the out of the box config.

The management API allows customers to bypass the SmartConsole and interact with the Postgres database via the API (for example, using command line).

That means that they can manually manage objects and rules, or fully automate that via the API.

https://sc1.checkpoint.com/documents/latest/APIs/#introduction~v1.9.1%20

Since CME is integrate in the SMS and needs to get some configururation, that can be done via the SMS API (but also using the autoprov-cfg command in some cases).

The autoprov-cfg command is the original command for configuring the CME (if I understand properly).

The CME config includes building a controller (at the 36 minute mark in Jeff’s video), which represents the connection/binding with Azure and the subscription.

In some cases we can run autoprov-cfg show all to see the controller. Meaning that we can see out controller build specifically to plug into Azure.

More controllers can be built for plugging into AWS and GCP etc.

One CME, many controllers.

It’s like the old AD binding.

Through that connection (the controller) the CME can interact with the public cloud.

Going further…

To understand the history and one of the original purposes of the CME you need to know about cloud scaling solutions.

Scaling solutions like Azure VMSS (Virtual Machine Scale Sets) and AWS Auto Scaling Groups are at the heart of cloud elasticity.

You can create a VMSS, which is a group of one or more identically configured VMs (in our case CloudGuard SG VMs) and along with that comes the Azure Load Balancer, which distributes connections amongst the CloudGuard SGs.

If you deployed, for example, 2 VMSS instances (CloudGuard gateway VMs) and then they get to a point where they are experiencing high CPU usage because of growing traffic load then Azure would detect that and spin up a new identical CloudGuard gateway to help the current ones because they have reached and exceeded a CPU high water mark (80%).

That is the scale out event.

The CME (Cloud Management Extension) was developed as a new add-on the SMS, with the objective to interact with the cloud and be able to detect scale out events.

That is only possible by having the CME talk to the Azure API (yet another API).

Given the right details the CME can go into the Azure subscription via the API and discover the specially tagged VMSS solution and within there the instances.

The scale out event brings a new instance, which the CME detect by regularly checking on the VMSS.

And so, the main task of the CME was initially (and still valid and important now) is to monitor scaling solutions and whenever a scale out event happens the CME detects that and then update the SMS (via the SMS’s API)

Working together with the SMS API the CME gets the new Scale set VM (CloudGuard SG) automatically added to the SmartConsole (adding the gateway object into GATEWAYS & SERVERS) which includes getting the trust established between the SMS and the new SG, and then any software blades enabled (like IPS for example) on top of the already enabled FW blade.

After that the policy install happens, again automatically.

The CME learns the IP address of the new gateway so that all of that is made possible over the network.

The new SG is known to Azure (obviously) and Azure starts to send health probes to the new SG (port 8117 TCP – from IP 168.63.129.16).

When the new SG is ready and policy install is completed and the SG starts to respond to the health probes then the LB starts to forward traffic to the 3^rd SG.

Scale in event is all of that in reverse(kind of), and happens after no less than 5 minutes and when the low water mark is reached (60% aggregate CPU across the 3 SGs).

The Overview in here is a bit light weight and fluffy/cloudy.

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/Overview.htm

https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview

Behind a vWAN solution (the NVA) there is something like a VMSS (I believe it is VMSS but not like the normal VMSS) and the CME is involved in configuration within that solution.

I’m not experienced in the vWAN solution so Jeff can fill in the blanks and correct me if needed.

Hope that all makes sense and helps.

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 08:03:42 GMT

Hi Don, thanks for your great explaination and all the time that you spended on helping me understand the concepts better. All other comments are also highly apriciated !

I builded the test environment with the below video as a guide and i thougt Jeff referred to this video, i now also read the guides you linked me to.

https://community.checkpoint.com/t5/Cloud-Network-Security/Azure-Virtual-Wan-amp-CloudGuard-NVA-Integration-Workshop/m-p/183312#M268

Yesterday i watched Jeffs seminar https://www.brighttalk.com/webcast/16731/624271

Now i have a better understanding of howto work with Postman to connect to the SMS API, the seminar is great help for this.

I am now able to connect to the SMS API using postman following the instructions in Jeffs semiar.

Now when i run the postman Post Add Azure vWAN ingress rules the scripts is giving me the

"status-code": 200 and the request ID

But when i do the GET status

GET https://<Management_IP>/web_api/cme-api/status/<request_id>

i get

"details": "Account with id [account id] not found",

There is one part of Jeffs seminar thats not clear to me and thats the part that covers the POST Add an Azure account.

for adding the gateways to the management server i used the phyton script and used a account that i created. This is the same account that i now use in the POST Add Azure vWAN ingress rules in postman is that correct ?

This script worked with that account

When i run the autoprov-cfg show all this managed identity is filled in the "client_id" section.

Do i still need to run the POST Add an Azure account that was in the seminar or is that command creating the managed identity i allready used in the python script to add the gateways from azure in my SMS ?

When i do run the scipt POST Add an Azure account using the "application_id" that is the same as i see in autoprov-cfg show all and i used in the pyton script to add the gateways from azur to my SMS it gives me this error

"details": "The management does not run in a MDS environment",

I am really close to the solution now

Again thanks for the help all end i hope to fix this soon as i realy like the ingress functionality it brings me.

Re: CloudGuard NVA ingress traffic

Don_Paterson — Fri, 13 Dec 2024 09:11:10 GMT

Just quickly on this part:

GET https://<Management_IP>/web_api/cme-api/status/<request_id>

It might be easier to use the command line (on the management server for some of the api commands, or even all.

For example:

In expert mode run, mgmt_cli -r true cme-api/<cme-api-version>/<cme-command>

Have a look at the swaggerhub reference

-r true assumes you are a root user in gaia (admin is) and avoids authentication and is great for quick single operations (not so much for bulk)

This can be a useful command too:

service cme test

https://sc1.checkpoint.com/documents/latest/APIs/#cli/cme-api~v2%20

https://app.swaggerhub.com/apis-docs/Check-Point/cme-api/v1.2.2

Are you using this section of the guide as a reference?

https://sc1.checkpoint.com/documents/iaas/webadminguides/en/cp_cme/content/topics-cme/azure_virtual_wan.htm#Azure_Virtual_WAN

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 09:16:26 GMT

The test is fine i used that before to test and was all fine.

Again i also added the gateways and all is working except for this last small issue ...

Testing basic configuration structure...
Testing templates...
Testing nbtemplate...
Testing controllers...
Testing azurecontroller...

provisioned gateways:

Testing management configuration...
Testing management connectivity...

**********
Tests finished
**********
[Expert@cpms01:0]#

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 09:52:14 GMT

The last link you sended is not working can you provide me the working link please ?

Re: CloudGuard NVA ingress traffic

Don_Paterson — Fri, 13 Dec 2024 09:56:14 GMT

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/Azure_Virtual_WAN.htm

Here you go.

The other link only works on my mobile phone browser 🙄

What command did you run to get this?

"details": "The management does not run in a MDS environment",

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 10:07:23 GMT

https://x.x.x.x/web_api/v1.8/cme-api/v1.2.2/accounts/azure

The main question is do i still need to do this ?

I am allready capable of adding gateways to the management server using the managed identity and running the python script. Or is this account needed for adding the ingress rule ?

When i try to create te rule with

https://172.211.215.122/web_api/v1.8/cme-api/v1.2.1/azure/virtualWANs/accounts/id of the managed identity i see in the "service cme test"/resourceGroups/mrg-cp-vwan-managed-app-xxxxxxx/inboundRules/xxxxxx

But when i do the GET status

GET https://<Management_IP>/web_api/cme-api/status/<request_id>

i get

"details": "Account with id [id of the managed identity i see in the "service cme test"] not found",

is that the managed identity i see in the "service cme test" output or do i need a second account...............

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 10:35:37 GMT

In that documentation they refer to this

Prerequisites:

A Security Management Server or Multi-Domain Security Management Server with CME Take 288 and higher, with a valid license.
An Azure account with reader permission for the NVA's Resource Group configured in CME configuration.

When i click on the "Azure account" link i get to the page that explains the account needed

To see the current controllers used by the Management Server connected to the cloud environments, run:

autoprov_cfg show controllers

utoprov_cfg show controllers

The client ID i see here i also use in the

https://172.211.215.122/web_api/v1.8/cme-api/v1.2.1/azure/virtualWANs/accounts/client id of the above screenshot/resourceGroups/mrg-cp-vwan-managed-app-xxxxxxx/inboundRules/xxxxxx

this gives me

I spended a full week on this so i realy need a success to proceed with my happy life 😛

Re: CloudGuard NVA ingress traffic

Lars_de_Mooy — Fri, 13 Dec 2024 11:16:09 GMT

I managed to create the account like in the webinar now i have this...