PAN-OS high availability is not simply “two firewalls with the same configuration.” A resilient pair depends on control communication, state synchronization, path monitoring, consistent software and licensing, predictable election behavior, and a network design that can move traffic to the surviving peer. If those pieces are not engineered together, a pair can look healthy in the GUI yet fail during the event it was built to survive.
The current Next-Generation Firewall Engineer certification validates NGFW deployment, networking, device settings, management, and operations. High availability sits across all of those domains because failover is both a firewall feature and a network event.
Active/passive keeps one peer forwarding at a time
In a typical active/passive design, the active firewall processes production traffic while the passive peer receives synchronized configuration and state so it can take over when required. This model reduces some of the traffic-distribution complexity associated with active/active deployments.
Failover can be triggered by device health, monitored interfaces, monitored paths, or loss of HA communication depending on configuration. The passive peer must be capable of assuming the active role without depending on the failed component.
Do not treat “passive” as idle. The passive firewall needs healthy control and data links, current software/content compatibility, correct cabling, power, upstream connectivity, and regular validation.
HA1 carries control information
HA1 is the control-link function used for heartbeats, hello messages, configuration synchronization, and other coordination between peers. If the control path fails, the peers can lose the information they use to determine each other’s state.
Redundancy matters. Current Palo Alto Networks guidance supports heartbeat backup over the management path in applicable designs. A backup control path helps prevent split-brain scenarios in which both peers believe the other is unavailable and both attempt to become active.
Monitor control-link health as an operational metric. A degraded HA1 path may not cause immediate traffic loss, but it removes resilience and can turn the next failure into a larger outage.
HA2 synchronizes dataplane state
HA2 carries state information such as the session table in supported HA modes, allowing the passive peer to continue many sessions after failover. Current PAN-OS documentation distinguishes which dataplane elements synchronize and which do not.
If HA2 is down, the pair may still appear generally available, but session continuity is compromised. A failover can force applications to establish new sessions because the new active peer lacks the state of the previous one.
Verify session synchronization rather than assuming it is enabled and healthy. Check link status, keep-alive behavior, and any backup data-link design.
Know which state does not survive failover
Not every session or table is synchronized. Current reference documentation notes exceptions, and decrypted SSL sessions in particular are not synchronized between peers. That means users may experience reconnects during failover even when HA behaves correctly.
Applications differ in how well they recover. Stateless web requests may retry transparently, while long-lived administrative sessions, real-time traffic, or certain encrypted connections may reset. Define service expectations around the actual synchronization model rather than promising “zero interruption” generically.
Test representative applications during planned failover windows to establish realistic recovery behavior.
Link and path monitoring connect firewall health to network health
A firewall can be powered on and internally healthy while its upstream or downstream network path is broken. Link monitoring and path monitoring allow failover decisions to consider these external dependencies.
Select monitoring targets carefully. A single remote address can become a false failover trigger if that host fails while the network is otherwise healthy. Conversely, monitoring only a local interface can miss an upstream routing failure beyond the first hop.
Design monitors around services or paths whose loss genuinely makes the active firewall unable to perform its role. Document thresholds and test both true failures and benign maintenance events.
Election settings should reflect deliberate preference
Device priority and preemption can influence which peer should be active when both are healthy. Use them when there is a real reason to prefer one device—for example, network attachment, operational convention, or hardware characteristics—not merely because every HA pair seems to need a “primary.”
Preemption can cause a recovered preferred firewall to reclaim the active role, creating a second transition after an outage. Decide whether that behavior is desirable for the applications and maintenance process.
A stable pair is often more important than returning immediately to the original active device. Make the preference an engineering choice, not a default habit.
Network design must support role movement
Failover succeeds only if surrounding switches, routers, peers, and adjacent services recognize the new active firewall. Virtual MAC behavior, ARP/neighbor information, dynamic routing adjacencies, link aggregation, and upstream convergence all influence recovery time.
Switching and routing fundamentals matter because firewall HA is inserted into a larger forwarding topology. A perfectly synchronized firewall cannot overcome an upstream design that still points traffic at the failed peer.
Measure end-to-end service restoration, not only the time it takes the HA status indicator to change.
Prevent split brain with redundant communication and clear topology
Split brain occurs when peers lose communication but both remain capable of forwarding and each concludes that the other has failed. This can create duplicate IP/MAC ownership, asymmetric traffic, routing instability, and difficult recovery.
Use recommended HA link redundancy and heartbeat mechanisms, and avoid designing both control paths through the same fragile infrastructure. Physical separation is valuable only when the backup path does not share the same failure domain.
When diagnosing a suspected split-brain event, reconstruct HA link state, election history, interface status, and network reachability on both peers rather than examining only whichever device is currently active.
Test HA as an operational procedure
A pair should be tested before production and periodically afterward. Validate manual failover, monitored-link failure, monitored-path failure, control-link degradation, state synchronization, and restoration. Confirm what happens to routing peers, VPNs, NAT sessions, decrypted traffic, and critical applications.
Palo Alto firewall monitoring can define the logs and health indicators that demonstrate whether traffic moved cleanly during failover.
Record the observed recovery time and session impact. HA is not proven because configuration is synchronized; it is proven when the business service survives the failures the design claims to tolerate.
Keep peers operationally equivalent.
Configuration synchronization can fail when software, features, licenses, plugins, or other prerequisites differ between peers. Maintenance procedures should preserve compatibility during upgrades and content changes.
Before a planned upgrade, confirm which peer will remain active, how state will be handled, and how the team will recover if the upgraded device does not rejoin correctly. After maintenance, verify both configuration and state synchronization instead of stopping when the dashboard shows both units online.
High-availability objectives across Palo Alto Networks certifications emphasize operational ownership. A resilient HA pair depends on healthy control and state links, predictable elections, tested network convergence, compatible peers, and realistic expectations about which sessions survive failover.
Software upgrades are one of the best tests of HA discipline. Plan which peer upgrades first, how the active role will move, whether content or plugin versions must match, and what conditions would stop the procedure. A rolling upgrade that is not rehearsed can leave the pair in a partially compatible state where configuration or session synchronization behaves differently than expected.
External dependencies also deserve failure testing. If dynamic routing peers establish separately with each firewall, measure how quickly neighbors and routes recover after a role change. If upstream switches use link aggregation or virtual MAC learning, verify their convergence. If VPNs terminate on the pair, confirm security associations and application sessions recover within the accepted service objective.
Operational monitoring should distinguish “HA is enabled” from “HA is ready.” Alert on degraded control or data links, synchronization failures, version mismatch, path-monitor failures, unexpected peer state, and repeated role changes. A pair that has lost redundancy but is still forwarding traffic is already in a failure condition from a resilience perspective.
After any real failover, perform a post-event review. Determine what triggered it, whether the new active peer handled traffic correctly, which sessions were disrupted, how long routing and applications took to recover, and whether failback introduced another interruption. These observations are more valuable than assuming the documented design behaved exactly as planned.
Capacity parity between peers should be part of HA planning. Hardware models, interface availability, subscriptions, and enabled features should support the same production load after failover. A secondary unit that can technically become active but cannot sustain normal throughput or inspection demand does not provide the resilience the design assumes.
Test failure boundaries one at a time. Disconnect an HA control path, then a data path, then a monitored production path, and record which condition triggers failover versus only an alert. This teaches operators the difference between degraded redundancy and an actual role transition and helps tune monitoring thresholds without guesswork.
Maintenance documentation should also define failback. Decide whether the recovered preferred peer should preempt automatically, whether traffic should remain on the current active peer until a window, and which checks are required before restoring the original state. Planned failback can be as disruptive as failover if it is treated as an afterthought.
Document the expected status of every HA link and monitor before maintenance begins. A pair that already has a failed backup link or unsynchronized state should not enter an upgrade as though full redundancy exists. Repair degraded HA first or explicitly accept the reduced resilience in the change plan.