Synchronized Logging Across a Palo Alto HA Pair

Before you run this

This guide configures both members of a PAN-OS active/passive HA pair to forward their logs to a shared collector — an external syslog server (or Panorama) — so that no matter which unit is active, and no matter which one just failed over, you end up with one continuous log record. Be clear about what this is not: PAN-OS does not replicate the local log databases between HA peers. The active unit sees the traffic and writes traffic logs; the passive unit does not pass traffic and so has no traffic logs of its own. "Synchronized logging" here means both units point at the same external destination, and because HA config sync copies the running config to the peer, you configure it once on the active unit and the passive inherits it.

Privileges: You need a firewall administrator account with commit rights (a superuser role is simplest). Everything is done in the web UI with a couple of CLI checks; no OS shell.

This is a config change and requires a commit. Adding log-forwarding profiles and applying them to security rules does not change what the firewall permits or denies — you are only turning on logging and shipping — but it still commits into the running config and syncs to the peer. Test the whole procedure on a lab pair or a non-production HA pair before touching production, and read every value you enter.

Firewall-specific safety:

• Keep a separate out-of-band path open — a console cable or a management session to each member's own management IP — before you commit. A bad service-route or management change can cut you off.
• Back up the running config first. Device → Setup → Operations → Save named configuration snapshot, then Export named configuration snapshot to your workstation.
• Do this in a maintenance window, and don't combine it with security-rule edits.
• Rollback path: Device → Setup → Operations → Load named configuration snapshot (choose the snapshot you exported), then commit. You can also use Load configuration version to step back to the last known-good version.

Assumptions

• Two Palo Alto firewalls in an active/passive HA pair, PAN-OS 11.1.
• HA is already formed and running-config sync is enabled and healthy.
• Logs go to an external syslog server over UDP/514 in this example; the Panorama path is noted where it differs.
• Each firewall uses its own management interface as the syslog source (the default). Because each member has a distinct management IP, your syslog server will see two sources — that is expected and correct.

Step 1 — Confirm HA config sync is healthy

Everything below depends on config sync working, so check it first. On the active unit:

show high-availability state
show high-availability all

In the output confirm the local state is active, the peer is passive, and the running config is synchronized. You can also read this from the Dashboard → High Availability widget — look for Running Config: synchronized. If it is out of sync, fix that before continuing.

Step 2 — Create the syslog server profile (on the active unit)

Do all configuration on the active member. Navigate to:

Device → Server Profiles → Syslog → Add

• Name: e.g. syslog-central
• Under the Servers tab, Add:
  • Name: a label, e.g. siem-01
  • Syslog Server: the IP of your collector, e.g. 192.0.2.50
  • Transport: UDP (or TCP/SSL if your collector requires it)
  • Port: 514 for UDP
  • Format: BSD or IETF — match what your collector expects
  • Facility: choose the facility your collector filters on

Replace the name, IP, and port with your own values.

(For Panorama instead of syslog: you configure Panorama's IP under Device → Setup → Management → Panorama Settings, and select Panorama as the destination in the log-forwarding steps below rather than a syslog profile.)

Step 3 — Forward system, config, and HA logs

Traffic and threat logs are forwarded via a separate profile (next step). System, Configuration, and HA logs — which include failover events, and are exactly what you want from both members — are configured here:

Device → Log Settings

For the System, Configuration, and HA sections, Add a match entry and set Syslog to the syslog-central profile you just created. This is what makes the passive unit useful as a log source: even though it passes no traffic, it will report its own health and failover events.

Step 4 — Create a log-forwarding profile for traffic and threat logs

Objects → Log Forwarding → Add

• Name: e.g. lf-to-syslog
• Add a match-list entry per log type you care about (Traffic, Threat, URL, etc.). For each entry, set Syslog to syslog-central.

Step 5 — Apply the log-forwarding profile to your security rules

A log-forwarding profile does nothing until it is attached to a security policy:

Policies → Security → select a rule → Actions tab:

• Log Forwarding: select lf-to-syslog
• Confirm Log at Session End is checked (and Log at Session Start only if you specifically want it — it is much noisier).

Apply this to the rules whose traffic you want in the collector. On an HA pair the same rulebase runs on both members, so once the active unit's rules carry the profile, the newly-active unit after a failover will forward too.

Step 6 — Check the source interface (service route)

By default, syslog leaves via the management interface, using each member's own management IP. If your management network cannot reach the collector, set a service route:

Device → Setup → Services → Service Route Configuration

Point the Syslog service at the interface/source you want. Set this consciously — each HA member will use its own IP on that interface, which is why the collector correctly shows two distinct sources.

Step 7 — Commit and let it sync

Commit on the active unit. With running-config sync enabled, the change replicates to the passive member automatically. If you want to force it, use the Sync to peer action in the Dashboard → High Availability widget, or from the CLI:

request high-availability sync-to-remote running-config

After the commit, both members hold identical forwarding config, and each ships its own logs to the shared collector.

Verify it worked

1. Confirm config sync after the commit (on either unit):

show high-availability state

The running config should read as synchronized, with the peer showing the new config.

2. Confirm the passive unit inherited the config. Log in to the passive member's own management IP and check that the syslog server profile (Device → Server Profiles → Syslog), the log-forwarding profile (Objects → Log Forwarding), and the Log Settings entries are present. They should be, and greyed out, because config comes from the active peer.

3. Confirm logs are arriving. On your syslog/Panorama collector, look for messages from both management IPs. Generate some traffic through the active unit to produce traffic logs, and expect at minimum system/HA messages from the passive unit.

4. Cross-check locally. On the active unit, Monitor → Logs → Traffic shows what it is logging locally; those same entries should appear at the collector. (The passive unit's Traffic log will be sparse or empty — that is normal.)

5. Optional: test failover in your maintenance window (suspend the active unit from the HA widget) and confirm the newly-active member continues forwarding, and that the failover itself shows up as an HA/system log at the collector. Return the suspended unit to functional afterward.

Undo

The change is fully reversible:

• Remove the log-forwarding profile from each security rule (Policies → Security → Actions).
• Delete the log-forwarding profile (Objects → Log Forwarding), the Log Settings entries (Device → Log Settings), and the syslog server profile (Device → Server Profiles → Syslog).
• Commit. The removal syncs to the peer.

Or, to roll back everything at once, Device → Setup → Operations → Load named configuration snapshot, select the snapshot you exported in the safety note, and commit. If you need the exact menu wording or a field you're unsure about, check the PAN-OS 11.1 Administrator's Guide sections on Log Forwarding and HA Configuration Synchronization rather than guessing.