Set Up Active-Passive HA on a Palo Alto Firewall Pair

Before you run this

This guide pairs two identical Palo Alto firewalls into an active-passive HA cluster: one firewall passes all traffic while the other sits in sync and takes over if the active one fails, reboots, or loses a monitored link. It does not load-balance — the passive box carries no production traffic until failover.

You need a superuser (full admin) web-GUI account on both firewalls. There is no root shell involved; everything here is done in the firewall's own admin plane. This is a hardware/appliance procedure, so treat it accordingly:

• Keep a separate out-of-band connection open — a serial console cable to each firewall, or SSH to the management interface over a path that does not depend on the data plane you are about to change. Enabling HA and committing changes how the pair forwards and negotiates state, and a wrong HA1 IP or a mismatched group can leave you locked out of one box.
• Back up the running config on BOTH firewalls first. Go to Device > Setup > Operations and use Save named configuration snapshot and Export named configuration snapshot on each unit. Keep those files off the box.
• The single most dangerous point: when config sync runs for the first time, the firewall you designate as primary pushes its running config to the peer. If you get the priorities backwards, you can overwrite a correctly configured peer with a blank or wrong one. Decide which box is the intended primary and confirm its config is the good one before you sync.
• Do this in a maintenance window. Even a clean setup causes at least one negotiation event.
• Rollback: to undo before committing, use Device > Setup > Operations > Revert to running configuration. After a commit, use Load configuration version (or Load named configuration snapshot) on the same Operations page to restore the backup you took, or simply disable HA (last section) and commit.

Environment assumed: two identical PA-series hardware firewalls, same model, running the same PAN-OS 11.0 maintenance release, with dedicated HA1 and HA2 ports and directly cabled HA links, managed standalone (no Panorama). If your model has no dedicated HA ports you will repurpose data ports — noted where it differs.

---

1. Confirm the prerequisites

HA will refuse to fully sync if the two units are not matched. Before touching HA config, verify on both firewalls:

• Identical model and identical PAN-OS version (Device > Software).
• Same operational mode and same set of licenses/subscriptions.
• HA links cabled: HA1 (control) port to HA1 port, HA2 (data) port to HA2 port. Direct cables are the standard, cleanest choice.

2. (Only if you have no dedicated HA ports) set data ports to type HA

Skip this if your model has dedicated HA1/HA2 ports. Otherwise, on each firewall:

1. Network > Interfaces > Ethernet.
2. Click the interface you will use for HA1, set Interface Type = HA, click OK.
3. Repeat for the HA2 interface.

Do not assign these to a zone or a virtual router — HA interfaces are outside normal forwarding.

3. Configure HA on the primary firewall

On the intended primary unit, go to Device > High Availability > General and work through the sections.

Setup:

• Enable HA: checked.
• Group ID: a number (1–63). It must be identical on both firewalls. Example: 1.
• Description: optional.
• Mode: Active Passive.
• Enable Config Sync: checked (this is what keeps policy/objects in sync).
• Peer HA1 IP Address: the HA1 IP of the other firewall — e.g. 10.255.0.2.

Control Link (HA1):

• Port: the dedicated HA1 port (or the data port you set to HA).
• IPv4/Netmask: this firewall's HA1 address, e.g. 10.255.0.1 / 30.
• Gateway: leave blank if the two HA1 ports are directly connected on the same subnet.

For a directly cabled HA1 link on trusted hardware, HA1 encryption is commonly left off. Encryption is available and involves exporting/importing an HA key between the peers — if you need it, follow the exact export/import steps in the Palo Alto PAN-OS Administrator's Guide section on securing HA links, rather than guessing the menu.

Data Link (HA2):

• Port: the dedicated HA2 (or HSCI) port, or your chosen data port.
• Transport: leave the default ethernet for a direct HA2 cable.
• Enable Session Synchronization: keep enabled so existing sessions survive failover.

Election Settings:

• Device Priority: set the primary to a lower number, e.g. 100. Lower priority wins the active role.
• Preemptive: I leave this unchecked. With preemption off, when a recovered firewall comes back it stays passive instead of forcing another failover — one disruption instead of two. Enable it only if you have a firm reason to pin the active role to one box.

Active/Passive Settings:

• Passive Link State: set to Auto. This keeps the passive firewall's data interfaces up (but not forwarding), so failover is faster. The default, shutdown, works but adds link-up delay on failover.

4. Configure HA on the passive firewall

Repeat Step 3 on the secondary unit, mirrored:

• Same Group ID, same Mode, Enable Config Sync checked.
• Peer HA1 IP Address: the primary's HA1 IP, e.g. 10.255.0.1.
• Control Link (HA1) IPv4: this box's own HA1 address, e.g. 10.255.0.2 / 30.
• HA2 Port/Transport: matching the primary.
• Device Priority: a higher number than the primary, e.g. 110.
• Preemptive: unchecked (match the primary).
• Passive Link State: Auto.

5. (Optional but recommended) add link monitoring

On both firewalls, Device > High Availability > Link and Path Monitoring lets you list interfaces whose failure should trigger failover. Add the interfaces carrying real production traffic (uplinks, LAN). Leave Failure Condition at the default (any) unless you specifically want to require multiple links to fail.

6. Commit and perform the first sync

1. Commit on the primary, then Commit on the secondary.
2. Give them a minute to negotiate over HA1.
3. On the primary, open the Dashboard, find the High Availability widget, and click the Sync to peer link to push the primary's config to the peer. Confirm when prompted.

Verify it worked

In the Dashboard High Availability widget on the primary, you should see:

• Local: Active, Peer: Passive
• Running Config: Synchronized
• HA1 and HA2 link states green/up.

From the CLI on either firewall (these are read-only and safe):

show high-availability state
show high-availability all

show high-availability state reports each unit's role (active/passive) and whether the pair is fully negotiated; show high-availability all gives the detailed control-link, data-link, and monitoring status.

Test failover safely

During your maintenance window, suspend the active firewall so the passive takes over, then restore it:

request high-availability state suspend

Watch the passive unit become active (Dashboard widget / show high-availability state), confirm traffic still flows, then bring the first unit back:

request high-availability state functional

With preemption off, the recovered unit returns as passive — which is the calm, expected outcome. Do not skip this test; an HA pair you have never failed over is an assumption, not a safety net.

Undo / roll back

To dismantle HA cleanly:

1. On each firewall: Device > High Availability > General > Setup, uncheck Enable HA.
2. Commit on both.
3. If you also changed interface types in Step 2, revert those under Network > Interfaces > Ethernet.

If a commit went wrong, restore the pre-change state from the backup you took: Device > Setup > Operations > Load named configuration snapshot (or Load configuration version), then commit. This is why the Step-0 backup and the open console session matter — they are your way back.