Additional Information

Testing and Troubleshooting

You can use the APIs to retrieve information about the cluster resource group.

Use these commands on each Cluster Member to confirm that the cluster operates correctly:

Run these commands in the Expert mode:

cphaprob state

cphaprob -a if

Example:

[Expert@HostName:0]# cphaprob state

Cluster Mode: High Availability (Active Up) with IGMP Membership

Number Unique Address Assigned Load State

1 (local) 10.0.1.10 0% Active

2 10.0.1.20 100% Standby

Use the cluster configuration test script on each Cluster Member to confirm it is configured correctly:

The script verifies:

  • The configuration is defined in the $FWDIR/conf/azure-ha.json file, which is created by the ARM template.

  • A Primary DNS server is configured and works.

  • The machine is set up as a Cluster Member.

  • IP forwarding is enabled on all network interfaces of the Cluster Member.

  • It is possible to use the APIs to retrieve information about the cluster's resource group.

  • It is possible to log in to Azure with the Azure credentials in the $FWDIR/conf/azure-ha.json file.

  • Calibration of ClusterXL configuration for Azure. cluster

To get the latest version of the test script:

Important - In a Cluster, you must configure all the Cluster Members in the same way.

  1. Download the latest version of the test script.

    • For R80.40 and above, use this link.

    • For R80.30 image version R80.30.273.590 and above, use this link.

    • For other images, use this link.

    Note - To get the image version, see sk116585.

  2. Copy the downloaded script to a directory.

  3. Connect to the command line and log in to the Expert mode.

  4. Back up the current $FWDIR/scripts/azure_ha_test.py script:

    cp -v $FWDIR/scripts/azure_ha_test.py{,_backup}

  5. Copy the latest script to the $FWDIR/scripts/ directory:

    cp -v /<path to the downloaded script package>/azure_ha_test.py $FWDIR/scripts/

  6. Assign the required permissions:

    chmod -v 755 $FWDIR/scripts/azure_ha_test.py

To run the script on each Cluster Member:

  1. Connect to the command line.

  2. Log in to the Expert mode.

  3. Run the script with this command (do not change the syntax):

    $FWDIR/scripts/azure_ha_test.py

    If all tests were successful, this message appears:

    All tests were successful!

    Otherwise, an error message appears with information to troubleshoot the problem.

A list of common configuration errors:

Message

Recommendation

The attribute (ATTRIBUTE) is missing in the configuration

 

Primary DNS server is not configured

Failed to resolve (host)

The Cluster Member is not configured with a DNS server.

Failed in DNS resolving test

Confirm that DNS resolution on the Cluster Member works.

You do not seem to have a valid cluster configuration

Make sure that the Cluster Member configuration on the Check Point Security Management Server is complete and that the Security Policy is installed.

IP forwarding is not enabled on Interface (Interface-name)

Use PowerShell to enable IP forwarding on all the network interfaces of the Cluster Member.

failed to read configuration file: /opt/CPsuite-R80/fw1/conf/azure-ha.json

The Azure Cluster Member configuration is not up-to-date or written correctly.

Testing credentials

Failed to log in with the credentials provided. See the exception text to understand why.

Testing authorization

(Exception)

Make sure the Azure Active Directory service account you created is designated as a Contributor to the cluster resource group.

Simulate a cluster failover:

For example, shut down the internal interface of the Active Cluster Member.

  1. On the current Active Cluster Member, run in the Expert mode:

    ip link set dev eth1 down

  2. In a few seconds, the second Cluster Member has to report itself as the Active Cluster Member.

    Examine the cluster state on each Cluster Member in the Expert mode:

    cphaprob state

  3. On the former Active Cluster Member, run in the Expert mode:

    ip link set dev eth1 up

If you experience issues:

  • Make sure you have a configured Azure Active Directory Service Account.

    The service has to have:

    • Contributor privileges to the resource group

    • At least minimum privileges on the Cluster Member deployment resources. See Changing Template Components.

  • To make the networking changes automatically, the Cluster Members have to communicate with Azure. This requires HTTPS connections over TCP port 443 to the Azure end points. Make sure the Security Policy that is installed on the Cluster Members allows this type of communication.

Using the Azure High Availability Daemon

The cluster solution in Azure uses the daemon to make API calls to Azure when a cluster failover takes place.

This daemon uses a configuration file $FWDIR/conf/azure-ha.json on each Cluster Member.

When you deploy the solution above from the template supplied, this file is created automatically.

The configuration file is in JSON format and contains these attributes:

Attribute name

Type

Value

debug

Boolean

true or false

subscriptionId

String

Subscription ID.

location

String

Resource group location.

environment

String

Name of the environment.

resourceGroup

String

Resource group name.

credentials

String

IAM. Indicates using automatic credentials on the Cluster Member Virtual Machine.

proxy

String

Name of the proxy.

virtualNetwork

String

Name of the Virtual Network.

clusterName

String

Name of the cluster.

templateName

String

Name of the template.

tenantId

String

ID of the tenant.

Note - If you use your own service principal, the credentials attribute contains:

  • Your Client-ID

  • Your Client-secret

  • Grant type client-credentials

  • Your Tenant ID

You can confirm that the daemon in charge of communicating with Azure runs on each Cluster Member.

From the Expert mode, run:

cpwd_admin list | grep -E "PID|AZURE_HAD"

The output should look like in this example:

APP        PID    STAT  #START  START_TIME             MON  COMMAND
AZURE_HAD  3663   E     1       [12:58:48] 15/1/2016   N    python /opt/CPsuite-R80.20/fw1/scripts/azure_had.py

Notes:

  • The script appears in the output:

    • The STAT column should show E (executing)

    • The #START column should show 1 (the number of times this script was started by the Check Point WatchDog)

To troubleshoot issues related to this daemon, generate debug. From the Expert mode, run:

  • To enable debug printouts:

    azure-ha-conf --debug --force

  • To disable debug printouts:

    azure-ha-conf --no-debug --force

The debug output is written to $FWDIR/log/azure_had.elg* files.

Using a Different Azure Cloud Environment

If you want to deploy your cluster in an environment other than the standard Azure environment, make sure to edit this file:

$FWDIR/conf/azure-ha.json

Example:

{
...
    "environment": "[Azure-cloud-environment]",
...
}

The Azure-Cloud-Environment has to be one of these:

  • Azure Cloud (the default global cloud environment)

  • Azure China Cloud

  • Azure US Government

  • Azure German Cloud

Procedure:

  1. From the Expert mode, run:

    azure-ha-conf --environment '<Azure-cloud-environment>' --force

  2. Make sure the file syntax is correct. From the Expert mode, run:

    python -m json.tool $FWDIR/conf/azure-ha.json

  3. Apply the changes. From the Expert mode, run:

    $FWDIR/scripts/azure_ha_cli.py reconf

    Note - If you deploy in the default global cloud environment, you can omit this attribute.

Important note about the service principal:

If you use any of these different environments, you have to create your own service principal. No default service principal is created.

Working with a Proxy

In some deployments, you can only access the Internet through a web proxy.

To allow the Cluster Member to make API calls to Azure through the proxy, edit the $FWDIR/conf/azure-ha.json file and add this attribute:

{
...
    "proxy": "http://[Proxy-Server]:[Proxy-Port]",
...
}
  • Proxy-Server is the host name or IP address of the web proxy server

  • Proxy-Portis the port on the proxy server

Note - The URL scheme has to be HTTP and not HTTPS.

Example:

{
...
    "proxy": "http://proxy.example.com:8080",
...
}

Procedure:

  1. Change the proxy settings. From the Expert mode, run:

    azure-ha-conf --proxy 'http://[Proxy-Server]:[Proxy-Port]' --force

  2. Make sure the file syntax is correct. From the Expert mode, run:

    python -m json.tool $FWDIR/conf/azure-ha.json

  3. Apply the changes. From the Expert mode, run:

    $FWDIR/scripts/azure_ha_cli.py reconf

Changing Template Components

The Check Point cluster's public IP address has to be in the same resource group as the Cluster Members.

These resources can be in any resource group:

  • Virtual Network

  • Network interfaces

  • Route tables

  • Storage account

Note - Make sure the resources Virtual Network and External Network Interfaces use the same automatic service principal with the same permissions.

Naming Constraints

Do not change the name of any resources.

Cluster Members VM names must match the Cluster name with a suffix of '1' and '2'.

Example:

<member_name1>

<member_name2>

Network Interface names must match the Cluster Member VM names with a suffix of '-eth0' and '-eth1'.

Example:

<member_name1-eth0>

<member_name1-eth1>

<member_name2-eth0>

<member_name2-eth1>

The IP address of the cluster has to match the configuration file.

By default it should match the cluster name.

Permissions

It is possible to assign service principal permissions to specific Azure resources. See sk116585 for information on how to find the image version.

To allow the cluster to update the necessary Azure resources on failover, you must assign the service principal at least these roles on resources in that list that follows, or on their related resource group:

Resource Type

Role

Any public IP address attached to the External Load Balancer

Virtual Machine contributor

Public Load Balancer

Network contributor

CloudGuard Virtual Machines

Reader

Cluster public IP address

Network contributor

Public IP address of each Cluster Member

Virtual Machine contributor

Virtual Network

Virtual Machine contributor

The external network interfaces (eth0) used by the Cluster Member

Virtual Machine contributor

Creating Objects in SmartConsole

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

Important - After you create an object, you must publish the session to save the changes in the management database.

To create a Host object:

  1. From the top right Objects Pane, click New > Host.

    The New Host window shows.

  2. In the Machine field, enter the private IP address of the machine.

To create a Network object:

  1. From the top right Objects Pane, click New > Network.

    The New Network window opens.

  2. Enter the Object Name (specifically the subnet name).

  3. Enter the Network address and Net mask.

To create a Service (port) object:

  1. From the top right Objects Pane, click New > More > Service.

  2. Select your TCP/UDP service.

  3. Enter the Object name.

  4. In the Enter Object Comment field, enter the port name.

  5. In the General field, select your Protocol.

  6. In the Match By field, select the Port number.

  7. Click OK.

To create a Network Group object:

  1. From the top right Objects Pane, click New > Network Group.

    The New Network Group window opens.

  2. Click + to select your internal subnets.

  3. Click OK.

Related Solutions

Upgrading a Check Point CloudGuard IaaS High Availability Solution to a Newer Version

Use these instructions to upgrade a deployed Check Point CloudGuard IaaS High Availability.

Notes:

  • The upgrade maintains the network configurations used in the existing Check Point CloudGuard IaaS High Availability solution.

  • The Cluster VIP resource name is cluster object name defined in deploying the solution.

Step

Description

1

Log in to the Azure portal.

2

Deploy a new Check Point CloudGuard IaaS High Availability in the needed version.

You need to deploy it to the same subnets as in the existing CloudGuard IaaS High Availability solution.

3

Provide an access role with Contributor permission for the new CloudGuard IaaS High Availability members to these resource groups:

  1. The resource group that contains the original VNet.

  2. The resource group that contains the old cluster IP addresses and the Load Balancer.

For more information, see Step 2: Set Credentials in Azure.

Note - Access is granted after a few minutes to an hour.

4

Setup routes on Cluster Members to the Internal Subnets.

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

5

Use the old cluster VIP address:

* On each Cluster Member, edit the configuration file located at $FWDIR/conf/azure-ha.json

Under "clusterNetworkInterfaces" -> "etho", replace the public IP name with the original cluster VIP resource id.

Example:

  • Old:

    "clusterNetworkInterfaces": {
      "eth0": [
        "10.72.0.6",
        "newHAClusterIp"
      ]
    },
  • New:

    "clusterNetworkInterfaces": {
      "eth0": [
        "10.72.0.6",
        "/subscriptions/123/resourceGroups/ha-rg/providers/Microsoft.Network/publicIPAddresses/originalHAClusterIp"
      ]
    },

6

Update the existing cluster object in SmartConsole:

Important - Do not install policy.

  1. In SmartConsole, double-click on the existing cluster object.

  2. In Cluster Members, update each member to match the compatible member of the new Check Point CloudGuard IaaS High Availability. Enter the IPv4 address, and then create a SIC connection (after resetting the current communication).

    If you are managing the cluster from the same Virtual Network, then enter the Cluster Member's private IP address. Otherwise, enter the Cluster Member's public IP address.

  3. In General Properties > Platform, update the version of your new CloudGuard IaaS High Availability, and then click Get.

  4. In Network Management:

    1. Double-click the interface eth0: In the Virtual IPv4 field, and then enter the private VIP address and subnet mask of the new CloudGuard IaaS High Availability.

    2. For both eth0 and eth1, modify the Members IPs to match the new CloudGuard IaaS High Availability members IP addresses. Also, enter the external private IPs in eth0 and the internal private IPs in eth1.

  5. For a VPN configuration in IPsec VPN, select Link selection.

    In the Outgoing Route Selection:

    1. Click Source IP address settings.

    2. Select Manual.

    3. Click Selected addresses from topology table.

    4. Select the private cluster object VIP address of your new CloudGuard Network High Availability for Azure.

7

Delete the External Load Balancer and the Internal Load Balancer. Dissociate the public cluster address created in the deployment of the new Check Point CloudGuard IaaS High Availability (step 1), then delete it as well. All of the above are located in the new Check Point CloudGuard IaaS High Availability resource group.

 

Important - Connectivity will be lost during the next steps.

8

Add the new Check Point CloudGuard IaaS High Availability's members to the backend pools:

For each Load Balancer used in the original solution, add the new members to the existing backend pools.

Make sure to select the right IP address (private internal for the backend Load Balancer and private external to the frontend Load Balancer).

9

Delete the old Check Point CloudGuard IaaS High Availability's members from the backend pools of each Load Balancer used in the original solution.

10

Install the applicable Policy on the cluster object.

11

Detach the cluster VIP from the original Check Point CloudGuard IaaS High Availability's members:

  1. Stop both original Check Point CloudGuard IaaS High Availability's members.

  2. Select the Active Cluster Member's primary NIC > IP configuration > "cluster-vip" in the original Check Point CloudGuard IaaS Cluster and delete it.

Initiate a failover in the new CloudGuard IaaS High Availability to attach the original cluster VIP to the new members.

 

Note – After an access role to the new members has been granted, the new CloudGuard IaaS High Availability now handles all traffic in the environment (inbound, outbound, E-W, VPN Tunneling).

Verify that all the traffic flows work as expected before proceeding, and that the cluster failover works as expected.

12

Delete the original Check Point CloudGuard IaaS Cluster and other redundant resources.

Note – If you are using resources from the old resource group, such as VNETs or cluster IP addresses, do not delete them.

Upgrade a Check Point Cluster to the CloudGuard IaaS High Availability Solution

Use these instructions to upgrade a deployed Check Point CloudGuard IaaS Cluster for the CloudGuard IaaS High Availability solution.

Notes:

  • All public IP addresses associated with the Cluster solution will change. This is due to the fact that a "Standard" SKU Load Balancer is used in the High Availability solution. "Basic" SKU public IP address resources cannot be associated with "Standard" SKU Load Balancers.

  • You can upgrade a "Basic" SKU public IP address resources to a "Standard" SKU public IP resource by following these

  • Update all VPN endpoints to use a new public VIP.

  • Before starting the upgrade, read the steps below and prepare an upgrade plan.

Step

Description

 

Important - Before you begin, verify that your deployed Management Server or Multi-Domain Server is able to manage the version of the CloudGuard IaaS High Availability solution that you intend to upgrade to. If the Management Server is an earlier version, you may need to install a Hotfix. Contact Check Point Support for more information.

1

Log in to the Azure portal.

2

Deploy a new Check Point CloudGuard IaaS High Availability solution.

Use the same network configurations as in the existing CloudGuard IaaS Cluster solution.

Important - When deploying an existing VNet, you must either create or modify the Network Security Groups, since they are not automatically created.

3

Provide an access role for the virtual network in which the new CloudGuard IaaS High Availability solution is deployed to the CloudGuard IaaS High Availability members.

For more information see Step 2: Set Credentials in Azure.

Note - Granting access will take a few minutes to an hour.

4

Setup routes on Cluster Members to the Internal Subnets.

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

5

Create load balancing rules:

  • For each NAT rule in the Cluster solution's External Load Balancer, create a compatible load balancing rule for the new CloudGuard IaaS High Availability's External Load Balancer.

6

Update your existing cluster object in SmartConsole:

Important - Do not install policy.

  1. In SmartConsole, double-click on the existing cluster object.

  2. In General Properties:

    1. In the Virtual IPv4 address, enter the public address allocated for the new CloudGuard IaaS High Availability.
      Note - The cluster IP address is found in the Azure portal by selecting the Active Cluster Member's NIC > IP configuration > "cluster-vip".

    2. If needed, update the version.

  3. Under "Cluster Members" update each member to match the compatible member of the new Check Point CloudGuard IaaS High Availability. Enter the IPv4 address and then create a SIC connection (after resetting the current communication).

    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.

  4. In Network Management:

    1. Double-click the interface eth0: In the Virtual IPv4 field, and then enter the private VIP address and subnet mask of the new CloudGuard IaaS High Availability.

    2. For both eth0 and eth1, Modify the "Members IPs" to match the new IP addresses of CloudGuard IaaS High Availability members.

      Enter the external private IPs in eth0 and internal private IPs in eth1.

  5. For a VPN configuration, click IPsec VPN > Link selection.

    In the Outgoing Route Selection:

    1. Click Source IP address settings.

    2. Select Manual.

    3. Click Selected address from topology table.

    4. Select the private cluster VIP address of the new CloudGuard IaaS High Availability.

7

In SmartConsole, configure the policy and NAT rules as needed

 

Important - Connectivity will be lost during the next steps.

8

Update route tables in the azure portal:

  • For each route in the App or Web Internal subnet where the Nexthop address matches the active member of your old Check Point cluster, change it to match the iLB-internal-address.
    Note - If the subnet houses the Security Management Server, managing the Cluster Members, then do not change the route which allows the Security Management Server to communicate directly with each Cluster Member. For more information see "Step 3: Set Up Internal Subnets and Route Tables.

  • In the frontend and backend subnets (in places that Nexthop address match the active member of your old Check Point cluster), change it to match the iLB-internal-address.

9

Install the applicable Policy on the cluster object.

 

Note - After an access role to the new members has been granted, the new CloudGuard IaaS High Availability now handles all traffic in the environment (inbound, outbound, E-W, VPN Tunneling).

Verify that all the traffic flows work as expected before proceeding

10

Delete the original Check Point CloudGuard IaaS Cluster and other redundant resources.

Note - If you are using resources from the old resource group, such as VNets, do not delete them.