Courseiva
PCNSAChapter 8 of 15Objective 4.2

Device Management: Panorama Integration and Log Forwarding

Exam objective 4.2 asks you to describe Panorama centralised management and configure log forwarding to external systems. This concept matters because managing one firewall is manageable, but real businesses often have dozens or hundreds spread across offices, data centres, and cloud environments — you need a way to see everything at once and to store logs securely off the firewall itself. For the PCNSA exam, you must understand how Panorama simplifies policy management and how to send logs to systems like a Security Information and Event Management (SIEM) tool for analysis and compliance.

12 min read
Intermediate
Updated Jul 23, 2026
Reviewed by Johnson Ajibi· Senior Network & Security Engineer · MSc IT Security

A simple way to picture Device Management: Panorama Integration and Log Forwarding

The Restaurant Chain Manager Analogy

Have you ever watched a restaurant manager juggle orders, staff, and customer complaints while also trying to fix a broken freezer in the back? That is what managing a single firewall feels like — chaotic and hands-on. Now, what if that manager could sit in a central office with a giant screen showing every table, every kitchen, and every delivery driver across fifty different branches, all at once? That is the promise of Panorama.

In this analogy, each restaurant branch is a different firewall protecting a part of your network — maybe one in the London office, another in a data centre, and a third in a cloud environment. The central manager is Panorama, a single pane of glass that lets you see all branches simultaneously. When a customer complains about a cold meal (a security incident), the central manager can instantly check the logs from that specific branch (the firewall logs), see what went wrong, and push out a new recipe or cooking temperature (a security policy) to every branch at once. Without Panorama, you would have to phone each branch individually, ask them to check their own paper records, and then fax them a new recipe — slow, error-prone, and exhausting. Panorama centralises the logs and the control, so you can troubleshoot, update, and monitor every firewall from one place without ever leaving your desk.

How It Actually Works

To understand Panorama, imagine you are the manager of a security team responsible for 20 firewalls across four countries. Without Panorama, you would have to log in to each firewall individually to update rules, check logs, or apply a security patch. This approach is called 'management per-device' and it is a nightmare at scale — it is slow, easy to make mistakes, and almost impossible to enforce a consistent security policy across every location.

Panorama is Palo Alto Networks' centralised management platform. It is a physical appliance or a virtual machine that acts as a single control centre for all your Palo Alto Networks firewalls. Instead of logging in to each firewall, you log in to Panorama. From there, you can push policies (rules that decide what traffic is allowed or blocked) to every firewall at once. You can also collect logs from every firewall in one place, view them in a single dashboard, and forward them to external systems for long-term storage or analysis.

Let's break down the key components:

Panorama manages firewalls through a concept called 'device groups'. A device group is a logical container that holds similar firewalls — for instance, all firewalls in the European offices could be in one device group, and all firewalls in the US in another. You create policies at the device group level, and those policies are automatically pushed to every firewall inside that group.

Logs are records of events that happen on a firewall — every connection attempt, every threat blocked, every system change. Firewalls generate huge amounts of logs, but they have limited local storage. Panorama can collect these logs from all firewalls and store them centrally. This central log collection is called the Log Collector.

Log forwarding is the process of sending those logs from Panorama (or directly from a firewall) to an external system, like a SIEM (e.g., Splunk, IBM QRadar), a syslog server, or cloud storage. This is critical for compliance with regulations (like GDPR or PCI DSS) because you often need to keep logs for months or years, and firewalls themselves cannot store that much data.

Why does this all matter? Consider a real example: a security analyst needs to investigate a data breach that happened two months ago. If logs are only stored locally on each firewall, the analyst would need to access each firewall individually, hope the logs are still available (they often overwrite old logs with new ones), and manually piece together a timeline. With Panorama, the logs are aggregated in one place, searchable, and retained for as long as you configure. Even better, you can forward them to a SIEM where automated analysis can spot patterns.

Panorama also enables 'log filtering' — you can choose to forward only specific types of logs, such as 'threat logs' (records of blocked attacks) or 'traffic logs' (records of allowed connections), to different destinations. For example, you might send threat logs to a SIEM for immediate analysis and traffic logs to a cheap cloud storage bucket for archival.

On the PCNSA exam, you need to know that Panorama supports two deployment models: 'on-premises' (you run it in your own data centre) and 'cloud-managed' (Palo Alto Networks hosts it as a service, called Panorama as a Service). You also need to know about 'log forwarding profiles' — these are configurations within a policy or on the firewall that define where logs go (e.g., a syslog server) and what format they use (e.g., syslog with specific field mappings).

In summary, Panorama turns the messy job of managing many firewalls into a structured, centralised operation. Log forwarding ensures your critical security data lives beyond the firewall's limited storage, enabling compliance and advanced security analysis.

This diagram shows how Panorama centrally pushes policies to multiple firewalls while the firewalls independently forward their logs to a common external syslog server or SIEM.

Walk-Through

1

Register Firewalls to Panorama

Each firewall must be registered to Panorama using an IP address and authentication key. Once registered, the firewall appears in the Panorama management interface and becomes manageable.

2

Create Device Groups

Group similar firewalls (e.g., by location or function) into a device group. Policies you create at the device group level are automatically pushed to all firewalls in that group.

3

Define and Push Policies

Create security policies — rules that allow or deny traffic based on source, destination, application, and user. Commit (save) the changes and push them to the device group. All firewalls in the group receive the update simultaneously.

4

Configure Log Forwarding Profile

Create a Log Forwarding Profile that selects the log types you want to forward (e.g., Threat logs, Traffic logs) and specifies the destination (e.g., a syslog server IP and port). Attach this profile to the security policy.

5

Verify Log Forwarding

Check that logs are arriving at the external destination by performing a test action (e.g., generating traffic or triggering a block rule). Use Panorama's monitor tab or the external syslog server to confirm logs are received.

6

Monitor and Maintain

Regularly review Panorama dashboards for policy violations, unusual traffic patterns, and firewall health. Update policies as needed and ensure log forwarding destinations remain reachable.

What This Looks Like on the Job

Let's follow Priya, a junior security administrator at a mid-sized e-commerce company called ShopFast. ShopFast has three offices: London (head office), Berlin, and Singapore. Each office has a Palo Alto Networks firewall. The company also uses Amazon Web Services (AWS) for its web application, which has a virtual firewall. That means Priya needs to manage four firewalls manually — until she decides to implement Panorama.

Here is what Priya actually does, step by step:

1.

Priya deploys a Panorama virtual appliance in the company's London data centre. She configures it with an IP address, sets up administrator accounts, and registers the four existing firewalls to Panorama. Registration involves providing each firewall with the Panorama IP address and a shared authentication key. Once registered, the firewalls appear in Panorama's management interface.

2.

Priya creates a device group called 'Global-Office-Firewalls' and adds the London, Berlin, and Singapore firewalls to it. She creates a separate device group for the AWS firewall because cloud deployment might need different policies. She then creates a base security policy that blocks all traffic from high-risk countries and allows web traffic on ports 80 and 443. She pushes this policy to the 'Global-Office-Firewalls' group. All three office firewalls receive the update simultaneously within seconds.

3.

For compliance with the Payment Card Industry Data Security Standard (PCI DSS), ShopFast must store all firewall logs for one year. Priya configures Panorama to forward logs from all firewalls to a central syslog server hosted on a Linux machine. She creates a 'Log Forwarding Profile' that selects 'Threat Logs' and 'Traffic Logs' and specifies the syslog server's IP address and port 514. She attaches this profile to the security policy she pushed earlier.

4.

When a new ransomware variant hits the news, Priya's manager asks her to block all connections to known malicious IP addresses. Instead of updating four firewalls manually, Priya creates a new 'Custom External Dynamic List' (EDL) in Panorama — a live feed of malicious IPs from a threat intelligence provider. She then adds a rule in the central policy to block traffic to any IP in that list. With one push, all four firewalls are updated.

5.

A few weeks later, the company's security analyst needs to investigate a phishing alert. The analyst opens the SIEM, searches for blocked email traffic from the past three months, and finds the logs immediately. Without Panorama and log forwarding, the analyst would have had to log in to each firewall, hope the local logs hadn't been overwritten, and manually export them.

Priya's daily tasks now revolve around Panorama: she checks the central dashboard for failed logins, reviews forwarded logs in the SIEM for anomalies, and pushes policy updates when new threats emerge. She rarely logs in to individual firewalls — only for emergency troubleshooting when a firewall loses connectivity to Panorama.

How PCNSA Actually Tests This

The PCNSA exam tests objective 4.2 with questions that check your understanding of Panorama's role in centralised management and the mechanics of log forwarding. You will see multiple-choice questions, drag-and-drop ordering tasks, and 'select all that apply' scenarios. The exam expects you to distinguish between Panorama and single-firewall management, and to know the exact steps for configuring log forwarding.

Here are the specific concepts you must memorise and the traps the exam sets:

Device groups vs. template stacks. Device groups hold policies. Template stacks hold network and device settings (like interface IPs, static routes, and management access settings). The exam loves to ask: 'Which would you use to push a security policy across 50 firewalls?' Answer: device group. 'Which would you use to configure NTP servers on all firewalls?' Answer: template stack. Memorise that distinction.

Log forwarding profiles can be configured at three levels: on the firewall directly (per-device), in a policy rule (rule-based), or in a device group policy (centralised). A common exam trap: 'You want all firewalls managed by Panorama to send traffic logs to a single syslog server. Where do you configure the log forwarding profile?' The correct answer is in the device group's default policy, because that applies to all firewalls in the group. Configuring it individually on each firewall defeats the purpose of centralisation.

The exam tests 'log types' and their purposes. The five main log types you must know are: Traffic (allowed/blocked connections), Threat (malware, exploits, viruses), URL Filtering (blocked websites), WildFire (submissions and verdicts for unknown files), and Data Filtering (attempts to exfiltrate sensitive data). A typical question: 'Which log type would you check to see if a user tried to download a malicious file?' Answer: Threat logs.

Another trap concerns 'collection tiers' in Panorama. You need to know that Panorama's built-in log storage is called the 'Panorama logging service' and that logs are forwarded to 'Log Collectors' (dedicated virtual or physical appliances) for large-scale deployments. The exam may ask: 'When should you use a Log Collector instead of Panorama's built-in storage?' The answer: when you need to store more than a few gigabytes of logs per day or need high-performance search.

Syslog vs. Panorama log forwarding. The exam will ask you to identify which protocol is used for forwarding logs to external servers. The correct answer is syslog (UDP or TCP). A trap might suggest SNMP or SMTP — both are wrong for standard log forwarding. You should also know that Panorama supports 'syslog transmission with a specific format' — by default, it uses the 'Palo Alto Networks log format' which includes fields like source IP, destination IP, application, and action.

The exam also tests 'log filtering' and 'severity levels'. You can forward only logs with a severity of 'critical', 'high', 'medium', or 'low'. A question might say: 'An administrator wants to be notified only when a critical threat is blocked. Which filter should they apply?' Answer: set severity to 'critical'.

Finally, expect a question about Panorama high availability. Panorama can be deployed in an Active/Passive pair. The exam tests the concept: if one Panorama fails, the passive one takes over without a gap in management, but each firewall still makes its own forwarding decisions independently using the last pushed policy.

To prepare, lab the configuration: create a pseudo-device group, push a policy, and set up a log forwarding profile to a dummy syslog server (even if it's just on your local machine). Practise identifying which logs go to which server based on the filters.

Key Takeaways

Panorama is a centralised management platform that lets you push security policies to multiple Palo Alto Networks firewalls from a single console.

Device groups contain firewalls that share the same security policies; template stacks contain network and device configuration settings.

Log forwarding requires a Log Forwarding Profile that specifies which log types (e.g., Traffic, Threat) go to which external server (e.g., syslog, SIEM).

Firewalls continue to operate independently if Panorama is unavailable; they enforce the last received policy and store logs locally until Panorama reconnects.

Syslog (UDP/TCP) is the standard protocol used for forwarding logs to external systems; common servers include Splunk, QRadar, and generic syslog servers.

The five main log types on a Palo Alto firewall are Traffic, Threat, URL Filtering, WildFire, and Data Filtering.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Device Group

Used for security policies (rules that permit/deny traffic)

Applies to firewalls grouped logically (e.g., all office firewalls)

Pushed from Panorama to firewalls in the group

Template Stack

Used for network and device configuration (interfaces, routes, NTP)

Applies to firewalls grouped by deployment type or location

Pushed from Panorama to firewalls in the template stack

Local Firewall Logging

Logs stored on the firewall's local disk

Limited retention (hours or days depending on volume)

Accessed by logging in to the firewall directly

Log Forwarding via Panorama

Logs sent to an external server (syslog, SIEM, cloud storage)

Retention depends on external system's capacity (weeks to years)

Accessed via the external system's interface

Panorama as a Management Tool

Primary function: centralised policy management and log collection

Provides a dashboard for firewall health and policy status

Not designed for advanced correlation or long-term threat hunting

SIEM as a Log Analysis Tool

Primary function: aggregate, analyse, and alert on logs from many sources

Provides advanced search, correlation, and machine learning for threats

Designed for long-term storage and compliance reporting

Commit to Panorama

Saves changes to the Panorama configuration locally

Does not affect firewalls immediately

Required before you can push to firewalls

Push to Device Group

Sends the committed configuration to all firewalls in a device group

Actively updates firewall policies and settings

Can be scheduled or performed immediately

Watch Out for These

Mistake

Panorama only works with Palo Alto Networks firewalls that are on the same network as the Panorama appliance.

Correct

Panorama can manage firewalls across different networks, including those in different geographical locations and cloud environments, as long as the firewalls can communicate with Panorama over the internet or a VPN.

Beginners often assume centralised management requires physical proximity, but Panorama uses encrypted tunnels (via IPsec) to manage firewalls anywhere.

Mistake

Log forwarding automatically sends all logs from all firewalls as soon as Panorama is connected.

Correct

Log forwarding is not automatic. You must explicitly create a Log Forwarding Profile and attach it to a security policy or the default policy. Without this configuration, logs stay on the firewall or in Panorama's local storage.

This mistake comes from thinking that 'centralised management' implies automatic log collection. In reality, log forwarding is a deliberate configuration step.

Mistake

If Panorama goes offline, the firewalls stop working and stop logging traffic.

Correct

Firewalls operate independently of Panorama. If Panorama is down, the firewalls continue to enforce the last pushed policies and generate logs locally. When Panorama comes back online, it can collect backlogged logs (if configured to do so).

Newcomers often confuse management and data plane. Panorama is a management tool; the firewalls themselves handle traffic and logging independently.

Mistake

Log forwarding and logging are the same thing.

Correct

Logging is the act of recording events on the firewall. Log forwarding is a separate process that sends copies of those logs to an external system. Logging always happens; forwarding is optional and configurable.

The terms sound similar, and beginners often use them interchangeably. The exam specifically tests the distinction between local storage and remote forwarding.

Mistake

You can forward logs from Panorama to a syslog server without needing to configure syslog on the firewalls themselves.

Correct

Log forwarding can be configured on Panorama centrally, and then pushed to firewalls as part of a policy. The actual forwarding of logs happens from the firewall to the external server, not from Panorama (though Panorama can also forward its own management logs).

The name 'Panorama log forwarding' leads people to think Panorama does the forwarding; in most cases, the firewall does the forwarding, and Panorama simply distributes the configuration.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

Does Panorama replace each firewall individually?

No. Panorama centralises management, but each firewall still processes traffic and enforces policies independently. If Panorama goes offline, the firewalls continue working.

Can Panorama manage firewalls in different cloud providers?

Yes. Panorama can manage firewalls deployed in AWS, Azure, Google Cloud, or on-premises, as long as they can communicate over the internet or a VPN.

What is the difference between a device group and a template in Panorama?

Device groups organise firewalls for shared security policies. Templates organise firewalls for shared network and device settings (like interfaces, routes, and NTP).

Do I need a separate Log Collector appliance?

Only if you generate a very high volume of logs (e.g., hundreds of gigabytes per day). For smaller deployments, Panorama's built-in log storage suffices.

Can I forward logs to more than one syslog server?

Yes. In a Log Forwarding Profile, you can configure multiple destinations with different log filters, sending different log types to different servers.

Will my firewalls stop logging if Panorama is down?

No. Firewalls continue to log locally to their own storage. If you configure Panorama to retrieve logs, it will fetch missing logs once connectivity is restored.

Terms Worth Knowing

Keep going

You've finished Device Management: Panorama Integration and Log Forwarding. Continue through the PCNSA study guide to build a complete picture of the exam.

Done with this chapter?