Workflow for Setting Up a High Availability Cluster in Azure

Step 1: Deploy with a Template in Azure

Deploy this solution through the Azure Portal. If you use a different environment than the standard Azure environment, see Using a Different Azure Cloud Environment

Notes:

  • Important: Do not change the resource's names. For more information, refer to Changing Template Components.

  • By default, every Check Point Security Gateway and Security Management Server's WebUI is accessible from the internet by browsing to http://<virtual-machine-public-ip>. Restricting access to the WebUI is possible by configuring a Network Security Group, or by configuring the Check Point Gateway and Management Server settings.

Parameter

Description

Cluster object name

Name of the Cluster object resource group.

Credentials

Public key or user name and password for SSH connections to the Cluster Members.

Subscription

Azure subscription into which the Cluster object is deployed.

Resource group

Azure resource group into which the Cluster object is deployed.

Location

Location into which the Cluster object is deployed.

License

Type of license:

  • Bring your own license (BYOL)

  • Pay as you go (PAYG)

Virtual Machine size

Size of each Virtual Machine instance in the Cluster object.

SIC

SIC key to the Security Management Server.

Network setting

  1. Pre-existing Virtual Network and its subnets

  2. Name of a new Virtual Network and subnets, into which the Cluster object is deployed.

Notes:

When you use pre-existing subnets, make sure that:

  • No other Virtual Machines are deployed in those subnets.

  • Define UDRs properly for each subnet. See Step 3: Set Up Internal Subnets and Route Tables.

  • A Network Security Group (NSG) is associated with your Frontend subnet to connect the External Load Balancer and Cluster Member.

Network Security Group

The Network Security Group (NSG) that you attach to the Vnet.

Note:

  • If you select an existing NSG from a different Resource Group, create roleAssignment on the NSG with contributor permissions for the Cluster’s managed identity.

Availability Zones

Use Availability Set (default) or Azure Availability Zones for your High Availability.

  • First Cluster Member is be deployed in zone 1.

  • Second Cluster Member is deployed in zone 2.

Notes:

  • Support for Azure Availability Zones is available with template version 20190303 and above.

Enable CloudGuard metrics

  • Enable CloudGuard metrics to send statuses and statistics collected from Cluster Members to the Azure Monitor service.

  • If the CloudGuard metrics are enabled as part of Cluster HA deployment, then these items occur:

    • The CloudGuard metrics agent starts to send metrics each minute.

    • The CloudGuard metrics are sent to the Azure Monitor resource immediately after the VMSS deployment is completed.

    • To see the CloudGuard Metrics, go to VM view -> Monitoring -> Metrics -> Metric Namespace - "cloudguard".

Note - If the System Assigned Managed Identity is disabled, then you cannot use CloudGuard metrics.

Deploy the Load Balancer with floating IP

If you select: yes, the Load Balancer will be deployed with Floating IP enabled.

Default value: no.

Deploy with Public IP Prefix

If you select yes, the Cluster will be deployed with a Public IP Prefix.

Note: The Public IP prefix length (addresses range) is determined based on the VIPs number and could contain unused addresses.

Create new or existing Public IP Prefix

If you select: new, select the IPv4 prefix length.

Note: If you use an existing Public IP Prefix – make sure that the IP Prefix has free addresses range for the Cluster members, the Load Balancer, and the cluster VIPs.

Number of Virtual IP's

The number of virtual IP Addresses to deploy for the Cluster.

Quick connect to Smart-1 Cloud

If you select yes (and provide the tokens), the Cluster deploys with a secured communication tunnel to the Security Management.

Smart-1 Cloud Token Member A

The token you generate in Smart-1 Cloud portal.

Smart-1 Cloud Token Member B

The token you generate in Smart-1 Cloud portal.

Tags

Azure tags (Name, Value) that you attach to the selected resources.

Notes:

  • Smart-1 Cloud (Check Point’s Management Server as a Service) is a recommended option to start using CloudGuard Network Security Gateways.

  • Follow the instructions in sk180501 to create tokens for each member and paste them into the applicable fields.

Components of the Check Point Solution

  • Frontend subnet

    The NSG is associated with the frontend subnet and allows all inbound and outbound TCP and UDP traffic.

  • Backend subnet

  • Two Virtual Machines configured as a Check Point Cluster

  • Internal Load Balancer

  • External Load Balancer

  • Public IP address for each Cluster Member

It is not possible to deploy other Virtual Machines in the solution's subnet.

  • You can create a new Virtual Network, or deploy into an existing Virtual Network.

  • Web and App subnets are not deployed automatically.

  • It does not deploy any other Virtual Machines in the solution's frontend and backend subnets.

  • Virtual Machines that are launched in the backend subnets, may need Internet access to finalize provisioning. Launch these Virtual Machines only after you have applied Hide NAT rules on the Cluster object to support this type of connectivity.

  • The Check Point First Time Configuration Wizard automatically deploys after you have set up the Cluster object. The Cluster object is configured based on the parameters you apply.

  • After the First Time Configuration Wizard completes, the Virtual Machines automatically reboot.

Important - If you deploy the solution to an existing Virtual Network, confirm that an NSG is associated with the frontend subnet that allows all inbound and outbound TCP and UDP traffic. An NSG is necessary to connect to Cluster Members successfully.

Step 2: Set Credentials in Azure

By default, the system assigned managed identity is deployed. If you want to create your own service principal, make sure you set credentials and assign privileges to necessary resources.

Azure Credentials and the Automatic Service Principal

The Check Point Cluster template automatically deploys the Virtual Machine with a system-assigned managed identity and assigns a Contributor role to the Cluster resource group. Therefore, you do not have to create your own service principal. For more information, see What is managed identities for Azure resources?

After you deploy a Check Point Cluster, the automatic credentials can be found in Azure Portal > Resource groups > cluster_resource_group > Access control (IAM). There are two service principals for each Cluster Member, each with a Contributor role.

  • If you delete the Cluster Member's Virtual Machine, the credentials are also deleted.

  • Service principals never expire.

  • We recommend using the default managed identity as a best practice.

Important - When you use an existing VNet to deploy the solution, you must assign a Contributor role to the Cluster VNet resource group for each Cluster’s managed identity created by the deployment because they are not automatically assigned.

Creating Your Own Service Principal

See Create a Microsoft Entra application and service principal that can access resources.

Field

Parameter

Name

<Application_Name>

Example:

check-point-cluster

Application type

Web-App / API

Sign-on URL

https://localhost/<Application_Name>

Example:

https:/localhost/check-point-cluster

  • Application ID

    client_id

  • Key Value

    client_secret

  • Tenant ID (Directory ID)

    tenant

Best Practice - We recommend that you set the key to never expire. Go to your resource.

Step

Description

1

Click Access control (IAM) > Add.

2

Select your role.

3

Select your AD application.

4

Click Save.

5

Set the client_id and client_secret on each of the Cluster Members.

From Expert Mode, run this command on each Cluster Member:

# azure-ha-conf --client-id '<ApplicationId>' --client-secret '<Key Value>' --force

Example:

# azure-ha-conf --client-id '5c1896fe-26b6-4a5b-8c81-34ae07c09a24' --client-secret '2G6E_|]Y&|@Il(L}-O>g' --force

Note - Use single quotes to avoid shell expansion.

6

Make sure the file syntax is correct. From Expert Mode, run this command on each Cluster Member:

# python3 -m json.tool $FWDIR/conf/azure-ha.json

7

Reload the Cluster Azure configuration. From Expert Mode, run this command on each Cluster Member:

# $FWDIR/scripts/azure_ha_cli.py reconf

Step

Description

1

Remove your service principal.

2

From Expert Mode, run this command on each Cluster Member:

# azure-ha-conf --system-assigned --force

3

Assign the two service principals to each resource and to Cluster Members.

For more information, see Components of the Check Point Solution > Notes about the template.

4

The service principal deploys automatically.

If you want to create a new service principal, assign the privileges to the necessary resources and to Cluster Members.

For more information, see Manage access using RBAC and the Azure portal.

Step 3: Set Up Internal Subnets and Route Tables

You can use the Azure portal or the CLI to add internal subnets. You will now add the Web and App subnets to your Virtual Network.

For each internal subnet, you have to create an Azure routing table with these UDRs:

#

Name

Address prefix

Nexthop-type

Nexthop-address
1

<web-subnet>-local

<10.0.3.0/24> Virtual Network -
2

web-subnet-to-other-subnets

10.0.0.0/16 Virtual appliance ILB-internal-address 10.0.2.4
3

web-subnet-default

0.0.0.0/0 Virtual appliance ILB-internal-address 10.0.2.4

#

Name

Address prefix

Nexthop-type

Nexthop-address
1

<app-subnet>-local

10.0.4.0/24 Virtual Network -
2

<app-subnet-to-other-subnets>

<10.0.0.0/16> Virtual appliance ILB-internal-address 10.0.2.4
3

app-subnet-default

0.0.0.0/0 Virtual appliance ILB-internal-address 10.0.2.4

If traffic inspection is needed inside the Web/App subnets, override Rule 1 in the route tables, "<web-subnet>-local", and "<app-subnet>-local".

Important - Associate the newly created routing table with the subnet to which it belongs.

If the subnet houses the Security Management Server that manages the Cluster Members, add these routes below as well. This allows the Security Management Server to communicate directly with each Cluster Member, without passing through the Active Cluster Member.

Name

Address prefix

Nexthop-type

Nexthop-address

subnet-name-cluster_member1-management

cluster_member1-internal-address/32

<10.0.2.10/32>

Virtual appliance

cluster_member1-internal address

<10.0.2.10>

subnet-name-cluster_member2-management

cluster_member2-internal-address/32

<10.0.2.20/32>

Virtual appliance

cluster_member2-internal address

<10.0.2.20>

Step 4: Set Up Routes on Cluster Members to the Internal Subnets

Step

Description

1

Connect over SSH to each of the Cluster Members.

2

Log in to Gaia Clish, or Expert mode.

3

Add this route:

  • In Gaia Clish, run these two commands:

    set static-route <Virtual-Network-IP-address/Prefix> nexthop gateway address <eth1-router-IP-address> on

    save config

  • In Expert mode, run this command:

    clish -c 'set static-route <Virtual-Network-IP-address/Prefix> nexthop gateway address <eth1-router-IP-address> on' -s

Example:

set static-route 10.0.0.0/16 nexthop gateway address 10.0.2.1 on

Parameter

Description

<Virtual-Network-IP-address/Prefix>

Specifies the prefix of the entire Virtual Network.

Example:

10.0.0.0/16

<eth1-router-IP-address>

Specifies the first unicast IP address on the subnet, to which the eth1 is connected.

Example:

10.0.2.1

  • Routes to the private address space IP ranges specified in RFC 1918 are configured automatically.

  • If the Virtual Network has several non-contiguous address prefixes, repeat the command for each prefix.

  • For vNET Peering:

    • Add a compatible route on each peer network.

    • Add the route for vNET peering to each Cluster Member.

Step 5: Configure Cluster Objects in SmartConsole

Step

Description

1

Click the Objects menu > More object types > Network Object > Gateways and Servers > Cluster > New Cluster.

2

Select Classic Mode.

The Gateway Cluster Properties window opens.

3

Enter a Name.

Example:

checkpoint-cluster

4

  1. Select the Cluster Members tab.

  2. If managing this cluster from Smart-1 Cloud:

    • Click Add > Existing Cluster Member.

    • Select the relevant Cluster member from the list.

    • Continue from step "e".

    Otherwise:

    • Click Add > New Cluster Member.

  3. In the Name field, enter the first Cluster Member name.
    Example: member1

  4. In the IPv4 address field:
    If you manage the Cluster from the same Virtual Network, enter the Cluster Member's private IP address. Otherwise, enter the Cluster Member's public IP address.

  5. Click Communication.

  6. In the One-Time Password field, enter the SIC key you set up in Azure.

  7. In the One-Time Password field, enter the SIC key again.

  8. Click Initialize.

    If the One-time-password is confirmed, the Trust State field shows "Trust Established".

  9. To close the Communication properties window, click Close.
    If the Activation Key is confirmed, the Trust State field shows Trust Established.

  10. Click OK.

  11. Run the steps above again to create the second Cluster member.

5

In the IPv4 Address field, enter the public address allocated for the Cluster.

Note - You can find the Cluster IP address in the Azure portal when you select the Active Cluster Member's primary NIC > IP configuration > "cluster-vip".

6

Click Network Management > Get Interfaces > Get Interfaces With Topology.

If this warning appears:

"Topology and Anti-Spoofing settings that are already defined will be overwritten. by results of this operation that contradict them, if any. Do you want to continue?"

Click Yes.

7

Configure the interfaces eth0 and eth1.

  1. Double-click the interface eth0.
    The Network eth0 window shows.

  2. From the General tab, in the Network type field:

    • For version R81.10 and higher, select Cluster.

    • For version R81 and lower, select Cluster + Sync.

  3. In the Virtual IPv4 field, enter the private VIP address and subnet mask of the Cluster.
    In the diagram, the private VIP address is: 10.0.1.6
    Note - You can find the Cluster private VIP address in the Azure portal when you select the Active Cluster Member primary NIC > IP configuration > "cluster-vip".

  4. From the Network eth0 window, click Topology and disable the Anti-Spoofing.

  5. Click OK.

  6. Double-click the interface eth1.
    The Network eth1 window shows.

  7. From the General tab, in the Network type field, select Sync.

  8. From the Network eth1 window, click Topology and disable Anti-Spoofing.

  9. Click OK.

8

Remove VPN blade if not needed.

9

Install the applicable Access Control Policy on the Cluster object.

Step 6: Configure NAT Rules

To create new objects in SmartConsole, see Creating Objects in SmartConsole

No

Original
Source

Original
Destination

Original
Services

Translated
Source

Translated
Destination

Translated
Services

Install
On

Comments

1

Virtual Network

Virtual Network

*Any

= Original

= Original

= Original

Cluster object

Avoid NAT in the Virtual Network

2

App-subnet

App-subnet

*Any

= Original

= Original

= Original

Cluster object

 

3

App-subnet

*Any

*Any

App-subnet (hidden address)

= Original

= Original

Cluster object

 

4

Web-subnet

Web-subnet

*Any

= Original

= Original

= Original

Cluster object

 

5

Web-subnet

*Any

*Any

Web-subnet (hidden address)

= Original

= Original

Cluster object

 

Notes:

  • Rule 1 - You have to define this NAT rule manually.

  • Rules 2 - 5: The NAT rules are created in SmartConsole when you create a new network object and select Add automatic address translation rules according to the instructions below.

  • Traffic between the Web-subnet and the App-subnet is based on the UDR rules. Each subnet has its own routing table.

For each internal subnet, create a network object:

Step

Description

1

Double-click the Web-subnet object.

The Web-subnet object window shows.

2

Select the NAT tab > Add automatic address translation rules.

3

In the Translation method field, select Hide > Hide Behind Gateway.

4

In the Install on Gateway field, select the Cluster object.

5

Click OK.

This creates the automatic NAT rules.

6

Install the applicable Access Control Policy on the Cluster object.

Step 7: Set Up the External Load Balancer in Azure

By default, the template you deploy creates an External Load Balancer, with the name frontend-lb, which faces the Internet.

The External Load Balancer sends health probes to TCP port 8117 to determine the health of the CloudGuard Network Security Gateways.

Create the load balancing rules in the Azure portal to allow incoming connections:

  1. Go to External Load Balancer > Load balancing rules > Add.

  2. Click Add.

  • You cannot use these ports for forwarded traffic:

    • 80

    • 443

    • 444

    • 8082

    • 8080

    • 8117

  • Do not change the health probe port.

  • In the Floating IP field, use the same value used in Deploy the Load Balancer with floating IP from step 1.

  • The Check Point Cluster resource group includes an NSG associated with the frontend subnet. By default, the NSG allows all outbound and inbound traffic.

  • The Load Balancer can be set up to listen on additional ports or on additional public IP addresses.

For more information, see Multiple Frontends for Azure Load Balancer. For an example, go to Step 9: Configure the Load Balancer to Listen on Multiple IP Addresses in Azure.

Step 8: Create Dynamic Object LocalGatewayExternal in SmartConsole

In SmartConsole, create the Dynamic object called LocalGatewayExternal.

This object represents the private Cluster Member's IP addresses.

You use this Dynamic object in the next step.

  1. In SmartConsole, click the Objects menu > Object Explorer.

  2. From the top toolbar, click New > Network Object > Dynamic Objects > Dynamic Object.

  3. In the Enter Object Name field, enter (case-sensitive):

    LocalGatewayExternal

  4. Click OK.

  5. Close the Object Explorer.

Step 9: Configure the Load Balancer to Listen on Multiple IP Addresses in Azure

Configure the Load Balancer to listen on additional public IP addresses. This setup is useful if you want the Security Gateway to secure multiple web applications, each with its own public IP address.

Configure the Load Balancer to listen on a second public IP address on TCP port 80, and then forward the traffic to the Check Point CloudGuard Security Gateway to TCP port 8083.

Step

Description

1

In the Azure portal, select the Load Balancer called frontend-lb.

Note - The Load Balancer is in the resource group you created.

2

Allocate a new public IP address:

  1. Click Frontend IP configuration> Add.

  2. Select a Name.

    Example: <cluster>-app-2

  3. Select the public IP address you created.

  4. Click OK.

3

Add a load balancing rule.

  1. Click Load balancing rules > Add.

  2. Enter the rule name.

    Example: <cluster>-app-2-tcp-80

  3. In the Frontend IP address field, select the newly created Frontend IP address.

  4. In the Protocol field, select TCP.

  5. In the Port field, enter 80.

  6. In the Backend port field, enter 8083.

  7. In the next Backend pool field, select the pre-existing Cluster pool.

  8. In the Health probe field, select the health probe created by default by the template (TCP, port 8117).

  9. In the Session persistence field, select None.

  10. Set the desired Idle timeout, in minutes.

  11. In the Floating IP field, use the same value used in Deploy the Load Balancer with floating IP from step 1.

  12. Click Add

Configure Access Control Rule in SmartConsole

Rule Name

Meaning / Value
Rule No 1
Name

Desired rule name
Source *Any
Destination LocalGatewayExternal

When Floating IP is enabled, use the External Load Balancer Frontend IP Address
VPN *Any

Service and Applications

The service object that represents the internal port

Data

 *Any

Action

Accept

Track

Log

Install On

*Policy Targets

Load Balancer Conditions

The Active Cluster Member uses NAT to forward traffic that belongs to the two web applications, to the right web server.

NAT rules are defined with the special Dynamic Object.

The Dynamic object LocalGatewayExternal represents the private IP addresses of the external interface of Member 1 and Member 2.

For more information, see Step 8: Create Dynamic Object LocalGatewayExternal in SmartConsole.

No

Original
Source

Original
Destination

Original
Services

Translated
Source

Translated
Destination

Translated
Services

Install
On

1

All_Internet

LocalGatewayExternal

TCP 8081

= Original

s AppHost

https

Policy Targets

2

*All_Internet

LocalGatewayExternal

TCP 8083

= Original

s WebHost

http

Policy Targets

Note - When Floating IP is enabled, set Original Destination to be the External Load Balancer Frontend IP Address.

Step 10: Configure VPN

In SmartConsole, create a Network Group object to represent the encryption domain for the Cluster.

For more information, see the Check Point Security Management Administration Guide for your Management Server version.

Step

Description

1

Create a Network Group object to represent the encryption domain of the Cluster:

  1. In SmartConsole, click the Objects menu > Object Explorer.

  2. From the top toolbar, click New > Network Group.

  3. In the Enter Object Name field, enter the desired name.

  4. Click the + icon and select the applicable network objects.

  5. Click OK.

  6. Close the Object Explorer.

2

Edit the Cluster object:

  1. In SmartConsole, from the left navigation panel, click Gateways & Servers.

  2. Double-click the Cluster object.
    The Gateway Cluster Properties window shows.

3

Define your Network Group as the encryption domain of the Cluster object:

  1. In SmartConsole, from the left navigation panel, click Gateways & Servers.

  2. Double-click the Cluster object.
    The Gateway Cluster Properties window shows.

  3. In the Cluster object left tree, click Network Management > VPN Domain.

  4. Select Manually defined.

  5. In the right corner of this field, click the [...] button and select the Network Group object you created in Step 1.

4

Define the VPN community:

  1. In the Cluster object left tree, click IPsec VPN.

  2. In the section This Security Gateway participates in the following VPN Communities, select the applicable VPN community.

5

Define the outgoing VPN interface:

  1. In the Cluster object left tree, click IPsec VPN > Link > Selection.

  2. In the IP Selection by Remote Peer section, select Always use this IP address > Statically NATed IP, and then enter the Cluster's Internet Routable IP address.

  3. In the Outgoing Route Selection section:

    1. Click Source IP address settings.

    1. Select Manual.

    1. Choose Selected address from topology table.

    1. Select the private Cluster object VIP address.

    1. Click OK.

  4. In the Tracking section, select the desired option.

  5. Click OK to close the Gateway Cluster Properties window.

6

Configure the VPN Community to use Permanent Tunnels:

  1. In SmartConsole, click the Objects menu > Object Explorer.

  2. In the left tree, clear all boxes except for VPN Communities.

  3. Double-click the VPN community, in which this Cluster object participates.
    The VPN Community window shows.

  4. In the left tree, click Tunnel Management.

  5. Select Set Permanent Tunnels.

  6. Select the applicable option.

  7. Click OK to close the VPN Community properties window.

  8. Close the Object Explorer.

7

Install the applicable Access Control Policy on the Cluster object.

Step 11: Configure multiple VIP (optional)

Notes:

  • The multiple VIP feature is supported starting from image build number 1266. You can view the build number in /etc/cloud.version.json.

  • You can skip this section if you already deploy the environment using the “Number of Virtual IPs” template parameter. The Cluster is deployed with automatic multiple VIP configuration.

For each member:

Step

Description

1

Open the $FWDIR/conf/azure-ha.json file in Edit mode.

2

Make sure that the "clusterNetworkInterfaces" field is in the new configuration

  • Old configuration:

    "clusterNetworkInterfaces": {
      "eth0":  [
        "<privateIpAddress>",
        "<publicIpAddress>"
      ]
    }

  • New configuration:

    "clusterNetworkInterfaces": {
      "eth0":  [
        {
           "name": "<ipConfigurationName>",
           "addr": "<privateIpAddress>",
           "pub": "<publicIpAddress>"
    }
      ]
    }

3

Configure new VIPs in the the "clusterNetworkInterfaces" field.

Example:

"clusterNetworkInterfaces": {
  "eth0":  [
    {
      "name": "cluster-vip",
      "addr": "<privateIpAddress>",
      "pub": "<publicIpAddress>"
  },
{
      "name": "cluster-vip-2",
      "addr": "<privateIpAddress>",
      "pub": "<publicIpAddress>"
  }
 ]
}

Where:

  • name - The name of the VIP

  • addr - The private IP address to associate with the VIP, the private address that another resource cannot use. This is the equivalent of eth0[0] in the old configuration.

  • pub - The public IP address resource's name to associate with the VIP. IP address must be an existing resource of public type IP and cannot be in use by another resource. This is the equivalent of eth0[1] in the old configuration.

4

Attach your new VIP/s to the active member in Azure portal.

5

Run: "$FWDIR/scripts/azure_ha_cli.py restart" on both instances.

6

Run: "$FWDIR/scripts/azure_ha_test.py" on both instances and make sure all tests were passed.

7

Test the failover and make sure all VIPs are transferred from the standby to the active member.

 

Note -To attach VIP from another resource group, specify the full path of the public IP object in the "pub" field in this format:

"/subscriptions/<subscription>/resourceGroups/<your resource group>/providers/Microsoft.Network/publicIPAddresses/<your public IP resource>"

 

Example of the .conf file:

{
   "credentials": "IAM",
   "tenant": "fffcccbb-1762-34ec-cba1-26283ecbef78",
   "subscriptionId": "eeeccc34-1762-34ec-2343-26283ecbefff",
   "location": "northeurope",
   "environment": "AzureCloud",
   "resourceGroup": "ResourceGroupNmae-Test",
   "proxy": "",
   "virtualNetwork": "vnet01",
   "clusterName": "ClusterName-Test",
   "templateName": "ha",
   "clusterNetworkInterfaces": {
     "eth0": [
       {
          "name": "cluster-vip",
          "addr": "10.4.0.6",
          "pub": "ClusterName-Test"
        },
        {
          "name": "vip2",
          "addr": "10.4.0.11",
          "pub": "SecondVipName"
         }]
     },
     "debug": false
}