This lab guide focuses on Palo Alto active-passive HA as an operational problem: how the pair synchronizes, what the network should do during a failover, and how to verify the result without relying on the GUI alone.

Implementing a Palo Alto active passive HA configuration solves this issue. It pairs two firewalls so that one actively processes traffic while the second remains in a standby state. The standby node continuously mirrors session state and configuration data. If the primary unit fails, the secondary firewall takes over instantly without dropping active connections.

Real-Life Scenario

Acme Financial operates a primary data center hosting mission-critical banking portals and transactional databases. The infrastructure relies on two firewall appliances to inspect north-south internet traffic and east-west internal segment traffic.

To comply with financial industry uptime SLAs, Acme Financial requires zero single points of failure across their security edge. They require:

  • Automated, hitless failover for active TCP sessions (such as database queries and web applications).
  • Automatic synchronization of security policies, NAT rules, and network configurations.
  • Automated failover triggering if critical upstream ISP links or downstream core switch connections disconnect.
  • Controlled manual failover capabilities for seamless software upgrades during maintenance windows.

Lab Topology

The following diagram illustrates the physical and logical layout of the active-passive high availability cluster. dedicated physical connections link the two firewalls directly for control (HA1) and data (HA2) synchronization.

                      +-----------------------+
                      |   Upstream ISP /      |
                      |   Edge Routers        |
                      +-----------+-----------+
                                  |
               +------------------+------------------+
               |                                     |
               | Port ethernet1/1                    | Port ethernet1/1
    +----------+----------+               +----------+----------+
    |   FW-A (Active)     |               |   FW-B (Passive)    |
    |   PA-3220           |               |   PA-3220           |
    |                     |   HA1 Control |                     |
    |          HA1-A Port +---------------+ Port HA1-A          |
    |                     | 192.168.1.1/30|                     |
    |                     | 192.168.1.2/30|                     |
    |          HA1-B Port + - - - - - - - + Port HA1-B          |
    |                     |  (Backup Link)|                     |
    |                     |               |                     |
    |          HA2-A Port +---------------+ Port HA2-A          |
    |                     | 192.168.2.1/30|                     |
    |                     | 192.168.2.2/30|                     |
    +----------+----------+               +----------+----------+
               | Port ethernet1/2                    | Port ethernet1/2
               |                                     |
               +------------------+------------------+
                                  |
                      +-----------+-----------+
                      |   Internal Core       |
                      |   Switch Fabric       |
                      +-----------------------+

Example Addressing and Objects

The following table details the IP addressing layout, interface assignments, and HA cluster parameters used throughout this lab guide. Note that public IPv4 addresses use RFC 5737 test ranges, and local IPs use standard private documentation subnets. Adapt these values to match your specific deployment plan.

Device / Role Interface / Parameter IP Address / Value Description
FW-A (Primary) Management Interface 192.0.2.10/24 Out-of-band management IP for FW-A.
FW-B (Secondary) Management Interface 192.0.2.11/24 Out-of-band management IP for FW-B.
HA Cluster HA Group ID 10 Must match on both firewalls (Range: 1-63).
HA Control Link HA1 (FW-A / FW-B) 192.168.1.1/30 & 192.168.1.2/30 Dedicated control plane sync link.
HA Control Backup HA1-Backup (FW-A / FW-B) 192.0.2.10 & 192.0.2.11 In-band management fallback for control traffic.
HA Data Link HA2 (FW-A / FW-B) 192.168.2.1/30 & 192.168.2.2/30 Dedicated data plane session sync link.
Untrust (WAN) ethernet1/1 (Floating IP) 198.51.100.10/24 Virtual/Floating IP assigned to Active firewall.
Trust (LAN) ethernet1/2 (Floating IP) 203.0.113.1/24 Default gateway floating IP for internal hosts.

Prerequisites

Before pairing two Palo Alto Networks firewalls in an active-passive HA cluster, confirm that both appliances meet strict compatibility requirements. Mismatches can prevent session state synchronization or block HA cluster formation altogether.

  • Identical Hardware Models: Both firewalls must be the exact same model (e.g., two PA-3220 appliances or two VM-300 instances).
  • Matching PAN-OS Versions: Both appliances must run the identical PAN-OS release, including the maintenance patch level (e.g., PAN-OS 10.2.4).
  • Matching Dynamic Updates: Ensure both firewalls run matching versions of Application and Threat ID signatures, Antivirus, and WildFire databases.
  • Identical Licensing: Both firewalls must carry identical feature licenses (such as Threat Prevention, GlobalProtect, or WildFire). Mismatched licenses trigger system warnings and prevent session offloading redundancy.
  • Interface Cabling: Verify dedicated physical connections are in place for the HA1 and HA2 interfaces. Use direct patch cables or dedicated VLANs across separate switches.

Step-by-Step GUI Configuration

Follow these steps to configure high availability on both firewalls using the PAN-OS web interface. Perform these steps on both devices, modifying device-specific parameters like IP addresses and priorities where indicated.

Step 1: Configure Physical Interfaces for HA Use

On appliances lacking dedicated HA ports (or when using standard data ports for HA2), set the interface type to HA.

  1. Log into the web interface of FW-A.
  2. Navigate to Network > Interfaces > Ethernet.
  3. Select the interface designated for HA2 (for example, ethernet1/3).
  4. Set the Interface Type drop-down menu to HA.
  5. Click OK. Repeat this step on FW-B.

Step 2: Enable High Availability and Set Election Rules

Configure general HA settings, election parameters, and device priorities. Lower priority numbers indicate a higher preference for the Active role.

  1. On FW-A, navigate to Device > High Availability > General Settings.
  2. Click the gear icon in the Setup section.
  3. Check the Enable High Availability box.
  4. Set Group ID to 10.
  5. Set Mode to Active-Passive.
  6. Click OK.
  7. Click the gear icon in the Election Settings section.
  8. Set Device Priority to 100 (FW-A will be preferred Active).
  9. Check Enable Preemption if you want the preferred primary firewall to automatically resume the Active state after recovering from a failure. Note: Leave this disabled if you want to prevent unexpected failbacks during unstable flapping conditions.
  10. Set Heartbeat Interval and Hello Interval to their default values unless custom timers are required.
  11. Click OK.

Now perform the same steps on FW-B, but set the election settings differently:

  • On FW-B, set Group ID to 10.
  • Set Device Priority to 200 (Higher number means lower preference).

Step 3: Configure Control (HA1) and Data (HA2) Links

Configure the transport settings for control plane communications (HA1) and state table replication (HA2).

  1. On FW-A, navigate to Device > High Availability > Control Link (HA1).
  2. Select the physical Port (e.g., ha1-a or dedicated port).
  3. Set the IP Address to 192.168.1.1 and Netmask to 255.255.255.252.
  4. Click OK.
  5. Click the gear icon for Control Link Backup (HA1-Backup).
  6. Select the management port or a dedicated backup interface, and enter its corresponding backup IP address.
  7. Navigate to Device > High Availability > Data Link (HA2).
  8. Select the designated HA2 interface (e.g., ethernet1/3 or ha2-a).
  9. Set the IP Address to 192.168.2.1 and Netmask to 255.255.255.252.
  10. Leave Transport set to Ethernet or IP (Protocol 99) based on your network architecture. Select IP if HA2 traffic passes through L3 infrastructure.
  11. Click OK.

Configure FW-B with matching settings, using IP address 192.168.1.2/30 for HA1 and 192.168.2.2/30 for HA2.

Step 4: Configure Link and Path Monitoring

Link and Path monitoring track physical interface states and remote IP reachability. If a monitored link fails, the active firewall triggers an automatic failover to the passive peer.

  1. Navigate to Device > High Availability > Link Monitoring.
  2. Click Add Group to monitor physical interfaces.
  3. Name the group (e.g., Uplink-Monitor), set Failure Condition to any, and add critical interfaces such as ethernet1/1 and ethernet1/2.
  4. Click OK.
  5. Navigate to Device > High Availability > Path Monitoring.
  6. Click Add Group to monitor destination upstream gateways or critical infrastructure IPs using ICMP pings.
  7. Save your configuration by clicking Commit on both firewalls.

CLI Section

You can also complete high availability status checks, configuration pushes, and forced operational failover tests directly through the PAN-OS Command Line Interface (CLI).

Review current HA operational status and peer cluster health:

admin@FW-A> show high-availability state
admin@FW-A> show high-availability all

Check the physical and logical condition of the HA control link (HA1) and data link (HA2):

admin@FW-A> show high-availability link-monitoring
admin@FW-A> show high-availability path-monitoring

Force a running firewall to initiate a configuration sync to its passive peer:

admin@FW-A> request high-availability sync-to-remote
CAUTION: Executing state modification commands causes immediate network path shifts. Running the suspend command forces the active unit into a functional standby state and transfers active routing to the secondary unit. Execute this command only during controlled maintenance or designated failover test windows.

To suspend an active unit and force traffic over to the passive peer during testing:

admin@FW-A> request high-availability state suspend

To restore a suspended unit back to normal functional operation:

admin@FW-A> request high-availability state functional

How the Traffic Flows

Understanding packet processing mechanics across an active-passive firewall pair is essential for effective troubleshooting and design validation.

Normal Operations (Active Unit Handling Traffic)

  • The Active firewall processes all active data-plane traffic. It responds to ARP requests for floating IP addresses and Virtual MACs (VMACs).
  • The Passive firewall keeps its data-plane interfaces in a non-forwarding state. It drops any standard transit traffic arriving on its data ports.
  • Configuration Synchronization: When an administrator commits a configuration change on the Active device, the changes automatically replicate to the Passive firewall over the HA1 control link.
  • Session Synchronization: As new TCP/UDP connections establish on the Active firewall, state entries write to the session table. The Active firewall replicates these session tables across the HA2 data link in real time. This includes NAT details, sequence numbers, and IPSec SA details.

Failover Event Sequence

  1. Failure Detection: The Active unit loses physical link state on a monitored interface, misses consecutive HA heartbeat hellos, or experiences a hardware fault.
  2. State Transition: The Passive firewall transitions its local HA state from Passive to Active.
  3. Gratuitous ARP (GARP): The newly Active firewall emits Gratuitous ARP packets out of all active layer-3 interfaces. This broadcasts its Virtual MAC or maps the floating IP addresses to its physical MAC address.
  4. Switch MAC Updates: Upstream routers and downstream core switches receive the GARP packets. They immediately update their local ARP and MAC address tables.
  5. Hitless Cutover: Traffic redirects to the newly Active firewall. Because session tables synchronized in real time via HA2, active user connections continue without dropping or re-authenticating.

Verification

Validate your Palo Alto active-passive HA configuration using the following operational checks.

1. Check HA Cluster Status in GUI

Log into the web UI of FW-A and check the High Availability dashboard widget on the main screen. You should confirm:

  • Local State: Active
  • Peer State: Passive
  • Sync Status: Synchronized (Green status indicator)
+-------------------------------------------------------+
| High Availability                                     |
+-------------------------------------------------------+
| Local State:  Active                                  |
| Peer State:   Passive                                 |
| Running Sync: Synchronized                            |
| Mode:         Active-Passive                          |
| Control Link: Up                                      |
| Data Link:    Up                                      |
+-------------------------------------------------------+

2. Perform a Manual Failover Test

To verify continuous, hitless failover under simulated failure conditions, run a continuous ping test from an internal workstation toward an external host (such as 8.8.8.8 or an upstream gateway IP):

C:\> ping -t 8.8.8.8

While the ping runs, open the CLI on FW-A and suspend the active firewall state:

admin@FW-A> request high-availability state suspend

Observe the continuous ping output. A properly optimized active-passive HA setup should experience no more than 1 to 2 dropped ping packets during the cutover process. Verify on FW-B that its HA status switches to Active:

admin@FW-B> show high-availability state

Group 10: 
  Mode: Active-Passive
  Local Information:
    State: Active
    Device Priority: 200
  Peer Information:
    State: Suspended
    Device Priority: 100

Re-enable FW-A back into service after completing the test:

admin@FW-A> request high-availability state functional

Troubleshooting

If your high availability pairing fails to form, or if state synchronization breaks, work through these targeted troubleshooting procedures.

Symptom 1: HA Peer State Shows “Non-Functional” or “Mismatch”

  • Cause: Incompatible OS builds, mismatched dynamic update signatures, or feature license variances between the firewalls.
  • Check: Compare installed system software versions on both nodes via CLI using show system info. Ensure App-ID, Antivirus, and WildFire versions match exactly under Device > Dynamic Updates.

Symptom 2: Split-Brain Condition (Both Firewalls Act as Active)

  • Cause: High Availability control link (HA1) failure. The secondary firewall stops receiving heartbeats from the primary firewall and assumes it has failed.
  • Check: Verify physical connectivity on the HA1 link interfaces. Ensure you have configured an HA1-Backup link. Run show high-availability all to inspect packet counters across the control interfaces.

Symptom 3: User Sessions Disconnect During Failover Events

  • Cause: Data link (HA2) interface down, or transport mode mismatched, preventing session state table synchronization.
  • Check: Verify HA2 link status using show high-availability state. Ensure port speeds, duplex settings, and MTU match on both ends. Verify that firewall security policies do not accidentally block IP protocol 99 or UDP port 29281 if HA2 traffic crosses an intermediate network switch.

Common Mistakes

  • Forgetting to Set Preemption Hold Time: Enabling preemption without setting a hold time (e.g., 1 to 5 minutes) causes flapping loops if the primary firewall reboots unexpectedly or experiences an intermittent physical interface bounce.
  • Omitting an HA1 Backup Link: Relying on a single HA1 cable creates a single point of failure for HA state tracking. If that cable breaks, both firewalls can switch to Active simultaneously, causing network-wide IP collisions.
  • Mismatched HA Group IDs: Using different Group IDs on FW-A and FW-B prevents them from joining the same high availability cluster.
  • Ignoring Intermediate Switch STP Settings: If HA data interface connections terminate into access switches without Spanning Tree PortFast configured, switch port listening delays can drop traffic for up to 30 seconds after a failover event.

Production Considerations

When preparing to deploy high availability in live enterprise environments, consider these recommended practices:

  • Use Jumbo Frames for HA2: Enabling jumbo frames (MTU 9000) on dedicated HA2 data links reduces CPU overhead during heavy session synchronization workloads across high-throughput data centers.
  • Maintain Separate Infrastructure Paths: Connect FW-A and FW-B to physically redundant core switches, power distribution units (PDUs), and separate upstream ISP routers to eliminate single physical points of failure.
  • Plan Maintenance Upgrades Carefully: Perform PAN-OS upgrades cleanly across HA pairs. First, suspend the passive unit, upgrade its software, reboot it, and verify its status. Next, suspend the active unit to shift live traffic onto the updated node. Finally, upgrade the remaining unit.
  • Implement Automated System Alerting: Configure syslog export, SNMP traps, or email notifications triggered by system log events related to high availability state transitions (e.g., ha_state_change events).

Summary

Building a Palo Alto active passive HA configuration delivers reliable enterprise-grade redundant security. Configuring identical hardware and software baselines, setting up dedicated HA control and data links, and configuring link monitoring ensures robust fault tolerance across your network security edge.

Perform complete failover validations and continuous health checks to ensure your cluster shifts traffic smoothly during unexpected link or hardware failures, protecting your critical network paths from downtime.

Continue the lab: Compare this design with the FortiGate active-passive HA guide and use the Palo Alto IPsec troubleshooting guide when HA testing exposes tunnel or routing issues.