Configuration Steps

Step 1 Create a Microsoft Entra ID and Service Principal

With the Microsoft Entra ID and Service Principal, the Check Point Security Management Server monitors the creation and status of the VMSS, so it can complete the provision of these gateways.

  1. Connect to portal.azure.com.

  2. Click Active Directory -> App registrations -> New registration.

  3. Create new registration:

    1. Select a meaningful Name.

    2. Supported account types - Select Single tenant.

    3. Redirect URL - Select Web, and type https://localhost/vmss-name - instead of: vmss-name. It can be any name.

    4. Click Register.

    5. Open Certificates and secrets pane -> click New secret key.

    6. Add the duration for the key.

    7. Backup the key. You cannot look at the key later. Save it now.

After you create the application, write down these values, for "Configure the Check Point Security Management Server"

  • Application ID

    client_id

  • Key value

    client_secret

  • Tenant ID

    tenant

  • Directory ID

Note - We recommend that you set the key to never expire.

Step 2 Install the Check Point Security Management Server

We recommend you to use Smart-1 Cloud (Check Point's management server as a Service) to manage CloudGuard Network Azure Virtual Machine Scale Sets (VMSS).

Refer to Quantum Smart-1 Cloud Administration Guide > Using the settings > Cloud Management Extension (CME) Configuration for step-by-step instructions for enabling CME in Smart-1 Cloud management.

These steps are required only if you do not have an installed Check Point Security Management Server.

If you already have the Check Point Security Management Server installed, skip to Step 3.

Step 3: Configure the Check Point Security Management Server

Do these steps to manage the Virtual Machine Scale Sets with the Check Point Security Management Server:

  1. Downloading and Installing the Latest CME (Cloud Management Extension) Version of CME.

  2. Configuring the Cloud Management Extension (CME) on the Security Management Server

  3. Configure the Security Policy in SmartConsole.

    Important - The name of the policy has to match correctly the value that you configured in "Install the Check Point Security Management Server".

Note - By default, each Check Point Security Gateway and Security Management Server's Gaia Portal is accessible from the internet by browsing to http://<virtual-machine-public-ip>. Restriction of access to the Gaia Portal is possible by configuring a Network Security Group, or by configuring the Check Point Security Gateway and Management Server settings.

Step 4: Deploy the Check Point VMSS and Assign the Microsoft Entra ID Application

Deploy the CloudGuard Network Security - Firewall & Threat Prevention from the Azure Marketplace.

Assign the Azure Active Directory application as described in Add a minimum role of Reader to the VMSS and the VNET. See Assign application to role.

For more about Managed identities, see the Azure documentation overview.

Notes:

  • Newly provisioned Security Gateways automatically receive the latest published Security Policy. You have to install the policy on the existing Security Gateways to update their Security Policy.

  • Auto Scaling Security Gateway objects are automatically created and deleted according to the current environment. Therefore, we do not recommend that you use specified objects in rules. In additions, we do not recommend that you manually edit those objects.

  • In case of scale out event, the latest released Check Point image is used to deploy the new Virtual Machine.

  • When you use the template version 20181017 or above:

      1. Fast Deployment Images (Blink) with a pre-installed Jumbo Hotfix Accumulator is used.

      2. In case of scale out event, the newer Virtual Machine uses the latest released Check Point image.

        For R80.10, the latest release image might include a newer Jumbo Hotfix Accumulator version.

    For more information, see these SK articles:

  • By default, each Check Point Security Gateway and Security Management Server's Gaia Portal is accessible from the internet at https://<virtual-machine-public-ip>. It is possible to control the access to the Gaia Portal. Configure a Network Security Group, or configure the Check Point Gateway and Management Server settings.

Step 5: (Optional): Deploy External Application Gateway

Prerequisites:

  • A domain in your possession.

  • A subnet that can contains only the External Application Gateway in the VMSS's VNET.

To deploy an External Application Gateway:

From the Azure Portal, go to Application gateways > deploy a new Application Gateway.

To complete the HTTP settings creation, click Add.

To complete the Routing rule creation, click Add.

Review and create this Application Gateway.

Note – The Application Gateway deployment completes in about 20 minutes or less.

Important - The Health Probe checks the communication up to the application server. Hence, the Backend health tests passes only when the full solution is deployed and configured.

Edit the route table:

  1. Add a route from the VMSS Frontends subnet to the Application Gateway subnet.

  2. Go the external VMSS subnet by default named "VMSS-Frontend" > Routes > click Add.

    • Name: To-external-application-gateway

    • Address prefix: the address prefix of the external Application Gateway subnet

    • Next hop type: Virtual network

  3. Click OK.

Add a static route for the VMSS instances:

  1. Connect to the command line on the Security Management Server.

  2. Log in to the Expert mode.

  3. Download the static_route_config_sh script from this link.

  4. Edit static_route_config_sh and enter the EXTERNAL_AGW_SUBNET_CIDR and EXTERNAL_VMSS_SUBNET_DEFAULT_GATEWAY values.

  5. Copy the script to the Management Server, use this name:

    $MDS_FWDIR/conf/static_route_config_<CONFIGURATION-TEMPLATE-NAME>.sh

  6. Assign the execute permission to the shell script, run:

    chmod u+x $MDS_FWDIR/conf/static_route_config_<CONFIGURATION-TEMPLATE-NAME>.sh

  7. Make sure there are no syntax mistakes in the shell script, run:

    sh -n $MDS_FWDIR/conf/static_route_config_<CONFIGURATION-TEMPLATE-NAME>.sh

  8. Configure CME and set the relevant template to use this script, run:

    autoprov_cfg set template –tn <CONFIGURATION-TEMPLATE-NAME> –cg $MDS_FWDIR/conf/static_route_config_<CONFIGURATION-TEMPLATE-NAME>.sh

Step 6: (Optional): Deploy Internal Application Gateway

Prerequisite - A subnet that can contains only Internal Application Gateway in the VMSS's VNET. This subnet is different from the one created in step 6.

To deploy Internal Application Gateway:

From the Azure Portal, go to Application gateways > deploy a new Application Gateway.

To complete a Path-based routing rule, click Add. If it necessary, you can create more Path-based rules.

Review and create this Application Gateway.

Note – The Application Gateway deployment completes in about 20 minutes.

Cleanup

After the deployment of the Internal and External Application Gateways (steps 6 and 7), go to the VMSS resource group and delete the External Load Balancer object created automatically in step 5. The External Load Balancer is named by default: frontend-lb.

Note - For outbound inspection, use the Internal Load Balancer

Step 7: (Optional) Set Up Traffic Manager External Endpoints

Microsoft Azure Traffic Manager allows you to control how network traffic is distributed to VMSS that run in different regions.

When the Traffic Manager receives a DNS request, it selects an available endpoint in the closest region to return the DNS response.

To set up Traffic Manager External Endpoints:

Step Instructions

1

From the Azure portal, navigate to the Traffic Manager profile created in the step 7.

2

In the Traffic Manager profile, select Configuration and enter this information in the required information:

  • In the Protocol field, enter: HTTPS

  • In the Port field, enter: 443

3

In the Traffic Manager profile, select Endpoints, click Add and enter this information in the required field:

  • In the Type field, select External endpoint

  • In the Name field, enter the Endpoint's name

  • In the Fully-qualified domain name (FQDN) or IP field, enter a DNS Record Set FQDN that includes the VMSS Instances' public IP addresses.

    Note - DNS Record Set is used for one VMSS only.

  • In the Location field, select the geographic location from which the DNS Record Set FQDN defined in previous step will be accessible.

  • In the Health Checks field, select:

    • Enable: We recommend selecting this option: Health Checks determine if to send traffic to the Endpoint.

    • Always serve traffic: No Health Checks run. Traffic is always sent to the Endpoint.

4

After creating the Endpoint makes sure the Monitor Status is set to Online.

5

To create morel Endpoints with different DNS Record Sets, do steps 3 and 4 again.

Step 8: Set Up the External Load Balancer

By default, the template you deploy creates an external (Internet facing) Load Balancer that:

  • Listens on TCP port 80 on the static public IP address of the External Load Balancer.

  • Forwards the traffic it receives to the pool of Check Point CloudGuard Security Gateways on TCP port 8081.

  • Uses TCP health probes on port 8117 to know the health of the Check Point CloudGuard Network Security Gateways.

Notes:

  • You cannot use ports 80, 443, 444, 8082, 8117, and 8880 for forwarded traffic.

  • In addition, you cannot use the ports defined in sk52421 (used by Check Point software), and 32768 – 65535 as defined in sk162619 (FWD daemon listening on multiple random high ports).

  • Do not change the health probes.

  • The Check Point VMSS Resource Group includes a Network Security Group (NSG). By default, the NSG allows all outbound and inbound traffic.

You can configure the Load Balancer to listen on more ports and/or on more public IP addresses. See Load balancing with Multiple front-ends.

For use cases, see these links:

Step 9: Configure Inbound Protection

Note - If HTTPS Inspection is necessary, see Configuring HTTPS Inspection.

Step 10: Configure Outbound and East-West Protection

Configure UDR tables and NAT rules for Southbound-Northbound and East-West traffic protection. See the diagrams of the traffic flows.

You can configure the Check Point VMSS to examine Outbound and East-West traffic across internal subnets.

You can use this to examine and control traffic of different web clients such as

  • Servers and containers that must have software and image updates from repositories located outside the Virtual Network.

  • Virtual desktop environments that run in the Virtual Network and that access the Internet or each other.

  • Servers that send traffic to each other.

To configure inspection of the traffic from servers in internal private subnets, you have to route traffic through the Check Point VMSS. Use the Check Point Internal Load Balancer as the Next hop in the private subnet UDR. The Internal Load Balancer then forwards all the traffic to one of the Check Point Security Gateways.

Note - The Internal Load Balancer deploys by default as part of the solution template and is automatically configured. It is configured to listen and forward all TCP or UDP traffic on HA Ports. The Internal Load Balancer gets an automatically assigned name backend-lb. Probes monitor the health of the Check Point VMSS on the TCP port 8117 from source IP address 168.63.129.16.

Configuring Protection for the VMSS VNET

Note - The Internal Load Balancer private IP address is static. To find it, browse into the Internal Load Balancer named backend-lb.

For more information, see User Defined Routes.

Configuring Protection for External VNETs

Limitations:

This section is only supported when:

  • The template version is 20180711 or above.

  • The applicable peered VNETs use private address spaces as defined in the RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

  • Global VNET peering is not supported. See Azure requirements and constraints.

Do these steps below for inspection of traffic between a subnet in the peered VNET, and a subnet in the VMSS VNET, or a different peered VNET.

Use case:

Your hub-spoke network topology uses peered VNETs and you want the VMSS, as the hub, to examine the traffic.