Set Up Active/Active HA
Focus
Focus
Next-Generation Firewall

Set Up Active/Active HA

Table of Contents

Set Up Active/Active HA

Learn what's required to set up an active/active HA pair of NGFWs.
Where Can I Use This?What Do I Need?
  • NGFW (Managed by Strata Cloud Manager)
  • NGFW (Managed by PAN-OS or Panorama)
For Strata Cloud Manager managed NGFWs:
  • Strata Cloud Manager Pro
To set up active/active HA on your firewalls, you need a pair of firewalls that meet the following requirements:
  • The same model—The firewalls in the pair must be of the same hardware model.
  • The same PAN-OS version—The firewalls must be running the same PAN-OS version and must each be up-to-date on the application, URL, and threat databases.
  • The same multi virtual system capability—Both firewalls must have Multi Virtual System Capability either enabled or not enabled. When enabled, each firewall requires its own multiple virtual systems licenses.
  • The same type of interfaces—Dedicated HA links, or a combination of the management port and in-band ports that are set to interface type HA.
    • The HA interfaces must be configured with static IP addresses only, not IP addresses obtained from DHCP (except AWS can use DHCP addresses). Determine the IP address for the HA1 (control) connection between the HA peers. The HA1 IP address for the peers must be on the same subnet if they are directly connected or are connected to the same switch.
      For firewalls without dedicated HA ports, you can use the management port for the control connection. Using the management port provides a direct communication link between the management planes on both firewalls. However, because the management ports will not be directly cabled between the peers, make sure that you have a route that connects these two interfaces across your network.
    • If you use Layer 3 as the transport method for the HA2 (data) connection, determine the IP address for the HA2 link. Use Layer 3 only if the HA2 connection must communicate over a routed network. The IP subnet for the HA2 links must not overlap with that of the HA1 links or with any other subnet assigned to the data ports on the firewall.
    • Each firewall needs a dedicated interface for the HA3 link. The PA-7000 Series, PA-5400 Series, PA-3400 Series, PA-3200, and PA-1400 Series firewalls use the HSCI port for HA3. The PA-5200 Series firewalls can use the HSCI port for HA3 or you can configure aggregate interfaces on the dataplane ports for HA3 for redundancy. On the remaining platforms, you can configure aggregate interfaces on dataplane ports as the HA3 link for redundancy.
  • The same set of licenses—Licenses are unique to each firewall and cannot be shared between the firewalls. Therefore, you must license both firewalls identically. If both firewalls do not have an identical set of licenses, they cannot synchronize configuration information and maintain parity for a seamless failover.
    If you have an existing firewall and you want to add a new firewall for HA purposes and the new firewall has an existing configuration, it is recommended that you Reset the Firewall to Factory Default Settings on the new firewall. This will ensure that the new firewall has a clean configuration. After HA is configured, you will then sync the configuration on the primary firewall to the newly introduced firewall with the clean config. You will also have to configure local IP addresses.

ECMP in Active/Active HA

When an active/active HA peer fails, its sessions transfer to the new active-primary firewall, which tries to use the same egress interface that the failed firewall was using. If the firewall finds that interface among the ECMP paths, the transferred sessions will take the same egress interface and path. This behavior occurs regardless of the ECMP algorithm in use; using the same interface is desirable.
Only if no ECMP path matches the original egress interface will the active-primary firewall select a new ECMP path.
If you did not configure the same interfaces on the active/active peers, upon failover the active-primary firewall selects the next best path from the FIB table. Consequently, the existing sessions might not be distributed according to the ECMP algorithm.

NAT in Active/Active HA

In an active/active HA configuration:
  • You must bind each Dynamic IP (DIP) NAT rule and Dynamic IP and Port (DIPP) NAT rule to either Device ID 0 or Device ID 1.
  • You must bind each static NAT rule to either Device ID 0, Device ID 1, both Device IDs, or the firewall in active-primary state.
Thus, when one of the firewalls creates a new session, the Device ID 0 or Device ID 1 binding determines which NAT rules match the firewall. The device binding must include the session owner firewall to produce a match.
The session setup firewall performs the NAT policy match, but the NAT rules are evaluated based on the session owner. That is, the session is translated according to NAT rules that are bound to the session owner firewall. While performing NAT policy matching, a firewall skips all NAT rules that are not bound to the session owner firewall.
For example, suppose the firewall with Device ID 1 is the session owner and session setup firewall. When the firewall with Device ID 1 tries to match a session to a NAT rule, it skips all rules bound to Device ID 0. The firewall performs the NAT translation only if the session owner and the Device ID in the NAT rule match.
You will typically create device-specific NAT rules when the peer firewalls use different IP addresses for translation.
If one of the peer firewalls fails, the active firewall continues to process traffic for synchronized sessions from the failed firewall, including NAT traffic. In a source NAT configuration, when one firewall fails:
  • The floating IP address that is used as the Translated IP address of the NAT rule transfers to the surviving firewall. Hence, the existing sessions that fail over will still use this IP address.
  • All new sessions will use the device-specific NAT rules that the surviving firewall naturally owns. That is, the surviving firewall translates new sessions using only the NAT rules that match its Device ID; it ignores any NAT rules bound to the failed Device ID.

Route-Based Redundancy

In a Layer 3 interface deployment and active/active HA configuration, the firewalls are connected to routers, not switches. The firewalls use dynamic routing protocols to determine the best path (asymmetric route), ensure continuous service, minimize downtime, and to load share between the HA pair. In such a scenario, no floating IP addresses are necessary. If a link, monitored path, or firewall fails, or if Bidirectional Forwarding Detection (BFD) detects a link failure, the routing protocol (RIP, OSPF, or BGP) handles the rerouting of traffic to the functioning firewall. You configure each firewall interface with a unique IP address. The IP addresses remain local to the firewall where they are configured; they do not move between devices when a firewall fails. See Use Case: Configure Active/Active HA with Route-Based Redundancy.

Determine Your Active/Active Use Case

Determine which type of use case you have and then select the corresponding procedure to configure active/active HA.
If you are using route-based redundancy, Floating IP Address and Virtual MAC Address, or ARP Load-Sharing, select the corresponding procedure:
If you want a Layer 3 active/active HA deployment that behaves like an active/passive deployment, select the following procedure:
If you are configuring NAT in Active/Active HA, see the following procedures: