Configuring High Availability on Palo Alto Firewalls: Step-by-Step

High availability in the context of network security refers to the design principle of ensuring that a firewall or security system remains operational and continues protecting network traffic even when hardware failures, software issues, or maintenance activities would otherwise cause an outage. For organizations that depend on continuous network connectivity — which today includes virtually every business that operates online — a single firewall that fails takes down the entire network perimeter, exposing the organization to both downtime and potential security vulnerabilities during the recovery period.

Palo Alto Networks firewalls support high availability through a mechanism that pairs two physical or virtual firewall units together so that if one fails, the other seamlessly takes over without interrupting active network sessions. This failover capability is the core value proposition of HA configuration, and when implemented correctly, end users and connected systems experience little to no disruption during a failover event. Understanding what high availability is, why it matters, and what it requires before you begin configuring it is the essential foundation for everything that follows in this guide.

HA Modes Palo Alto Supports

Palo Alto firewalls support two distinct high availability modes, each designed for different network architectures and failover requirements. The first mode is Active/Passive, where one firewall actively processes all traffic while the second unit stands by in a synchronized but idle state, ready to take over immediately if the active unit fails. In this configuration, the passive unit mirrors the session table, routing information, and configuration of the active unit continuously, which enables it to assume the active role without losing established network sessions.

The second mode is Active/Active, where both firewall units process traffic simultaneously, sharing the load between them. This mode is more complex to configure and requires careful consideration of session ownership and flow symmetry, but it provides better utilization of hardware resources and can offer faster failover under certain conditions. Active/Active is typically used in environments with asymmetric routing, where traffic from a single session may enter through one firewall and exit through another. For most organizations, Active/Passive is the recommended starting point because it is simpler to configure, easier to troubleshoot, and sufficient for the majority of high availability use cases.

Hardware and Software Prerequisites

Before you begin configuring high availability on Palo Alto firewalls, several prerequisites must be met to ensure the configuration will work correctly. First, both firewall units must be the same hardware model. You cannot pair a PA-3220 with a PA-3260 or a PA-5220 with a PA-5250 — the hardware must match exactly. This requirement exists because HA relies on synchronized state information and configuration, and differences in hardware capabilities between units can cause unpredictable behavior during failover.

Both units must also run the same PAN-OS version and have matching content database versions, including application and threat definitions, URL filtering databases, and GlobalProtect clients if applicable. Mismatched software versions are one of the most common causes of HA configuration failures and unexpected behavior. Additionally, both firewalls must have the same set of licenses applied, including the Threat Prevention, URL Filtering, and WildFire subscriptions if your configuration depends on those features. Verifying all of these requirements before touching the HA configuration menus will save you significant troubleshooting time later.

Physical Interface Connections Required

High availability on Palo Alto firewalls requires dedicated physical interface connections between the two units for HA communication. There are two types of HA links that need to be configured: the HA1 link and the HA2 link. The HA1 link is the control link, responsible for transmitting hello messages between the two units to verify that each peer is alive, exchanging configuration synchronization data, and communicating HA state information including which unit is currently active and which is passive. This link carries relatively low bandwidth traffic but must be highly reliable because its failure can trigger unnecessary failover events.

The HA2 link is the data link, responsible for synchronizing session state information between the two units. This includes the session table, forwarding tables, IPsec security associations, and ARP tables. The HA2 link carries significantly more traffic than the HA1 link, particularly in environments with high numbers of concurrent sessions. Palo Alto recommends using dedicated management interfaces or dedicated data plane interfaces for HA links depending on your firewall model. Some organizations also configure HA1 backup and HA2 backup links using different physical paths to add redundancy to the HA communication itself, preventing a single cable or switch failure from disrupting HA operation.

Accessing the HA Configuration Menu

With physical connections in place and prerequisites verified, the next step is accessing the high availability configuration interface on each firewall. Log into the Palo Alto web interface, known as the Web UI, on the first firewall using a browser and navigating to the management IP address. Once authenticated, navigate to Device in the top menu bar, then select High Availability from the left-hand navigation panel. This brings you to the main HA configuration page, which is organized into several sections including General, Election Settings, Active/Passive Settings or Active/Active Settings depending on your intended mode, and Link and Path Monitoring.

The General section is where you will spend most of your initial configuration time, as it contains the fundamental settings that define the HA relationship between the two units. You will also want to familiarize yourself with the HA status indicators that appear on this page once HA is active, including the local state, peer state, and synchronization status. These indicators become your primary diagnostic tools when verifying that HA is operating correctly after configuration. Taking a moment to understand the layout of this page before making any changes will help you work through the configuration steps more efficiently.

Enabling and Configuring HA General Settings

In the General section of the HA configuration page, the first thing to do is check the Enable HA checkbox to activate high availability on the firewall. Once enabled, the remaining configuration fields become active. The Group ID field is important — it is a numerical identifier between 1 and 63 that distinguishes this HA pair from other HA pairs on the same network segment. Both firewalls in the pair must be configured with the same Group ID, and if you have multiple HA pairs on the same Layer 2 network segment, each pair must have a unique Group ID to prevent them from interfering with each other.

The Description field is optional but worth completing with a meaningful label that identifies the HA pair, which is helpful when managing multiple firewalls. The Mode dropdown allows you to select Active/Passive or Active/Active. For this guide, select Active/Passive. The Peer HA1 IP Address field is where you enter the IP address configured on the HA1 interface of the peer firewall — this is how the local unit knows where to send HA1 control traffic. The Backup Peer HA1 IP Address is where you enter the IP address of the HA1 backup interface on the peer, if you have configured backup HA links. After completing these fields, do not commit yet — continue configuring the remaining sections first.

Configuring HA1 and HA2 Interfaces

With the General settings completed, navigate to the HA1 section to configure the control link interface. In the Port dropdown, select the physical interface on the firewall that you have connected to the HA1 interface on the peer firewall. Enter the IP address and netmask that you want to assign to this interface. The HA1 interface IP addresses on the two firewalls must be in the same subnet but must be different addresses — for example, 192.168.100.1/30 on the first firewall and 192.168.100.2/30 on the second. The Gateway field should be left blank in most configurations where the HA1 link is a direct connection between the two firewalls.

For the HA2 section, follow the same process of selecting the physical interface assigned to the HA2 link and assigning an IP address in a different subnet from the HA1 link. The HA2 Transport dropdown allows you to choose between IP, UDP, and Ethernet as the transport mechanism for session synchronization traffic. IP is the default and works in most environments. If the HA2 link is a direct back-to-back connection between the two firewalls at Layer 2, you can select Ethernet, which eliminates IP overhead and can improve synchronization performance. Enable the HA2 Keep-alive option to allow the firewall to detect HA2 link failures and respond appropriately. Save these settings and prepare to move on to the election settings that determine how the firewalls decide which unit should be active.

Election Settings and Device Priority

The Election Settings section controls how the two firewalls determine which unit will be the active firewall during normal operation and which will be passive. The Device Priority field accepts a value between 0 and 255, and the firewall with the lower numerical value wins the election to become the active unit during initial HA formation or after both units restart simultaneously. Setting the priority to 100 on the firewall you want to be primary and 200 on the secondary firewall is a common convention, though any values that clearly distinguish the two units will work.

The Preemptive checkbox is an important setting that controls what happens when a previously failed primary firewall recovers and rejoins the HA pair. If Preemptive is enabled and the recovered firewall has a lower device priority, it will automatically reclaim the active role from the currently active secondary firewall. If Preemptive is disabled, the secondary firewall that took over during the failure will remain active even after the primary recovers, and a manual failover would be required to return the primary to the active role. Many organizations prefer to disable Preemptive to avoid unnecessary failover events during recovery periods, prioritizing stability over automatic role restoration.

Configuring Passive Link State

In Active/Passive mode, the passive firewall’s data plane interfaces are in a shutdown state by default to prevent the passive unit from forwarding traffic. This default behavior is controlled by the Passive Link State setting in the Active/Passive Settings section. The two options are Auto and Shutdown. When set to Shutdown, the passive firewall’s interfaces are physically shut down and the connected switches or routers see the links as down, which can cause spanning tree reconvergence or routing protocol changes during failover. When set to Auto, the interfaces remain up at Layer 1 but the passive firewall does not forward traffic, which results in faster failover because there is no need to wait for spanning tree or routing protocol convergence after a failover event.

For most modern network environments, setting Passive Link State to Auto is the preferred configuration because it reduces failover time significantly. However, there are specific environments where Shutdown is necessary, particularly when using Layer 2 deployments where having both firewalls connected with active links could cause bridging loops. Evaluate your specific network topology before making this decision, and if in doubt, consult the Palo Alto documentation for your specific deployment scenario. This setting exists on the primary firewall’s configuration and controls the behavior of the passive peer, so configure it thoughtfully.

Link Monitoring Configuration Steps

Link monitoring is a feature that allows the firewall to monitor the state of specific network interfaces and trigger a failover if those interfaces lose connectivity. This is valuable because a firewall’s HA links might remain up while one of its data plane interfaces connected to the upstream router or downstream switch fails — without link monitoring, the firewall would remain active even though it can no longer forward traffic properly, causing an outage. Link monitoring detects this condition and triggers a failover to the peer unit, which presumably still has its interfaces connected and operational.

To configure link monitoring, navigate to the Link and Path Monitoring section of the HA configuration page and expand the Link Monitoring area. Click Add to create a new link group, give it a descriptive name, and then add the interfaces you want to monitor to the group. The Link Group Failure Condition dropdown allows you to choose whether all interfaces in the group must fail before triggering a failover, or whether the failure of any single interface is sufficient. For most configurations, monitoring the uplink interface to your upstream router and setting the failure condition to Any provides a good balance of protection without excessive sensitivity to single link anomalies.

Path Monitoring Configuration Steps

Path monitoring goes a step further than link monitoring by testing actual network reachability to specific IP addresses through the firewall’s interfaces. Rather than simply checking whether an interface is physically up, path monitoring sends ping packets to designated target IP addresses and triggers a failover if those targets become unreachable. This provides a more comprehensive health check because it can detect situations where an interface is physically up but the network path through it is broken — for example, when an upstream router has failed but the physical link between the firewall and the router remains connected.

To configure path monitoring, expand the Path Monitoring section and click Add to create a path group. Enter the name of the group and specify the virtual router or zone through which the monitored path runs. Then add the IP addresses you want to monitor — common choices include the IP address of the upstream router, a core switch, or a reliable external resource like a DNS server or the default gateway of the upstream ISP. Configure the ping interval, the number of consecutive failures required before declaring the path failed, and the failure condition for the group. Path monitoring adds meaningful intelligence to your HA failover logic and is strongly recommended for environments where network path failures are a realistic concern.

Synchronizing Configuration Between Units

Once you have completed the HA configuration on the first firewall, you need to commit those changes and then configure the second firewall with matching settings. On the second firewall, navigate to the same Device, High Availability path and enter the same Group ID, the same HA mode, the same interface assignments, and the appropriate IP addresses for its own HA interfaces. The Peer HA1 IP Address on the second firewall should point to the HA1 interface IP address of the first firewall, which is the reverse of what you entered on the first unit.

After committing the configuration on both firewalls, they will begin exchanging HA hello messages over the HA1 link and attempting to establish the HA relationship. Navigate to the Dashboard in the Web UI and look for the High Availability widget, which displays the local state, peer state, and synchronization status. Initially you may see the state as Initial or Non-Functional as the two units negotiate their roles. Within a few minutes, assuming all physical connections are correct and the configurations match, one unit should transition to Active and the other to Passive, and the Sync Status should show Configuration Synchronized. If synchronization does not complete, review the HA configuration on both units for any discrepancies.

Testing Failover After Configuration

Testing failover after completing the HA configuration is not optional — it is an essential validation step that confirms your configuration works correctly before you depend on it during a real outage. The safest way to initiate a test failover is through the Web UI using the Suspend Local Device option, which gracefully moves the active role to the passive peer without simulating a crash. Navigate to Device, then High Availability, then click on the Suspend Local Device link in the operational commands area. The local firewall will transition to a Suspended state and the peer will become active.

During the failover, observe whether active network sessions are maintained or interrupted. In a correctly configured Active/Passive HA pair with session synchronization working properly, established TCP sessions should survive the failover without disconnecting, and end users should experience at most a brief pause in traffic rather than a full connection reset. After verifying that the failover occurred correctly and that the new active unit is passing traffic normally, use the Make Local Device Functional option to restore the suspended unit to the passive state, and then perform a second test by suspending the peer to verify that failover works in both directions. Document the results of your testing for your organization’s change management records.

Common HA Troubleshooting Approaches

When HA is not behaving as expected, several systematic troubleshooting approaches can help you identify the root cause. The first place to check is always the HA status widget on the dashboard of both firewalls. The local state, peer state, and synchronization status displayed there immediately tell you whether the HA relationship has been established and whether the two units see each other correctly. A state of Non-Functional typically indicates a configuration mismatch or a connectivity problem on the HA1 link. A state of Tentative often indicates that the firewalls have detected each other but have not yet completed the election process.

If the HA status shows a problem, check the system logs on both firewalls by navigating to Monitor, then Logs, then System, and filtering for HA-related events. These logs provide detailed messages about what the HA subsystem is doing and where it is encountering errors. Common issues include mismatched Group IDs, incorrect Peer HA1 IP addresses, physical connectivity problems on HA interface cables, software version mismatches, and license discrepancies between the two units. The Palo Alto command line interface also provides powerful HA diagnostic commands such as show high-availability all and show high-availability state, which output comprehensive information about every aspect of the HA relationship that is invaluable during troubleshooting.

Conclusion

Configuring high availability on Palo Alto firewalls is one of the most impactful investments you can make in the resilience of your network security infrastructure. Every step of this process — from verifying hardware and software prerequisites to cabling the HA interfaces, configuring the control and data links, setting election priorities, enabling link and path monitoring, and finally testing failover — contributes to a system that protects your organization from the consequences of firewall failure. When implemented correctly, HA operates invisibly, doing its job in the background while your network runs without interruption.

The importance of testing cannot be overstated. Many organizations go through the effort of configuring HA and then never verify that it actually works until a real failure occurs, at which point they discover a misconfiguration that prevents proper failover at the worst possible moment. Scheduled HA failover tests, ideally conducted during maintenance windows and repeated after any significant configuration change, are the only way to have genuine confidence that your HA pair will perform as designed. Treat failover testing as a regular operational discipline rather than a one-time post-installation activity.

Maintaining HA over the long term requires ongoing attention to the prerequisites that made it work initially. When upgrading PAN-OS versions, follow the proper HA upgrade procedure, which involves upgrading the passive unit first, verifying that it is running the new version correctly, and then failing over to it before upgrading the originally active unit. Applying the same licenses, content updates, and configuration changes to both units in a coordinated way prevents the kind of drift between units that silently undermines HA readiness. Assigning clear operational responsibility for HA maintenance ensures that these tasks do not fall through the cracks during busy periods.

The investment in learning and implementing Palo Alto high availability pays dividends that extend beyond preventing individual outages. It builds the discipline of thinking about infrastructure redundancy at every layer, which is a mindset that makes every system you design more resilient. It also deepens your understanding of how Palo Alto firewalls work internally, because HA configuration touches session management, interface behavior, routing, and synchronization in ways that reveal how the platform handles traffic at a fundamental level. Every network security professional who manages Palo Alto infrastructure should have a solid working knowledge of HA configuration, and the step-by-step process covered throughout this guide gives you the foundation to build and maintain it with confidence.