Logging, Monitoring & High Availability

PAN-OS Log Types

PAN-OS generates multiple distinct log types, each capturing different aspects of firewall activity. Understanding which log type to query for which investigation is essential for effective incident response.

Log Type	What It Records	Key Fields
Traffic	All allowed and denied sessions	src/dst IP, port, app, bytes, rule, user, zone
Threat	IPS, AV, WildFire, URL filter, data filter hits	threat-id, severity, action, attacker, victim
URL	All web requests with category	URL, category, action, user, response code
Data	Data filtering and file blocking events	pattern, file name, direction
Auth	Authentication events (GlobalProtect, Captive Portal)	user, status, auth server, client IP
System	Firewall operational events	event type, severity, description
Config	All configuration changes	admin, client, time, path changed
HIP Match	Host Information Profile match events	user, host, profile, match
GTP	Mobile network GTP tunnel events (carrier grade)	IMSI, APN, bearer

Traffic Log Performance Note

Logging every allowed session to traffic logs can generate enormous volumes on busy firewalls. Best practice: enable log at session end for all allow rules, but exclude high-volume, low-risk applications (internal DNS queries, NTP) by creating a dedicated allow rule with logging disabled for those applications.

Log Forwarding

PAN-OS can forward logs to external systems in real time using multiple methods. This is critical for SIEM integration, long-term log retention, and compliance reporting.

Forwarding Methods

Method	Protocol	Destination	Best For
Syslog	UDP/TCP/SSL	Syslog server, SIEM	Universal compatibility; all log types
SNMP Trap	UDP 162	NMS (Network Management System)	System and threshold alerts only
Email	SMTP	Ops/security team mailbox	Critical system alerts and threat events
HTTP Log Forwarding	HTTP/HTTPS	Splunk HEC, webhooks, custom apps	Splunk integration, cloud SIEMs

Log Forwarding Profile

Log forwarding profiles define where to send logs and which log types to forward. They can include filters to forward only specific log entries (e.g., only Critical and High severity threats, not Informational). Log forwarding profiles are attached to security policy rules under the Log Setting field.

pan-os-cli

# Test syslog forwarding
test log-forwarding syslog server <profile-name>

# View recent traffic logs (CLI)
show log traffic direction equal forward

# View recent threat logs
show log threat

# View system logs
show log system

# View config audit log
show log config

Panorama Centralized Management

When managing more than a few firewalls, Panorama eliminates the need to log into each device individually. It provides a single pane of glass for configuration, policy management, log aggregation, and reporting.

Panorama Hierarchy

→

Device Groups — logical containers for firewalls sharing common security policies and objects. A device group can be shared (applies to all managed firewalls) or specific to a subset.

→

Templates — push consistent network configuration (zones, interfaces, routing, server profiles) to multiple firewalls. Template stacks allow layering — a base template for all devices, with device-specific overrides in a stack.

→

Log Collectors — Panorama collects logs from managed firewalls into a centralized log store. Analysts query one interface instead of logging into each firewall separately.

→

Administrative Roles — Panorama supports granular RBAC: a SOC analyst might have read-only access to logs for all firewalls, while a network admin has full configuration access only for their assigned device group.

High Availability — HA Modes

High Availability ensures firewall functionality continues despite a hardware or software failure. PAN-OS supports two HA modes.

Active/Passive HA

One firewall is active and processes all traffic. The second firewall is passive — it synchronizes state from the active peer but does not forward traffic. On failover, the passive device becomes active. Session synchronization ensures that established sessions survive failover without disruption to users.

Simpler to configure and troubleshoot than Active/Active
Consistent inspection — all traffic processed by one device at a time
Failover typically completes in under 60 seconds for link/path failures
Active device uses its own IP; passive device has a separate management IP
Virtual IP (floating IP) moves to the active device; downstream devices do not need to change routing

Active/Active HA

Both firewalls actively process traffic simultaneously. Traffic is distributed across both peers using a floating IP or route-based distribution. Provides both redundancy and load distribution.

More complex to configure — asymmetric routing must be handled
Both firewalls must synchronize session state (HA2 link)
Requires HA3 link for active-active packet forwarding (sending packets between peers)
Useful when a single active firewall is a throughput bottleneck

HA Components

Link	Protocol	Purpose
HA1	Layer 3 (encrypted)	Heartbeat, keepalives, routing/control plane state sync
HA2	Layer 2 or Layer 3	Session state synchronization (data plane sessions)
HA3	Layer 2 (dedicated)	Active/Active packet forwarding between peers
HA Backup	Optional	Backup HA1 or HA2 path for additional redundancy

HA Best Practice

Use dedicated physical interfaces for HA1 and HA2. Never share HA links with data traffic. HA1 should use a direct cable between the two firewalls or a dedicated management VLAN — not the internet-facing interface. Configure backup HA1 and HA2 paths to prevent a single cable failure from causing a split-brain scenario.

HA Failover Triggers

Physical link failure — monitored interface goes down; failover triggers immediately
Path monitoring — firewall periodically pings critical upstream IPs; failover if pings fail beyond threshold
Hello keepalive loss — HA1 heartbeat messages missed beyond the dead interval (default: 10 seconds)
Hardware failure — dataplane hardware error triggers failover
Manual preemption — administrator triggers failover from Panorama or CLI for maintenance

Preemption

Preemption allows the primary firewall to automatically resume the active role after recovering from a failure. Without preemption, the secondary remains active even after the primary recovers, requiring a manual failback. In most environments, preemption is enabled to maintain a predictable primary/secondary designation, but with a preemption hold timer (e.g., 1–5 minutes) to ensure the recovering device is fully stable before taking over.

HA Verification Commands

pan-os-cli

# Show HA state (active/passive, sync status)
show high-availability state

# Show HA state on both peers
show high-availability all

# Show HA link status
show high-availability interface ha1
show high-availability interface ha2

# Show session synchronization stats
show high-availability state-synchronization

# Trigger failover (switch active to passive — maintenance)
request high-availability state suspend

# Return to active state
request high-availability state functional

# Synchronize configuration from active to passive
request high-availability sync-to-remote running-config

PAN-OS Course Complete

You have completed the Firewall Mastery NGFW course. You now understand PAN-OS architecture, security policies, NAT, App-ID, URL filtering, threat prevention, VPN configuration, and high availability. Continue with the Threat Intelligence course to deepen your understanding of the threat landscape your firewall is defending against.

Previous Module

Course Complete