> Source: [sk175023](https://support.checkpoint.com/results/sk/sk175023)

# sk175023 - ATRG: Cloud Firewall for Azure - High Availability (HA)

| Property | Value |
|----------|-------|
| Solution ID | sk175023 |
| Date Created | 2021-09-01 |
| Last Modified | 2026-05-11 |
| Technical Level | General |
| Products | Cloud Firewall |
| Versions | R82.10, R81.10 (EOS), R81.20, R82 |
| OS | Gaia |
| Platform | Azure |

## Solution

**Table of Contents**

* Introduction
* Important Information
* FAQ
* Errors and Troubleshooting
  * General
  * Tester
  * Failover
  * Traffic
* Contact Check Point Support

**Note:** To stay up-to-date, refer to Cloud Firewall for Azure [latest updates](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk132192)  
Click Here to Show the Entire Section

Introduction {#Introduction}
============================

The Cloud Firewall (formerly CloudGuard Network) cloud security solution provides advanced threat protection to private or public cloud infrastructures. It controls and manages security in both physical and virtual environments with a single unified management solution.

A cluster is a group of Virtual Machines that work together in a high-availability mode. One Cluster Member is the Active, and the second Cluster Member is the Standby. The cluster fails over from the Active Cluster Member to the Standby Cluster Member when necessary.

* Cluster Members communicate with each other using unicast IP addresses.
* For inbound, outbound, and East-West traffic, Cluster Members rely on Azure Load Balancers to represent their external and internal Virtual IP addresses. Load Balancers only forward traffic to the Active Cluster Member.
* For VPN traffic, Cluster Members use API calls to Azure to communicate the failover from the Active Cluster Member. The Standby Cluster Member then promotes itself to an Active member. During cluster failover, the Standby Cluster Member associates the Active Cluster Member's private and public cluster IP addresses with its external interface.

**To get additional information about the solution, refer to:**

* [Cloud Firewall for Azure HA Admin Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Cluster/Default.htm)
* [Cloud Firewall for Public Cloud - Frequently Asked Questions](https://support.checkpoint.com/results/sk/sk174006)
* [Cloud Firewall for Public Cloud - Important Resources](https://support.checkpoint.com/results/sk/sk173705)

Important Information {#Important}
==================================

<br />

|----------------------------------------------------------------|---------------------------------------------------------------------------------------------|--------------|------------------------|
| **SK**                                                         | **Description**                                                                             | **Versions** | **Fix**                |
| [sk173631](https://support.checkpoint.com/results/sk/sk173631) | "*hv_utils: Shutdown request received - graceful shutdown initiated*" error in message file | All versions | Open a ticket to Azure |

Frequently Asked Questions {#FAQ}
=================================

<br />

Click Here to Show the Entire Section

* How do I know that my cluster is well-configured?  
  1. Make sure that the tester (`$FWDIR/scripts/azure_ha_test.py`) passes and there are no errors in `$FWDIR/log/azure_had.log` on each member.
  2. Make sure that the daemon in charge of communicating with Azure runs on each cluster member by running: `cpwd_admin getpid -name AZURE_HAD` and ensuring the output is non-zero.

  <br />

* What is the expected failover time?  

  |---------------------------------------------------------|----------------------------|----------------------------------------------------------|
  | **Use case**                                            | **Expected failover time** | **Comments**                                             |
  | Site-to-site VPN                                        | Less than 2 minutes.       | Depends on the Azure API.                                |
  | Inbound inspection through the External Load Balancer   | Less than 15 seconds.      | Depends on the Load Balancer health probe.               |
  | Outbound inspection                                     | Less than 2 minutes.       | Depends on the Load Balancer health probe and Azure API. |
  | East-West inspection through the Internal Load Balancer | Less than 15 seconds.      | Depends on the Load Balancer health probe.               |

* Is the solution stateful?  
  > There are two possible scenarios for the solution:
  > 1. **Using Azure load balancers**   
  >    While the HA solution supports stateful failover, the failover will not be stateful when the connection passes through an Azure load balancer. When a connection initiates through a load balancer, the load balancer always forwards the connection to the same instance regardless of the health probe or the instance status. Hence, the load balancer sends the existing connection to the same instance even when a failover occurs. Once the connection times out and is reinitiated, it will connect via the new Active member.
  > 2. **Using the HA Virtual IP (VIP)**   
  >    The failover is stateful.
* Can I terminate my VPN connection by the load balancer?  
  No, Azure load balancers do not support IPSec.
* What do the API calls for HA exactly do?  
  During failover, the only API calls are from the Cluster Member that gets promoted to Active to attach the cluster private and public IP addresses to itself.
* Can I use a public IP address other than the one deployed by the solution?  
  Yes.

  On each Cluster Member, edit the configuration file located at `$FWDIR/conf/azure-ha.json`. In `"clusterNetworkInterfaces" -> "eth0"`, replace the public IP address name with the original cluster VIP address resource ID. Then run **$FWDIR/scripts/azure_ha_cli.py reconf**

  **Note** : Refer to the [Cloud Firewall HA Administration Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Cluster/Default.htm) \> "Upgrading a Cloud Firewall High Availability Solution" for more information.

Errors and Troubleshooting {#Troubleshooting}
=============================================

* General
* Tester
* Failover
* Traffic

Click Here to Show the Entire Section

General Errors {#General problems}
----------------------------------

* Policy installation fails on the cluster members with "*Installation failed. Reason: TCP connectivity failure ( port = 18191 )( IP = 40.88.211.66 )\[ error no. 10 \].*" error.  
  > **Cause** : There are some possible reasons:
  > 1. The cluster member's VM's are turned off.
  > 2. There is no NSG on the cluster VNET allowing the connectivity over SIC port between the Security Management Server and the cluster members.
  > 3. The cluster members were deployed in an existing VNET, and the frontend Network Security Group (NSG) is missing.
  >
  > <br />
  >
  > **How to resolve** :   
  > 1. Ensure that the VMs are turned on.
  > 2. Ensure that there are [Network Security Groups](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview) on the cluster's VNET allowing connectivity over SIC port.
  > 3. Add a Network Security Group (NSG) as documented in the [HA Admin Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Cluster/Content/Topics-Azure-HA/Workflow.htm?tocpath=Workflow%20for%20Setting%20Up%20a%20High%20Availability%20Cluster%20in%20Azure%7C_____0#Workflow_for_Setting_Up_a_High_Availability_Cluster_in_Azure).
* The cluster members do not use their configuration `$FWDIR/conf/azure-ha.json`   
  > **Cause** : The configuration file hasn't been loaded into the solution.  
  >
  > **How to resolve** :   
  > Load the configuration file by running **$FWDIR/scripts/azure_ha_cli.py reconf**.
* Install policy on the cluster members displays "*Anti-Spoofing is not configured for some interfaces and gateways.*" warning  
  > **Cause** : The warning appears because the Anti Spoofing is disabled from the topology.  
  >
  > **How to resolve**: No action should be taken. This is a correct configuration.
* Deploying the solution into an existing VNET fails because of an IP address conflict.  
  > **Cause** : It fails because of Azure ARM limitations.  
  >
  > **How to resolve** :   
  > Follow [sk170472](https://support.checkpoint.com/results/sk/sk170472).

Troubleshooting Tester Errors {#Tester}
---------------------------------------

* The tester fails with the "*You do not seem to have a valid cluster configuration*" error.  
  > **Cause** : there are two possible reasons:
  > 1. The cluster was not configured in SmartConsole.
  > 2. The Cluster IP addresses are not assigned as expected because of a manual configuration.
  >
  > <br />
  >
  > **How to resolve** :   
  > 1. Configure the cluster as explained in [Cloud Firewall HA Admin Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Cluster/Default.htm) in the "Configure Cluster Objects in SmartConsole" section.
  > 2. Assign the IP address manually using [Cloud Firewall HA Admin Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Cluster/Default.htm) topology as explained in [Azure official documentation](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/associate-public-ip-address-vm?tabs=azure-portal).
* The tester fails with the "*Attempting to write - \[Forbidden\] Error: HTTP/1.1 403 Forbidden*" error.  
  > **Cause**: The cluster members do not have Contributor permissions for their VNET, or/and their NICs, or/and the Cluster IP address, or/and the Network Security Group.
  >
  > **How to resolve** :   
  > 1. Navigate to the cluster's VNET resource group or/and the cluster's resource group (in the case of Network Security Group from a different resource Group - navigate to the NSG resource).
  > 2. Assign the following [Azure permissions](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/) for each cluster's managed identity created by the deployment:
  >    1.
  >       1.
  >          1. Contributor to the cluster managed identity named **`<CLUSTER_NAME`1`>`**.
  >          2. Contributor to the cluster managed identity named **`<CLUSTER_NAME`2`>`**.
  > 3. Wait for a few minutes for the changes to take place (up to one hour).
  > **Note**: If you use the old cluster solution, you need to perform the steps above for all the VNET's peered to the cluster VNET.
  > To check if you use the old cluster solution, run **cat /etc/cloud-version | grep template_name** and the output should be **cluster**.
* The tester fails on the Standby member with an empty error.  
  > **Cause**: Outbound traffic initiated by the Standby member passes through the Active member.
  > **How to resolve** :   
  > Install the latest Jumbo Hotfix Accomulator on the cluster members.  
  > **Note**: There is no impact on the cluster performance as only the Active member performs API calls.
* The tester fails with the "*Unable to connect to login.windows.net:443*" error.  
  > **Cause** : There is no outbound connectivity to Azure.  
  >
  > **How to resolve** :   
  > 1. Make sure the DNS settings are correct:   
  >    The command **nslookup management.azure.com** should return the output:   
  >    **Server: X.X.X.X
  >    Address: X.X.X.X#53**.   
  >    If the command does not return a similar output, configure your DNS accordingly.   
  >    It is recommended to have the Primary or Secondary DNS set to the Azure default, as mentioned in [sk122274](https://support.checkpoint.com/results/sk/sk122274).  
  >
  > 2. Resolve Azure connectivity:   
  >    The command **curl_cli --verbose https://management.azure.com?api-version=1.3 --cacert $CPDIR/conf/ca-bundle-public-cloud.crt** should return the following output: **Connected to management.azure.com (X.X.X.X) port 443**.   
  >    If the command doesn't return a similar output, set Azure connectivity.
* The tester fails for newly created R80.30 HA members with the "*HTTP/1.1 400 Bad Request*" error   
  > **Cause** : There is the expected behavior up to one hour.  
  >
  > **How to resolve** : Follow [sk164316](https://support.checkpoint.com/results/sk/sk164316).
* The tester fails with an API version error.  
  > **Cause** : A missing parameter in the `azure-ha.json` file is causing the cluster to behave in a legacy mode requiring to update UDRs to successfully complete a failover.  
  >
  > **How to resolve** : Follow [sk176463](https://support.checkpoint.com/results/sk/sk176463).

Troubleshooting Failover Issues {#Failover}
-------------------------------------------

* Azure HA log file shows the "*rest.TimeoutException: b'curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received* " error.  
  > **Cause** : Azure API server did not respond to the active member's API requests in 20 seconds.  
  >
  > **How to resolve** :   
  > 1. There is no impact on functionality if the log is not shown repetitively.
  > 2. If the log appears repetitively, make sure there are no connectivity issue to Azure. Run **curl_cli --verbose https://management.azure.com?api-version=1.3 --cacert $CPDIR/conf/ca-bundle-public-cloud.crt** and part of the output should be **Connected to management.azure.com (X.X.X.X) port 443**. If the output is **Failed to connect to management.azure.com port 443: Connection timed out**, fix Azure's connectivity.
* Azure HA log file shows the "*HTTP status code 429 Too many requests* " error.  
  > **Cause** : [Azure throttling](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling)  
  >
  > **How to resolve** : Follow [sk131932](https://support.checkpoint.com/results/sk/sk131932).
* Azure HA log file shows the "*Couldn't resolve host 'management.azure.com'*" error.  
  > **Cause**: There is no outbound connectivity to Azure.
  >
  > **How to resolve** :   
  > 1. Ensure DNS settings are correct:   
  >    The command **nslookup management.azure.com** should return the output:   
  >    **Server: X.X.X.X
  >    Address: X.X.X.X#53**.   
  >    If the command does not return a similar output, configure your DNS accordingly.   
  >    It is recommended to have the Primary or Secondary DNS set to the Azure default, as mentioned in [sk122274](https://support.checkpoint.com/results/sk/sk122274).   
  >
  > 2. Resolve Azure connectivity:   
  >    The command **curl_cli --verbose https://management.azure.com?api-version=1.3 --cacert $CPDIR/conf/ca-bundle-public-cloud.crt** should return the following output: **Connected to management.azure.com (X.X.X.X) port 443**.   
  >    If the command does not return a similar output, set Azure connectivity.
  >
  > <br />
  >
  > **Note** : There is no impact on the cluster performance as only the Active member performs API calls.  
  >
* VIP addresses are not attached to the new active member, and the Azure HA log file shows this error: *{"error":{"code":"InvalidRequestFormat","message":"Cannot parse the request.","details":\[
  {"code":"DuplicateResourceName","message":"Resource /subscriptions//resourceGroups//providers/Microsoft.Network/networkInterfaces/ has two child resources with the same name (Capital-VIP)."}*   
  > **Cause** : The VIP address name under the NIC IP address configuration in Azure portal contains capital letters.  
  >
  > **How to resolve** :  
  >
  > ? Rename VIP address to contain only lower case letters.
  >
  > ? Modify the `azure_had.py` on the machine:
  > 1. Locate the HA script under `$FWDIR/scripts/azure_had.py`.
  > 2. Find the `get_cluster_ip_index` function.
  > 3. Change the following line:
  >
  >        if ipc[NAME].lower() == name:
  >
  >    to:
  >
  >        if ipc[NAME].lower() == name.lower():
  >
  > 4. Run `$FWDIR/scripts/azure_ha_cli.py restart` to load the changes.

Troubleshooting Traffic Issues {#Traffic}
-----------------------------------------

* Hide NAT and static NAT (to the public IP address) are applied to the Standby Security Gateway.  
  >
  > **Hide NAT behind VNET** :   
  > * **Cause** :  
  >   It fails because when selecting Hide NAT on the VNET, the Standby member requests are hidden behind the cluster IP address (VIP address) on eth0. The Active member owns this, so Azure will drop the packet since it is not the proper device sending this request.
  > * **How to resolve**   
  >   Disable NAT to resolve this. Add a No-NAT rule originating from each Security Gateway for HTTP, HTTPS, and DNS.
  >
  > **Static NAT to public IP** :   
  > * **Cause** :  
  >   It fails because Azure owns the Public IP address, and it is not expecting the public IP address to come from the firewalls.
  > * **How to resolve**   
  >   Disabling this NAT rule resolve the problem.
* The Security Gateways do not respond to Azure health probe requests.  
  > **Cause** : There are several possible reasons:
  > 1. The load balancer health probe requests are not received by the cluster members.
  > 2. The active member does not handle the health probes as expected.
  >
  > <br />
  >
  > **How to resolve** :   
  > 1. Ensure that health probes using port 8117 are configured in the solution's load balancers. See the [Azure health probe official documentation](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview) for more information.
  > 2. Follow [sk171584](https://support.checkpoint.com/results/sk/sk171584).
* The Standby cluster member cannot access the Internet.  
  > **Cause** : The Standby cluster member is hidden behind the VIP address when it should leave through the member IP address.  
  > **How to resolve** : Follow [sk175108](https://support.checkpoint.com/results/sk/sk175108).  
  > **Note**: There is no impact on the cluster performance as only the Active member performs API calls.

Contacting Check Point Support {#Support}
=========================================

If you still encounter issues, contact your local Check Point Support and attach the following files to the case to speed up the process:

* `/etc/cloud-version`
* `$FWDIR/conf/azure-ha.json`
* `$FWDIR/log/azure_had.elg*`
* `/var/log/cloud_config.log`
* `$FWDIR/boot/modules/fwkern.conf`
* `curl_cli --verbose https://management.azure.com --cacert $CPDIR/conf/ca-bundle-public-cloud.crt > /home/admin/azure-connectivity.txt`
* `$FWDIR/scripts/azure_ha_test.py > /home/admin/ha-tester-output.txt`
* `cphaprob state > /home/admin/cphaprob-stat.txt`

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content