TTechclick All lessons
Palo Alto · Panorama · Centralised MgmtInteractive · L2 / L3

Panorama — The Config Hierarchy That Runs 300 Firewalls

Templates, template stacks, device groups, pre-rules, post-rules, commit-and-push, log collectors. The hierarchy looks intimidating until you see the override visualizer animate which level wins. 12 minutes, four sections, and you'll never push a wrong rule to the wrong device-group again.

📅 2026-05-25 · ⏱ 12 min · 2 hierarchy demos · 🏷 10-Q assessment + AI Tutor inline

Pick a Panorama topic — jump straight to it

1

Templates & Stacks

Network & device settings. Top-of-stack wins on duplicates. Up to 8 templates per stack.

 2

Device Groups

Hierarchical security policies. Pre-rules (enforced) + local + post-rules (cleanup).

 3

Commit & Push

"Out of sync" demystified. Selective push. Why one device fails while peers succeed.

 4

Log Collectors

M-600 vs Panorama-VM sizing. 489 bytes/log math. Why you need three for quorum.

Why Panorama exists — the 30-firewall problem

One firewall? CLI is fine. Five? You can still SSH them in parallel. Thirty firewalls across six branches with three admins making changes? You need a control plane that pushes one security policy to many devices, lets each device keep local overrides where required, and shows you a unified log view across all of it. That's Panorama.

Panorama splits config into two orthogonal trees. Templates hold per-device settings — interfaces, zones, virtual routers, NTP, DNS, syslog destinations. Device Groups hold security objects — addresses, services, security rules, NAT rules, decryption profiles. Each managed firewall lives in exactly one template stack and exactly one device group leaf. Mix and match the two trees to get the right config on each firewall.

🧱
Template
tap to flip

Per-device settings: interfaces, zones, VRs, NTP, DNS, GP cert, syslog dest. Mix multiple templates into a stack to compose the final config.

📚
Template Stack
tap

Ordered list of templates (up to 8). Top template wins on duplicates. PAN-OS 9+ requires firewalls to be assigned to a stack, never a raw template.

🌳
Device Group
tap

Security objects + rules. Hierarchical (Shared → parent → child). Child inherits from parent unless overridden. One firewall = one leaf device group.

⚙️
Log Collector
tap

Dedicated log-receiver. M-600 hardware OR Panorama-VM in collector mode. Min 3 per group for quorum, <10ms latency between collectors.

① Templates & Template Stacks — top of stack wins

Priya at HCL has 12 branch firewalls. They share NTP, DNS, syslog (global settings) but each has a unique management IP, hostname, and BGP local-AS. She builds:

Stack order: fw-mumbai-01 → branch-india → global-base. Top of stack wins. So when she changes the NTP server in global-base, all 12 firewalls inherit. But fw-mumbai-01's unique BGP AS overrides anything below.

▶ Watch a setting flow through the template stack

Click Play. See how PAN-OS resolves "what NTP server does fw-mumbai-01 actually use?"

① QUESTION What NTP server does fw-mumbai-01 use? Check the stack order top-to-bottom.
▼
② TOP fw-mumbai-01 template — only sets ethernet1/1 IP + BGP AS. No NTP setting. Continue.
▼
③ MIDDLE branch-india template — defines timezone. No NTP setting. Continue.
▼
④ BOTTOM global-base template — NTP = time.cloudflare.com. First match wins.
▼
⑤ RESULT Pushed to fw-mumbai-01: NTP = time.cloudflare.com. From the global template, inherited cleanly.
▼
⑥ OVERRIDE If Priya later sets NTP in branch-india to a local server, branch-india wins (it's above global-base). global-base value is ignored for this stack.
Press Play. Each press of Next advances one stage in the override resolution.
Three template design patterns that scale

1. Keep a global-base template that all firewalls inherit (logging, NTP, DNS, admin roles). 2. Add a per-region template (timezone, region-specific log servers). 3. Use template variables for firewall-unique values (BGP AS, mgmt IP, GP gateway public IP) — one template, many firewalls, each gets its own variable substitution. Variables are the single biggest lever for keeping the template count low.

Quick check · Q1 of 10

Sneha at Infosys has a template stack ordered top-to-bottom: region-apac → global-base. Both templates define idle-timeout = 30 min in global-base and idle-timeout = 10 min in region-apac. Which value does the managed firewall actually use?

Correct: b. Template stack evaluation is top-down — the template highest in the stack list wins for any duplicate setting. Panorama doesn't fail on conflicts; it resolves them by priority. Knowing this lets you keep a permissive global default and tighten with regional overrides.

② Device Groups — pre-rules, local, post-rules

Device-group hierarchy mirrors org structure. Common Indian-IT pattern: Shared → corp → corp/india → corp/india/branches → fw-mumbai-01. Security rules can live at every level. When the firewall evaluates a packet, it walks the rules in this order:

  1. Shared pre-rules — enforced enterprise-wide bans (block known-bad TI feeds).
  2. Device-group pre-rules (root → leaf) — region/branch-level enforced rules.
  3. Local rules — rules defined on the firewall itself (rare in Panorama deployments).
  4. Device-group post-rules (leaf → root) — cleanup / fallback rules.
  5. Shared post-rules — last-stop catch-alls (log all → deny).

Pre-rules are evaluated FIRST. Use them for things admins must never bypass — Threat Intelligence blocks, executive-VIP-only carve-outs, breakglass deny rules. Post-rules are evaluated LAST. Use them for logging cleanup, "deny all and log" rules at the tail of the policy.

①
Pre-rules
tap

Top of policy. Inheritance Shared → root → leaf DG. Use for non-negotiable blocks (TI feeds, sanctioned-country deny).

②
Local rules
tap

Device-local, defined directly on the firewall. Rare in Panorama deployments — most shops keep all rules central for audit.

③
Post-rules
tap

Bottom of policy. Leaf → root order. Use for cleanup ("deny-all-log"), default-allow templates, and audit-trail catch-alls.

④
Inheritance
tap

Child device-group inherits rules + objects from parent automatically. Override at child level only when you must — keep the tree shallow.

The "where did this rule come from?" trap

When a packet hits a Panorama-managed firewall, the actual rulebase on the device is: Shared pre → DG-root pre → DG-leaf pre → Local → DG-leaf post → DG-root post → Shared post → interzone-default. Local admins see only their level. If a packet is allowed and you don't know why, the rule might be a Shared pre-rule defined three levels up — invisible from the device GUI. Always log into Panorama for the truth, not the firewall.

Quick check · Q2 of 10

Rahul at TCS wants ALL firewalls in the enterprise to drop traffic to known-bad threat-intel feed IPs, with no local admin able to override. Where should the rule live?

Correct: c. Shared pre-rules sit at the very top of the rulebase and inherit to every managed firewall. Combined with Panorama-side RBAC (no admin can edit Shared), the rule is uniformly enforced. Post-rules wouldn't work — local rules could match first and allow the traffic. Local rules can be edited per firewall, breaking uniformity.

③ Commit & Push — the "out of sync" puzzle

Karthik at Flipkart edits a Panorama device-group, hits Commit to Panorama. It succeeds. He sees a yellow badge on the device summary: Out of sync. Doesn't every commit propagate automatically?

No — Panorama uses a two-step commit model. Commit to Panorama saves the change to Panorama's own running config but doesn't ship it to the devices. Push to Devices ships the device-group / template-stack config to managed firewalls. If you only commit, devices stay out of sync. If you only push without committing, you push the old running config.

▶ The commit-and-push flow — and why one device fails

Same Symptom → Counter → CLI → Fix pattern as Blog 18.

① EDIT Karthik edits security rule "allow-finance-saas" in DG corp/india/branches.
▼
② COMMIT Hits Commit to Panorama → saved to Panorama's running config. Devices: Out of sync (yellow).
▼
③ PUSH Hits Push to Devices, selects DG + template-stack scope. Panorama begins commit-and-push job on each device.
▼
④ STATUS 10 of 12 devices: commit successful, in sync. 2 devices: commit failed — invalid reference.
▼
⑤ ROOT CAUSE show jobs id <N> on the failed devices → the address object 'finance-saas-edges' references an address-group not yet pushed because of a parallel scope-mismatch.
▼
⑥ FIX Push the parent device-group first, then the leaf. Or fold the dependency into a single push scope. After full push, both devices: in sync.
Out-of-sync = "Panorama running config has changes the device hasn't received yet." Almost always a missing push or missing scope.
Use Selective Push for safety

For mature deployments, prefer Push Selective — push only your administrator scope (your changes), not the entire device-group config. Cuts blast radius. If three admins are working concurrently, your push won't drag in someone else's half-committed change. Available since PAN-OS 8.x, criminally underused.

Quick check · Q3 of 10

Aditya at Wipro pushes a Panorama config to 25 firewalls. 23 succeed, 2 fail with "address object 'web-tier' references missing address-group". The address-group exists in Panorama. What's the most likely cause?

Correct: d. Push scope must include all device-groups that contain referenced objects. If "web-tier" lives in DG-parent and the rule references it from DG-leaf, but the push scope only covered DG-leaf, the leaf device sees a dangling reference. Either widen the scope, push parent first, or move the object to Shared so it's always present.

④ Log Collectors — the 489-byte math

By default a managed firewall ships logs back to Panorama for indexing. At small scale (≤10 firewalls, ≤500 logs/sec) Panorama itself can absorb the flow. At enterprise scale, you off-load logging to dedicated Log Collectors (M-600 hardware or Panorama-VM in collector mode).

The arithmetic everyone needs to memorise: average PAN-OS log = 489 bytes. Multiply by your logs-per-second × seconds-in-day × retention-days × safety-factor → storage in GB.

Log storage estimator — 1,500 LPS, 30 days retention 
logs/day      = 1,500 × 86,400              = 129,600,000
bytes/day     = 129,600,000 × 489 B         = 63,374,400,000 B   (~59 GB/day)
30-day total  = ~59 GB × 30                 = ~1.77 TB
+ safety 25%  = 1.77 × 1.25                 = ~2.2 TB

Three Log Collectors per group is the magic number — Palo Alto requires three for quorum, and inter-collector latency must stay under 10 ms. Two collectors leaves you without quorum during one collector's outage; one collector means logging dies if it dies. Hardware-wise, the M-600 takes the bulk of large deployments; Panorama-VM works for small-to-mid sites if you give it ≥16 vCPU + 64 GB RAM + high-IOPS disk.

Quick check · Q4 of 10

Priya designs Panorama for an enterprise with 1,800 LPS across the fleet and 45 days log retention. Which Log Collector design is correct?

Correct: a. Three-collector quorum is a Palo Alto best-practice for ingestion resiliency. The math: 1,800 × 86,400 × 489 ÷ 1024³ × 45 × 1.25 ≈ 4.2 TB. Single-collector or two-collector designs have known failure modes during patching or hardware failure. SIEM-only off-load loses the ACC, log-correlation, and reporting that Panorama's collectors enable.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from PAN-OS docs + Live Community. For complex prod issues, paste your Panorama device-summary screenshot into chat.techclick.in.

📝 Wrap-up — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete.

Q5 · Apply

Per PAN-OS 9.x and later, what can a firewall be assigned to from Panorama?

Correct: b. Since PAN-OS 9.0, the firewall is always assigned to a template stack, never a raw template. A stack can hold up to 8 templates in priority order. Templates were not deprecated — they're the building blocks composed into stacks.
Q6 · Analyze

A managed firewall shows "Out of Sync (Device-Group)" but commits on Panorama are successful. What's the most likely cause?

Correct: c. Out-of-sync is the normal state between "Commit to Panorama" and "Push to Devices". Two-step model: commit saves to Panorama config, push ships to device. Common mistake: only commit and walk away. Note option b — Panorama running same/higher PAN-OS than managed devices IS a requirement; managed firewall ahead of Panorama causes commit failures, but the symptom would be a push error, not idle "out of sync".
Q7 · Analyze

A new admin needs to manage security rules for only the India branch firewalls, never touch HQ. Which Panorama feature scopes this cleanly?

Correct: d. Admin Role profile controls WHAT functional areas they can edit (security rules vs decryption vs PBF); Access Domain controls WHERE (which device groups / template stacks they can see). Combine the two for least-privilege RBAC. Superuser is the opposite of least-privilege; shared creds break audit; local-only admin breaks central policy management.
Q8 · Analyze

A device-group tree is 7 levels deep (Shared → continent → country → state → city → site → fw-leaf). Admins complain that finding the right level to edit takes longer than the change itself. Best refactor?

Correct: a. The PAN best-practice doc recommends device-group hierarchies stay shallow (2-3 functional/regional tiers). Deeper trees increase commit time and confuse admins about where rules live, without proportional benefit. Most isolation goals (per-team scope) are solved by Access Domains + naming convention, not by deepening the tree.
Q9 · Evaluate

A Log Collector group has 4 collectors. Inter-collector latency between two pairs is 35 ms (across a WAN link). What's the operational impact?

Correct: b. Palo Alto's docs are explicit: members of the same Collector Group need <10 ms RTT. WAN-stretched collector groups will exhibit unstable sync, replication, and query behavior. The correct design is per-location collector groups, with Panorama as the federated query plane (it can read from multiple collector groups when running reports).
Q10 · Evaluate

A junior admin proposes: "since templates and device-groups are separate, let's merge them into one tree using only device-groups and disable templates." Sound?

Correct: c. Panorama's two-tree design (templates for device/network config, device-groups for security) is intentional and PCNSE-foundational. They aren't redundant — they solve different problems. Education the junior, don't merge.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto Docs — Templates and Template Stacks (Panorama 11.1). docs.paloaltonetworks.com
  2. Palo Alto Best Practices — Manage Your Device Group Configurations on Panorama (10.1). docs.paloaltonetworks.com
  3. Palo Alto Docs — Push Selective Configuration Changes to Managed Devices (Panorama 11.0).
  4. Palo Alto LIVECommunity — Best Practices for Configuration Management Performance on Panorama (article 1223863) & Reason for out-of-sync message in Panorama (thread 328292).
  5. Palo Alto Docs — Determine Panorama Log Storage Requirements & Panorama Sizing and Design Guide.
  6. Palo Alto LIVECommunity — Best Practices with Log Collection Design in Panorama (article 1228363).
  7. Palo Alto Docs — Role-Based Access Control / Administrative Roles (Panorama 10.1 - 11.0).

What's next?

Panorama gives you the control plane. Next we tackle PAN-OS upgrades and content updates — the operation most likely to break production if you skip steps.

Blog 20 · PAN-OS Upgrades → ← Recap Operational Failures