Index › Firewall Fundamentals & Admin
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Firewall Fundamentals & Admin

← Back to full guide index

~5 min read
Prerequisites: Policy & Segmentation — admin/interface fundamentals underpin how you'll actually configure the policies covered earlier.

Connecting & Managing a Firewall 11

PAN-OS course · Connecting to a Firewall / Managing Firewall Configurations

Learning objectives

  • Identify the management interfaces (Web UI, CLI, XML API, Panorama) and how each is used
  • Explain candidate vs. running configuration and the commit workflow
  • Describe how to filter, preview, and validate a commit before activating it

Every configuration change on PAN-OS goes through a staging step before it takes effect — understanding that workflow is the first practical skill in running a firewall, before you ever touch a security rule.

Why

A firewall is a live choke point; pushing every keystroke straight to the running network would be dangerous. PAN-OS separates "what you're editing" from "what's actually enforcing traffic" so mistakes can be caught before they go live.

How

Admins reach the firewall via the Web Interface (HTTPS, the primary GUI), the CLI (SSH/console, operational vs. configure modes), the XML API (HTTP/HTTPS for automation/integration), or Panorama (centralized, fleet-wide). Every edit lands in the candidate configuration — a working draft — and has no effect on traffic until you Commit. Commit lets you Validate (syntax/semantic check, no traffic impact), Preview (color-coded diff against the running config), or Commit for real; you can scope a commit to your own changes or another admin's, and by location (shared objects, a specific vsys, device/network settings). Commits queue if one is already in progress, and the Task Manager lets you track or cancel pending ones.
Admin edits land in the candidate configuration, then Validate, Preview, or Commit — only Commit pushes changes into the live running configuration.
Admin edits land in the candidate configuration, then Validate, Preview, or Commit — only Commit pushes changes into the live running configuration.

Pros

  • Candidate/running separation lets you stage and review large rule changes safely
  • Validate-before-commit catches syntax and dependency errors with zero traffic risk
  • Partial/filtered commits let multiple admins work concurrently without stepping on each other

Cons

  • Partial commits have hidden dependencies — editing an object someone else changed can force their change into your commit
  • A large uncommitted candidate config can drift far from what's actually running, confusing troubleshooting
  • Never exposing the management interface to untrusted zones is a discipline, not a default — it must be enforced deliberately

Exam Trap

A candidate config edit does not affect traffic until commit — questions love to describe a change "made" in the Web UI and ask whether it's enforced yet. It isn't, until Commit completes. Also remember Validate performs a full syntax/dependency check with zero traffic impact — it is not the same as Preview, which only shows a diff.

Self-check: Connecting & Managing a Firewall
Q1. An admin edits a NAT rule in the Web UI, closes the browser tab without committing, and traffic keeps flowing on the old rule. Why?
A: The edit only ever lands in the candidate configuration. Nothing changes what's enforcing traffic until an explicit Commit runs — closing the tab doesn't commit or discard it, the candidate config persists on the firewall.
Q2. Two admins are editing different address objects at the same time. Admin A commits with a "commit changes made by: Admin A" scope. Could Admin B's uncommitted edits still end up in that commit?
A: Yes — if Admin A's change depends on an object Admin B also modified, PAN-OS pulls that dependency in to keep the config consistent, even though the commit was scoped to Admin A. Partial commits don't guarantee full isolation between admins.

Source: pan-os/10-2/pan-os-admin/firewall-administration/management-interfaces; ngfw/help/10-1/web-interface-basics/commit-changes

Admin Accounts & Role-Based Access 12

PAN-OS course · Local & Non-Local Firewall Admin Accounts

Learning objectives

  • Distinguish local from externally-authenticated admin accounts
  • Explain the built-in Dynamic roles vs. custom Role Based admin profiles
  • Describe why every admin should get their own account instead of sharing "admin"

Every firewall ships with a default admin superuser account — real deployments replace shared use of that account with individually-attributable, least-privilege admin accounts.

Why

Shared credentials make it impossible to know who made a change, and a superuser account handed to every operator violates least-privilege. Separate, scoped accounts protect the firewall from accidental or malicious misconfiguration and make every change individually auditable.

How

Local accounts live entirely on the firewall (username/password, SSH keys, or client certificates), with role assignment done locally — no access-domain support. Non-local (external) accounts reference or are fully defined on an external server: local accounts can point at an external MFA/SAML/ Kerberos/TACACS+/RADIUS/LDAP service for authentication only (roles stay local), or SAML/TACACS+/RADIUS can own both authentication and authorization via Vendor-Specific Attributes/SAML attributes mapped to roles, access domains, and vsys. Roles themselves are either Dynamic (built-in: Superuser, Superuser read-only, Device administrator, Device administrator read-only, Virtual system administrator, and its read-only variant — auto-updated whenever new features ship) or Role Based (custom Admin Role profiles scoped to exactly the web UI/CLI/XML API areas a job function needs, which you must remember to update as new features are added).
Local and external admin accounts mapping through Dynamic and Role Based roles to firewall access.
Local and external admin accounts mapping through Dynamic and Role Based roles to firewall access.

Pros

  • Custom Role Based profiles give fine-grained, job-function-scoped access instead of all-or-nothing
  • External-authorization mode (SAML/TACACS+/RADIUS VSAs) centralizes admin RBAC alongside your existing identity stack
  • Dynamic roles need zero maintenance as PAN-OS adds features

Cons

  • Custom Role Based profiles do not auto-inherit access to new features — an admin can silently lose visibility into something new after an upgrade
  • Access domains aren't supported for pure-local accounts, limiting granularity on multi-vsys boxes without external auth
  • A Virtual system administrator role can't touch shared network objects (interfaces, VLANs, virtual routers, IPSec/GRE tunnels, DHCP, DNS proxy, QoS) — a common source of "why can't I configure this" tickets

Exam Trap

Dynamic roles auto-update with new PAN-OS features; custom Role Based profiles do not — an exam question describing an admin who "lost access" to a brand-new feature right after an upgrade is testing whether you know Role Based profiles need manual review post-upgrade. Also: a Virtual system administrator cannot touch shared/global network objects (interfaces, virtual routers, IPSec/GRE tunnels, DHCP, DNS proxy, QoS) — those are device-level, not vsys-level.

Self-check: Admin Accounts & Role-Based Access
Q1. After a PAN-OS upgrade adds a new feature, a custom Role Based admin can no longer see it in the Web UI, while a Superuser can. What's the fix?
A: Custom Admin Role profiles don't automatically inherit access to new features — an admin has to manually edit that Role profile to grant visibility into the new feature area. Dynamic roles like Superuser wouldn't need this since they're built-in and auto-updated.
Q2. A Virtual system administrator complains they can't edit a VLAN interface used by their vsys. Is this a permissions bug?
A: No — it's expected behavior. Shared network objects (interfaces, VLANs, virtual routers, IPSec/GRE tunnels, DHCP, DNS proxy, QoS) sit outside any single vsys's scope, so the Virtual system administrator role structurally cannot touch them regardless of how it's configured.

Source: ngfw/administration/firewall-administration/manage-firewall-administrators; ngfw/administration/firewall-administration/manage-firewall-administrators/administrative-authentication

Network Interfaces Deep Dive 13

PAN-OS course · Security Zones and Network Interfaces

Learning objectives

  • List the physical and logical interface types PAN-OS supports
  • Explain when to choose tap, virtual wire, Layer 2, or Layer 3 mode
  • Connect interface mode to how zones and security policy get built on top of it

Security Policy is built on zones, and zones are built on interfaces — the physical/logical mode you pick for an interface determines what kind of network design and policy you can express on top of it.

Why

Not every rollout looks the same: a POC or IDS-style deployment needs to see traffic without touching it, a bump-in-the-wire migration needs to stay invisible to routing, and a full gateway deployment needs to actually route. One firewall needs to support all of these modes, often simultaneously on different interfaces.

How

Physical Ethernet interfaces can be set to Tap (passive copy off a SPAN/mirror port, zero traffic impact, monitoring only), Virtual Wire (two interfaces bound transparently, no IP/routing changes needed — easiest drop-in insertion), Layer 2 (switches VLANs between interfaces), Layer 3 (routes IP traffic, the interface has its own IP — most common for real gateway deployments), HA, log card, and decrypt mirror (feeds decrypted copies to external DLP/forensics tools); Aggregate Ethernet bundles physical interfaces for throughput/redundancy. Logical interfaces — VLAN, loopback, tunnel, SD-WAN — sit on top of a physical interface and must be defined after it. Different interfaces on the same box can run different modes at once, letting one firewall serve tap-monitoring on one segment and full L3 gateway duty on another.
Tap, Virtual Wire, Layer 2, and Layer 3 interface modes compared, showing which are passive versus inline-enforcing.
Tap, Virtual Wire, Layer 2, and Layer 3 interface modes compared, showing which are passive versus inline-enforcing.

Pros

  • Virtual wire mode lets you insert the firewall for a POC or migration with zero re-addressing
  • Tap mode gives risk-free "what would this block" visibility before any enforcement
  • Mixed-mode interfaces on one box support gradual, segment-by-segment rollout

Cons

  • Tap and mirror modes don't enforce anything — they inform, they don't protect, until you switch to inline
  • Available interface types and speeds vary by hardware model, complicating like-for-like migrations
  • Getting virtual wire, L2, and L3 zones mixed up on the same box is a common source of "traffic just disappears" tickets

Exam Trap

Tap and Virtual Wire mode look similar ("no re-addressing needed") but behave very differently: Tap is purely passive (off a mirror port, cannot enforce/block anything), while Virtual Wire sits inline and can enforce policy. Don't confuse "no IP changes" with "no enforcement."

Self-check: Network Interfaces Deep Dive
Q1. A customer wants to evaluate the firewall's Threat Prevention detections against live traffic for two weeks without any risk of blocking legitimate business traffic if a signature misfires. Which interface mode fits, and why not Virtual Wire?
A: Tap mode — it receives a passive copy of traffic off a SPAN/mirror port and can never block anything, making it zero-risk for a POC. Virtual Wire is inline, so a misconfigured or overly aggressive security profile there could actually drop production traffic.
Q2. Can a single firewall run Tap mode on one pair of interfaces and Layer 3 mode on another pair at the same time?
A: Yes — interface mode is set per physical interface, not globally for the box, so one firewall can serve tap-based monitoring on one segment while acting as a full L3 gateway on another.

Source: ngfw/help/11-1/network/network-interfaces/firewall-interfaces-overview

Module Quiz

1. An administrator edits a NAT rule in the Web UI and immediately asks a colleague, logged into another admin session, to check whether the new rule is enforcing yet. The colleague reports traffic is still hitting the old rule. What is the most likely explanation?

Every edit lands in the candidate configuration first. Nothing is enforced, and no other session sees it as active, until an explicit Commit completes.

2. Before pushing a large rule-base change, an engineer wants to confirm the candidate configuration is syntactically and semantically valid without generating a diff view or affecting traffic in any way. Which commit-related action should they run?

Validate runs the full syntax/dependency check with zero traffic impact and no diff output. Preview Changes shows the color-coded diff against the running config; it does not validate the config for errors.

3. An organization wants to integrate its ticketing system so that approved change requests automatically generate and push firewall configuration changes without any operator opening the Web UI. Which management interface should the integration target?

The XML API is designed for HTTP/HTTPS-based automation and third-party integration; the Web UI and interactive CLI assume a human operator.

4. Admin A runs a commit scoped to "commit changes made by: Admin A" only. The commit unexpectedly includes an address object that Admin B had separately edited but not yet committed. Why did this happen?

Filtered/partial commits must still produce an internally consistent configuration, so a dependency owned by another admin's uncommitted edit can be pulled into someone else's scoped commit.

5. A security team wants an admin role that is guaranteed to gain visibility into every new PAN-OS feature automatically after each upgrade, with no manual profile maintenance required. Which role type meets this requirement?

Dynamic roles are built into PAN-OS and are automatically updated as new feature areas ship; custom Role Based profiles must be manually revised after every upgrade that adds a new area.

6. A company wants a single external system to control both which administrators can log in AND which role, access domain, and vsys each one is assigned — with no per-admin role configuration stored locally on the firewall. Which setup achieves this?

Only SAML/TACACS+/RADIUS operating in combined authentication-and-authorization mode push role, access-domain, and vsys assignment from the external system; pointing a local account at an external service for authentication only still keeps role assignment local.

7. Which two firewall objects are considered shared, device-level resources that a Virtual System administrator role cannot configure, regardless of which vsys they are assigned to? (Choose two.)

Interfaces and virtual routers (along with VLANs, IPSec/GRE tunnels, DHCP, DNS proxy, and QoS) are shared network-level objects that sit outside any single vsys's scope. Security rules and objects scoped to a vsys remain configurable by that vsys's administrator.

8. An engineer needs to insert a firewall into an existing network segment for a two-week proof of concept, enforcing Security policy on real traffic, but the customer will not permit any change to IP addressing or the existing routing design. Which interface mode satisfies both requirements?

Virtual Wire binds two interfaces transparently with no IP or routing changes required, and unlike Tap it sits inline, so it can actually enforce Security policy rather than only observe traffic.

9. Which of the following must be configured on top of an already-existing physical interface, rather than being a mode a physical interface itself is set to?

Tap, Virtual Wire, Layer 2, Layer 3, and Aggregate Ethernet are physical interface modes. VLAN, loopback, tunnel, and SD-WAN interfaces are logical interfaces that must be layered on top of an already-defined physical interface.
← Policy & SegmentationThreat & Content Services →