Synchronization Between Panorama HA Peers
The Panorama HA peers synchronize the running configuration
each time you commit changes on the active Panorama peer. The candidate
configuration is synchronized between the peers each time you save
the configuration on the active peer or just before a failover occurs.
Settings that are common across the pair, such as shared objects
and policy rules, device group objects and rules, template configuration,
certificates and SSL/TLS service profiles, and administrative access
configuration, are synchronized between the Panorama HA peers.
When you
Enable Automated Commit Recovery, HA synchronization
occurs only after the firewall successfully tests the connection
between itself and Panorama after a push from Panorama.
The settings that are not synchronized are those that are unique
to each peer, such as the following:
Panorama HA configuration—Priority setting, peer IP address,
path monitoring groups and IP addresses
Panorama configuration—Management interface IP address, FQDN
settings, login banner, NTP server, time zone, geographic location,
DNS server, permitted IP addresses for accessing Panorama, SNMP
system settings, and dynamic content update schedules
Scheduled configuration exports
NFS partition configuration and all disk quota allocation
for logging. This applies only to a Panorama virtual appliance in
Legacy mode that runs on a VMware ESXi server
Disk quota allocation for the different types of logs and
databases on the Panorama local storage (SSD)
If you
use a master key to encrypt the private keys and certificates on Panorama,
you must use the same master key on both HA peers. If the master keys
differ, Panorama cannot synchronize the HA peers.
Password for the Panorama admin administrator
Synchronization Considerations for Cross-Hypervisor HA
(
PAN-OS 12.2.2 and later releases) When deploying Panorama HA peers across
different hypervisors or cloud environments, the following requirements apply to
ensure reliable configuration synchronization and consistent policy enforcement
after a failover.
Plugin Version Parity
Panorama HA forms successfully regardless of whether plugin versions
match between peers. The HA formation process does not check for plugin
version parity. However, a version mismatch between peers causes the
configuration synchronization to fail silently from a formation
perspective, meaning the HA pair appears healthy but configuration
changes on the active peer do not replicate to the passive peer.
- Before forming an HA pair: Confirm that both peers are
running identical plugin versions. SelectDashboard > High
Availability on both peers and compare the plugin
versions shown in the HA widget.
- Before updating a plugin: Install the update on both peers
before committing, to avoid introducing a transient version mismatch
that interrupts synchronization.
Content Versions
Both peers should run the same content versions (App-ID, Threat, and URL
Filtering databases) to ensure consistent policy enforcement after
failover. A mismatch does not prevent HA formation, but may result in
different policy decisions on the newly active peer until versions are
aligned.
Dynamic Address Groups (DAGs) and IP-Tag Mappings
The HA peers synchronize IP-tag mappings used in DAGs as part of standard
configuration synchronization. Tags and policies remain intact on the
newly active peer after a failover. In case of a cross-hypervisor
deployment, the IP addresses behind those tags represent entirely
different hosts or services in each cloud environment—for example, the
same IP range on an AWS subnet carries different workloads than on an
Azure subnet.
Avoid deploying
cross-hypervisor HA in production if your security policies rely on
cloud-sourced DAG mappings. DAG-based policies that rely on
cloud-sourced IP-tag mappings may produce unexpected policy
enforcement behavior after a cross-hypervisor failover, because the
same IP-tag mappings may refer to different hosts in each cloud
environment. Evaluate the impact of this behavior on your security
posture before deployment.
