Set up the Firewalls for Enabling HA

Set up the Active Directory application and a Service Principal to enable programmatic API access.

For the firewall to interact with the Azure APIs, you need to create an Azure Active Directory Service Principal. This Service Principle has the permissions required to authenticate to the Azure AD and access the resources within your subscription.To complete this set up, you must have permissions to register an application with your Azure AD tenant, and assign the application to a role in your subscription. If you don't have the necessary permissions, ask your Azure AD or subscription administrator to create a Service Principal with an IAM role of contributor. Copy the following details for use later in this workflow:
Client ID
—The Application ID associated with the Active Directory (
Azure Active Directory
App registrations
, select your application and copy the ID).
Tenant ID
—The Directory ID (
Azure Active Directory
Properties
Directory ID
on the Azure portal).
Azure Subscription ID
—The Azure subscription in which you have deployed the firewalls. You must login to your Azure portal to get this subscription ID.
Resource Group Name
— The resource group name in which you have deployed the firewalls that you want to configure as HA peers. Both firewalls must be in the same resource group.
Secret Key
—The authentication key associated with the Active Directory application. To log in as the application, you must provide both the key value and the Application ID.

Know where to get the templates you need to deploy the VM-Series firewalls within the same Azure Resource Group.

For an HA configuration, both HA peers must belong to the same Azure Resource Group. If you deploy the first instance of the firewall from the Azure Marketplace, and must use your custom ARM template or the Palo Alto Networks sample GitHub template for deploying the second instance of the firewall into the existing Resource Group. The reason you need a custom template or the Palo Alto Networks sample template is because Azure does not support the ability to deploy the firewall in to an Resource Group that is not empty.

Copy the deployment information for the first firewall instance. For example:



Match the

VM Name of VM-Series

firewall as shown in the screenshot above with the

Hostname

on the firewall web interface. You must add the same name on

Device

Setup

Management

, because the hostname of the firewall is used to trigger failover.

Plan the network interface configuration on the VM-Series firewalls on Azure.

To set up HA, you must deploy both HA peers within the same Azure Resource Group and both firewalls must have the same number of network interfaces. A minimum of four network interfaces is required on each HA peer:

Management interface (eth0)
—Private and public IP address associated with the primary interface. The public IP address enables access to the firewall web interface and SSH access.
You can use the private IP interface on the management interface as the HA1 peer IP address for the control link communication between the active/passive HA peers. If you want a dedicated HA1 interface, you must attach an additional network interface on each firewall, and this means that you need five interfaces on each firewall.
Untrust interface (eth1/1)
—Primary private IP address with /32 netmask, and secondary IP configuration with both a private IP address (any netmask) and a public IP address.
On failover, when the passive peer transitions to the active state, the public IP address associated with the secondary IP configuration is detached from the previously active peer and attached to the now active HA peer.
Trust interface (eth1/2)
—Primary and secondary private IP addresses. On failover, when the passive peer transitions to the active state, the secondary private IP address is detached from the previously active peer and is attached to the now active HA peer.
HA2 (eth 1/3)
—Primary private IP address. The HA2 interface is the data link that the HA peers use for synchronizing sessions, forwarding tables, IPSec security associations and ARP tables.

Interface	Active firewall peer	Passive firewall peer	Description
Trust	Secondary IP address	—	The trust interface of the active peer requires a secondary IP configuration that can float to the other peer on failover. This secondary IP configuration on the trust interface must be a private IP address with the netmask of the servers that it secures. On failover, the VM-Series plugin calls the Azure API to detach this secondary private IP address from the active peer and attach it to the passive peer. Attaching this IP address to the now active peer ensures that the firewall can receive traffic on the floating IP on the untrust interface and send it through to the floating IP on the trust interface and on to the workloads.
Untrust	Secondary IP address	—	The untrust interface of the firewall requires a secondary IP configuration that includes a static private IP address with a netmask for the untrust subnet, and a public IP address for accessing the back-end servers or workloads over the internet. On failover, the VM-Series plugin calls the Azure API to detach the secondary IP configuration from the active peer and attach it to the passive peer before it transitions to the active state. This process of floating the secondary IP configuration, enables the now active firewall to continue processing inbound traffic that is destined to the workloads.
HA2	Add a NIC to the firewall from the Azure management console.	Add a NIC to the firewall from the Azure management console.	On the active and passive peers, add a dedicated HA2 link to enable session synchronization. The default interface for HA1 is the management interface, and you can opt to use the management interface instead of adding an additional interface to the firewall. For enabling data flow over the HA2 link, you need to add an additional network interface on the Azure portal and configure the interface for HA2 on the firewall.