Jump to chapter (9)
What you will learn, the track map and the big picture
What you will learn in this module. This is the free "Start here" module of the Palo Alto Networks NGFW Engineer track. By the end you will be able to explain what makes a firewall next-generation, describe zones, App-ID and security policy in plain words, find your way around PAN-OS (candidate configuration, commit, CLI and GUI), read the first show commands, and plan how to practise for the NGFW Engineer exam in the labs. You will not configure a full firewall here. You will understand the ideas so the next modules feel familiar.
Prerequisites. CCNA-level networking: IP addressing and subnets, VLANs, static routing, TCP and UDP ports, ACLs and NAT. You do not need any firewall experience and you do not need to know any Palo Alto product.
Analogy: a smart reception desk
Picture an office building. An old-style security guard checks only the door number you walk through: "Floor 5 is allowed, floor 9 is not." That is a traditional port-based firewall. It looks at addresses and port numbers. The problem is that a visitor can walk through the allowed door and do something completely different inside.
A next-generation firewall (NGFW) is a smart reception desk. It asks who you are (user), what you are here to do (application), and it can look inside your bag (threat scanning). The door number still matters, but it is only one clue. Palo Alto Networks built its firewall around that idea, and PAN-OS is the operating system that runs it.
The firewall question moves from "which port?" to "which application, which user, which content?"
The five ideas this module builds
- Next-generation: what the three "-ID" technologies add on top of a stateful firewall (chapter 2).
- Zones: groups of interfaces that become the "from" and "to" of every rule (chapter 3).
- Policy and App-ID: how a rule is written and why rule order matters (chapter 4).
- PAN-OS organisation: planes, interfaces to manage the box, and the configuration tree (chapter 5).
- Candidate, commit, verify: the safe change workflow and the first show commands (chapters 6 to 8).
Where this module sits in the track
The track follows the shape of the NGFW Engineer exam: configuration and deployment, policy and threat features, then operations and troubleshooting. Always confirm the current domains and weights in the official exam guide from Palo Alto Networks, because they are updated. In this academy the order is: this module, then pan-setup (CLI, commit, interfaces, zones, virtual router), pan-policy (App-ID and rule order), pan-nat, pan-vlans (subinterfaces and deployment modes), routing, VPN, profiles, decryption, User-ID, high availability and Panorama.
Worked example. A user opens a video site on TCP port 443. A port-based firewall sees "TCP 443 allowed" and passes it. A NGFW identifies the application as, say, a video streaming service running inside TLS, and your policy may allow business web but block streaming for a specific group. The port never changed. The decision did.
About the labs. This module has no labs of its own. It explains the vocabulary. The command outputs you see in these chapters were captured from the NK-OS simulator, which mimics PAN-OS 11.1 behaviour but is an educational simulator, not Palo Alto software. Hands-on practice for the ideas here lives in the pan-setup labs (first commit, and a ticket where a DMZ interface is dead). Policy practice follows in pan-policy.
Common beginner mistake. Treating a Palo Alto firewall as "a Cisco ASA with a different CLI". The ideas that matter are different: policy is written between zones, rules name applications rather than only ports, and nothing you type takes effect until you commit.
Exam trap. Questions often hide the answer in one word: "application-default", "candidate", "zone". Learn the exact vocabulary now. It saves marks later.
The "we already allow 443" meeting
A company's old firewall allowed outbound port 443 to everyone. Security noticed a file-sharing tool tunnelling through that port and moving documents out. The network team said, "But 443 is allowed, that is how the web works." After moving to a NGFW, the same port stayed open for the web applications the business needed, while the unapproved file-sharing application was blocked by name.
Lesson: an open port is not the same as an approved application.
"In one sentence, what is a next-generation firewall?"
A stateful firewall that also identifies the application, the user and the content of traffic, independent of port number, so policy can be written about business intent instead of only IPs and ports. Mention App-ID, User-ID and Content-ID by name and say that policy is written between zones.
Key takeaways
- A NGFW decides using application, user and content, not only IP and port.
- PAN-OS is the operating system of Palo Alto Networks firewalls.
- Policy is written between zones; changes apply only after a commit.
- This module is vocabulary and orientation; labs start in pan-setup.
- Check the official exam guide for current domains and weights.
What makes a firewall next-generation
Start from what you know. In CCNA you met the ACL: permit or deny by source, destination, protocol and port. A stateful firewall improves on a plain ACL by remembering connections. When an inside host opens a connection, the firewall records it in a session table and automatically allows the reply, so you do not write a rule for the return traffic. That was a big step in the 1990s. Today it is the minimum.
The gap stateful firewalls left
Modern applications do not stay on their own ports. Web mail, video calls, file sharing, remote-access tools and software updates all run over TCP 443 or 80. A stateful firewall that sees "TCP 443" cannot tell a payroll web application from a tool that copies files to a personal account. Applications also change ports on purpose, which is why "block port X" no longer blocks a thing. Meanwhile attackers hide malware inside allowed web traffic, and IP addresses stopped identifying people because users roam between Wi-Fi, VPN and mobile.
The three "-ID" technologies
Palo Alto Networks defines a next-generation firewall by what it can identify and control. These are the names you must know for the exam:
- App-ID
- Identifies the application from the traffic itself using signatures, protocol decoders and heuristics, on any port, even when the application is wrapped in TLS (with decryption, deeper). Policy then says "allow ssh" or "block file-sharing", not "allow TCP 22".
- User-ID
- Maps an IP address to a user name and group, for example from directory login events. Policy can say "the finance group may use this application".
- Content-ID
- Inspects the content of allowed traffic: threat prevention (vulnerability exploits, malware, command-and-control), URL filtering, file blocking, data filtering and WildFire cloud analysis of unknown files.
Newer material also talks about Device-ID, which adds the type of device (laptop, printer, camera) as a policy match. Treat it as an extension of the same idea: more context, better decisions.
Single-pass parallel processing: networking, policy and all content checks happen in one pass over the stream.
Single-pass architecture
Older "UTM" products bolted features on one after another: firewall, then IPS, then antivirus, each with its own engine and its own scan of the packet. Palo Alto Networks describes a single-pass parallel processing design. The firewall does the networking and policy work once and the content engines scan the same stream together. The practical result for you: turning on more security profiles costs less performance than stacking separate boxes, and you manage everything in one policy.
Worked example. Priya in Finance opens a cloud storage site. The firewall sees TCP 443 to a public address. App-ID names the application. User-ID says the source IP belongs to priya in the Finance group. The rule "Finance may use approved-storage" matches, and a file-blocking profile stops executables from being downloaded. Four facts (zone, application, user, content) decided one session. A port-based rule could only use two of them.
Where it sits in your network
Most often the firewall is routed between the LAN, an internet link and a DMZ (a Layer 3 deployment, which you will configure in pan-setup). It can also run as a transparent virtual wire or a Layer 2 switch-like device, or as a passive tap that only watches. The deployment modes are the subject of the pan-vlans module.
Common mistake. Believing "next-generation" means "turn everything on". Features such as URL filtering, threat prevention and decryption are separate profiles that you attach to rules. A rule with no profile is just a smarter stateful rule. You will meet profiles in the pan-profiles module.
Exam trap. App-ID identifies the application, User-ID the user, Content-ID the threats and content. Candidates mix them up under pressure. Also remember that the port in a rule is only a check that the application is on its expected port when you use application-default.
Port 8080 is not a web server
An engineer wrote "allow TCP 8080 outbound" for a developer tool. Weeks later the log showed a remote-access application using the same port to reach the internet. With an application-based rule ("allow the specific developer tool, application-default"), the remote-access application would have been denied even on the allowed port.
Lesson: name the application you want, then let the port follow.
"How is App-ID different from just matching a port number?"
App-ID classifies traffic by what it is, using signatures, decoders and heuristics, regardless of port or evasive tunnelling, so policy can allow or block the application itself. A port number says only where traffic goes, not what it carries. Add that App-ID can re-classify a session as more data arrives, and that decryption improves visibility into TLS.
Key takeaways
- A stateful firewall tracks sessions; a NGFW also knows application, user and content.
- App-ID = application, User-ID = user and group, Content-ID = threats, URLs, files.
- Single-pass processing examines traffic once for networking and content together.
- Security profiles are attached to rules; they are not automatic.
- Deployment modes (Layer 3, virtual wire, Layer 2, tap) come later in pan-vlans.
Zones: the "from" and "to" of every rule
Analogy: rooms in a building. A bank has a public lobby, a staff area and a vault. Nobody writes rules for each door handle. They write rules between areas: "Staff may go from the lobby side to the staff area. Customers may not enter the vault." A PAN-OS security zone is exactly that: a named area of the network. You put interfaces into zones, and then you write policy between zones.
What a zone is
A zone is a logical group of one or more interfaces that share the same security level. Common names are trust (inside LAN), untrust (internet) and dmz (public servers). The names are only labels you choose. What matters:
- An interface can belong to only one zone. A zone can contain many interfaces.
- A zone has a type that matches how its interfaces are deployed: Layer 3, Layer 2, virtual wire, tap, or external. A Layer 3 interface goes into a Layer 3 zone.
- Traffic is described as from zone A to zone B. Every session has exactly one source zone and one destination zone.
- An interface with no zone passes no traffic. The firewall has no policy "place" for it.
Rules are written between zones, never directly between interfaces.
The two built-in default rules
Every PAN-OS firewall has two predefined rules at the very bottom of the security rulebase. You can see their effect even with an empty rulebase:
- intrazone-default: traffic that stays inside one zone is allowed.
- interzone-default: traffic that crosses between zones is denied.
So with no rules, hosts in the same zone talk freely and nothing crosses between zones. That is the "default deny between zones" posture. The simulator reproduces it:
admin@PA1> test security-policy-match from trust to trust source 10.0.1.10 destination 10.0.1.11 protocol 6 destination-port 80 No rule matched. Traffic falls to the predefined "intrazone-default" rule (action allow). admin@PA1> test security-policy-match from trust to untrust source 10.0.1.10 destination 8.8.8.8 protocol 6 destination-port 443 No rule matched. Traffic falls to the predefined "interzone-default" rule (action deny).
Note that the default deny does not log by default, which is why teams often add an explicit deny-all rule at the bottom with logging turned on. You will do that in pan-policy.
What an interface without a zone looks like
The show interface all command lists every logical interface with its zone and virtual router. Here is the DMZ interface right after an admin gave it an IP but forgot the zone and the router. This is the situation of the pan-setup troubleshooting lab:
name id vsys zone forwarding tag address
------------------- ----- ---- ---------------- ------------------------ ------ ------------------
ethernet1/1 16 1 untrust vr:default 0 203.0.113.2/30
ethernet1/2 17 1 trust vr:default 0 10.0.1.1/24
ethernet1/3 18 1 N/A N/A 0 10.0.2.1/24
Zone N/A and forwarding N/A mean no zone and no virtual router. The IP is configured, yet nothing works.
Worked example. A branch firewall has ethernet1/2 in trust, ethernet1/3 in dmz, ethernet1/1 in untrust. A PC at 10.0.1.10 opens a page on the DMZ server 10.0.2.10. The firewall decides the source zone is trust (the interface the packet arrived on) and the destination zone is dmz (the egress interface found by routing). It then looks for a rule "from trust to dmz". The zones come from the interfaces plus the routing table, never from the IP addresses written in the rule.
Common mistakes. Putting two unrelated networks in one zone because they "look similar" (the intrazone-default rule then allows them to talk). Forgetting that the destination zone is found by a route lookup, so a missing route can give a confusing zone or a drop. Using zone names that differ by one letter between interface and rule: the commit fails with an invalid reference.
Exam trap. Intrazone traffic is allowed by default, interzone traffic is denied by default. A second trap: the exam may call rules "zone-based" but ask which object a rule is written between. The answer is zones, not interfaces and not VLANs.
The contractor Wi-Fi that could reach the servers
A site put the contractor Wi-Fi VLAN and the server VLAN into the same internal zone to save time. Because intrazone traffic is allowed by default, contractor laptops could reach servers with no rule at all, and nothing showed in the deny logs. The fix was a separate contractors zone and an explicit rule allowing only the applications they needed.
Lesson: a zone is a trust boundary. Do not merge networks that should be separated.
"What happens to traffic between two interfaces in the same zone?"
It is allowed by the predefined intrazone-default rule, so it does not need a rule, unless you override that rule or add a deny rule. Traffic between different zones is denied by interzone-default until you allow it. Mention that you can change the default behaviour by overriding the predefined rules.
Key takeaways
- A zone is a named group of interfaces; an interface is in one zone only.
- Every session has a source zone and a destination zone.
- Intrazone-default allows; interzone-default denies.
- An interface with no zone shows N/A and passes nothing.
- The destination zone comes from the routing lookup.
App-ID and security policy in plain words
Analogy: a visitor form. At a reception desk you fill a form: where you come from, where you are going, who you meet, why you came. The guard reads the form from top to bottom and the first line that fits decides what happens. A PAN-OS security rule is that form, and the rulebase is the list of forms checked in order.
Anatomy of a security rule
A rule has match conditions and an action. The main match fields:
| Field | Meaning | Example |
|---|---|---|
| from / to | source zone and destination zone | from trust to untrust |
| source / destination | IP addresses or address objects (or any) | any |
| user | User-ID user or group (optional) | any |
| application | App-ID application names | dns, ssl, web-browsing |
| service | ports; application-default means the application's usual ports | application-default |
| action | allow, deny, drop, reset (client, server, both) | allow |
Here is a real rule from the simulator, shown the way PAN-OS prints the running policy:
admin@NK-PUNE-PA> show running security-policy
"Allow-Out; index: 1" {
from trust;
source any;
to untrust;
destination any;
user any;
category any;
application/service [ ping dns web-browsing ssl ]/application-default;
action allow;
icmp-unreachable: no
terminal yes;
}
Read it aloud: "From trust to untrust, from any source to any destination, for these four applications on their default ports, allow." Four applications cover a basic browsing user: ping for tests, dns to resolve names, web-browsing for clear web traffic and ssl for encrypted sessions that the firewall cannot name more specifically without decryption.
Rules are checked top to bottom, first match wins
The firewall evaluates the rulebase from the top. The first rule that matches the session decides everything, and checking stops. Later rules are not looked at. If no rule matches, the predefined intrazone or interzone default applies (previous chapter). This is why rule order is a classic exam topic: a broad allow above a narrow deny makes the deny useless. You will practise this in pan-policy.
Top to bottom; the first matching rule decides; the predefined defaults sit at the end.
App-ID and "application-default"
Each application in the App-ID database has default ports. For web-browsing it is TCP 80, for ssl it is TCP 443, for dns UDP and TCP 53. When the rule's service is application-default, the firewall allows the application only on its default ports. If someone runs web-browsing on TCP 8080, the session does not match that rule. This closes the old problem of "allow TCP 8080" being used for anything.
Other service choices exist: any (all ports, usually too wide), or a specific port or service object (for an application you really do run on a custom port). Prefer application-default, and when you must use a custom port, name it explicitly.
Testing before you trust
You can ask the firewall which rule a hypothetical session would hit, with no real traffic:
admin@NK-PUNE-PA> test security-policy-match from trust to untrust source 10.0.1.10 destination 8.8.8.8 protocol 6 destination-port 443
"Allow-Out; index: 1" {
from trust;
to untrust;
application/service [ ping dns web-browsing ssl ]/application-default;
action allow;
}
This test uses protocol and port, not an application. It is a quick sanity check that the right rule is selected.
Worked example. You want users in trust to browse the web and nothing else. Rule 1: from trust to untrust, applications dns web-browsing ssl, service application-default, action allow. A user's SSH session to a public server matches no rule, so the interzone-default denies it. You did not write a deny. The default did it, and the session never appears as allowed in the log.
Common mistakes. Using application any with service any "to get it working" and never tightening it. Forgetting that an application like ssl is a placeholder for encrypted traffic the firewall cannot decode, and that some websites need extra dependent applications to be allowed.
Exam trap. "Which service setting restricts an application to its standard ports?" Answer: application-default. "Which action silently discards and which sends a reset?" drop versus reset-client, reset-server, reset-both. Know that deny uses the application's default deny behaviour.
The admin exception that never matched
An admin group needed SSH to a server, so an engineer added "Allow-Admin-SSH" at the bottom of the rulebase. It never matched. A broad rule above it ("trust to dmz, application any, deny") matched first, so the admin rule below it was shadowed. Moving the specific rule above the broad one fixed it. (This is the pan-policy lab "The admin exception never matches".)
Lesson: specific rules go above general rules.
"What does application-default do in a Palo Alto security rule?"
It tells the firewall to permit the chosen applications only on their standard ports. Traffic of that application on a non-standard port does not match the rule. It is more secure than a hand-written port list because it ties port and application together, and you do not have to maintain the ports yourself.
Key takeaways
- A rule matches on zones, addresses, user, application and service, then applies an action.
- The rulebase is read top to bottom; the first match wins.
- application-default permits an application only on its standard ports.
- No match means the predefined intrazone or interzone default applies.
- test security-policy-match shows which rule a flow would hit.
How PAN-OS is organised: planes, interfaces and the config tree
Analogy: a restaurant. The manager's office (management plane) takes orders about how the restaurant should run. The kitchen manager (control plane) works out recipes and routes. The kitchen line (data plane) cooks and serves every plate at speed. If the manager is busy on the phone, the line keeps cooking. PAN-OS firewalls are built the same way.
Three planes
| Plane | Job | You see it as |
|---|---|---|
| Management plane | Configuration, logging, reporting, GUI, CLI, API, commit | the management interface and every admin session |
| Control plane | Routing protocols, ARP, session setup decisions | virtual router, routing table |
| Data plane | Moves and inspects packets; session lookup, App-ID, Content-ID, NAT | ethernet1/x interfaces |
Hardware models give each plane its own processors. Virtual models share resources but keep the same logical split. The consequence for your daily work: a heavy report or commit on the management plane does not stop forwarding, and a management interface is not a data interface.
Admins talk to the top; users' traffic runs through the bottom.
Ways to manage the firewall
- Web interface (GUI): tabs for Dashboard, ACC, Monitor, Policies, Objects, Network and Device. Reached with HTTPS on the management interface.
- CLI: over SSH or the console. Two modes: operational (prompt ends with
>) and configure (prompt ends with#). - XML API and REST API: for automation. The GUI and CLI both call the same configuration engine, so a change made in one is visible in the other after saving the candidate.
- Panorama: central management of many firewalls (a later module).
A new firewall's management interface usually starts at 192.168.1.1/24 with a default administrator account whose password you must change at first login. The management interface has its own default gateway and services. It is separate from the data-plane interfaces, which is why a plain ping host from the CLI leaves through management, not through ethernet1/1. The simulator shows this on its first lines:
admin@PA1> show system info
hostname: PA1
ip-address: 192.168.1.1
netmask: 255.255.255.0
default-gateway: 192.168.1.254
family: vm
model: PA-VM
sw-version: 11.1.4 (NK-OS educational simulator)
The configuration is a tree
PAN-OS stores configuration as a hierarchical tree (XML underneath). The main branches you will meet: deviceconfig (hostname, DNS, NTP, management settings), network (interfaces, virtual routers, profiles), zone, rulebase (security, NAT) and shared objects such as addresses. In configure mode the set command walks that tree:
# one line, one path through the tree
set deviceconfig system hostname NK-PUNE-PA
set network interface ethernet ethernet1/2 layer3 ip 10.0.1.1/24
set zone trust network layer3 ethernet1/2
Reading the running configuration shows the same tree, in braces by default or as set lines after set cli config-output-format set:
admin@PA1> set cli config-output-format set
admin@PA1> show config running
set deviceconfig system hostname PA1
set network virtual-router default
Even a factory-fresh firewall already has a default virtual router. It has no interfaces and no routes yet.
Worked example. You are asked to "add a DMZ". Mentally split the work by branch: network interface for the IP, network virtual-router for the router membership, zone for the zone, rulebase security for access. Four branches, one change. This habit keeps a build checklist-driven.
Common mistakes. Testing reachability from the CLI with a plain ping and concluding the data plane works (it used the management interface). Leaving the default administrator password. Allowing management services such as SSH or HTTPS on an internet-facing interface.
Exam trap. The management interface is separate from the data-plane interfaces and uses its own routing. Services such as ping, SSH and HTTPS on a data interface are controlled by an interface management profile, not by security policy.
Locked out by a successful commit
An engineer enabled a management profile with only SSH on the LAN interface and removed the profile that allowed HTTPS. The commit succeeded, but the next admin could no longer open the web interface from the LAN. The out-of-band management interface still worked and the profile was restored.
Lesson: keep an independent path to the management interface. Treat management profiles as security-sensitive changes.
"What are the three planes in a PAN-OS firewall?"
Management plane (configuration, logging, GUI, CLI, API), control plane (routing and session setup logic) and data plane (packet forwarding and inspection). Explain that they are separated so a busy admin task does not interrupt traffic, and that the management interface is separate from the data interfaces.
Key takeaways
- Management, control and data planes are separate by design.
- CLI has operational (>) and configure (#) modes; GUI and API use the same configuration.
- The management interface is not a data interface; default is 192.168.1.1.
- Configuration is a tree: deviceconfig, network, zone, rulebase.
- Services on data interfaces come from interface management profiles.
Candidate configuration, commit and validation
Analogy: a draft and a publish button. If you used the Junos or "document with a Publish button" idea earlier in the academy, you already know it. PAN-OS keeps two copies of the configuration. The running configuration is what the firewall enforces now. The candidate configuration is your working draft. Every set or delete changes only the candidate. Nothing touches traffic until you commit.
Edit the candidate; commit validates and applies it; revert config throws the draft away.
Seeing the difference
From operational mode you can print either copy. Here the hostname was changed in the candidate but not committed (output in set format):
admin@PA1> show config candidate set deviceconfig system hostname NK-PUNE-PA set network virtual-router default admin@PA1> show config running set deviceconfig system hostname PA1 set network virtual-router default
The firewall is still called PA1 on the wire and in its prompt. The candidate already says NK-PUNE-PA. Inside configure mode, show prints the candidate.
Commit validates the whole candidate
A commit is an all-or-nothing job. First PAN-OS validates the candidate. If anything is invalid, nothing is applied. This simulator capture shows a rule that names a zone with a typo, and a zone that refers to an interface that is not configured as Layer 3:
admin@PA1# set zone trust network layer3 ethernet1/2
admin@PA1# set rulebase security rules Allow-Out from trustt to untrust application any action allow
admin@PA1# commit
Validation Error:
zone -> trust -> network -> layer3 'ethernet1/2' is not a valid reference
rulebase -> security -> rules -> Allow-Out source is missing
rulebase -> security -> rules -> Allow-Out destination is missing
rulebase -> security -> rules -> Allow-Out service is missing
rulebase -> security -> rules -> Allow-Out from 'trustt' is not a valid reference
rulebase -> security -> rules -> Allow-Out to 'untrust' is not a valid reference
Commit failed
Read it as a to-do list. Each line is a path in the tree and a reason. Required fields (source, destination, service) were missing, trustt is a misspelt zone, and the zones do not exist yet. Fix the candidate and commit again. The running configuration was never touched.
A successful commit is a job
admin@PA1# commit
Commit job 3 is in progress. Use Ctrl+C to return to command prompt
......55%......75%.....98%.......100%
Configuration committed successfully
admin@PA1> show jobs all
Enqueued Dequeued ID Type Status Result Completed
-----------------------------------------------------------------------------------------------
2026-10-02 03:43:46 2026-10-02 03:43:46 3 Commit FIN OK 2026-10-02 03:43:46
Every commit has a job ID. show jobs all lists them with status (FIN = finished) and result (OK or FAIL). On a real firewall the commit also compiles the policy for the data plane, which is why a large rulebase takes longer.
Undoing, and what the simulator does not have
To throw away uncommitted edits, use revert config in configure mode. The simulator replies "Candidate configuration reverted to the running configuration". Real PAN-OS also offers: save config to a named snapshot, load config from a snapshot or an earlier version, validate full (check without applying), commit force, a commit lock so two admins do not collide, and a configuration audit that compares versions. These real commands are not implemented in the simulator, so practise the core flow here and learn the extras from the product documentation.
Worked example. At 10:00 you add a DMZ interface and a rule. At 10:05 a colleague also edits the candidate and commits. On a real firewall a plain commit applies all pending candidate changes of all admins unless you use a partial commit by admin. This is why teams use commit locks and change windows. Always review what is pending before you press commit.
Common mistakes. Typing set commands and forgetting to commit, then wondering why the network did not change. Committing with someone else's half-finished edits in the candidate. Assuming a failed commit applied part of the change: it applied none.
Exam trap. "Which configuration does the firewall enforce?" Running. "Where do set commands write?" Candidate. "What happens if the candidate has one invalid reference?" The whole commit fails.
The rule that only worked after lunch
An engineer added a rule at 11:50 and tested at 12:10 with no effect. He had not committed. A colleague, who needed an unrelated change, committed at 13:30 and the rule suddenly went live, also publishing the half-tested rule to the whole company. After that the team adopted commit locks and a rule: commit your own work, immediately, and read the pending changes first.
Lesson: the candidate is shared between admins, and commit is a deliberate act.
"Explain candidate versus running configuration and what a commit does."
Running is what the firewall enforces; candidate is the editable draft. A commit validates the candidate as a whole and, if valid, makes it the running configuration; if anything is invalid it fails and changes nothing. Mention commit jobs, locks and partial commits, and that Panorama pushes configuration to firewalls with its own commit and push.
Key takeaways
- set and delete change the candidate only; commit makes it running.
- Validation is all or nothing; read the error list line by line.
- show jobs all lists commit jobs and their results.
- revert config discards uncommitted edits.
- Review pending changes and use locks when several admins share a firewall.
Your first firewall: interface, zone, router and route
Analogy: opening a shop. A shop needs a street address (IP address), a licence to trade in a district (zone), a postal service (virtual router), and a signboard that directs customers (route). Miss one and the shop exists but has no business. A PAN-OS Layer 3 interface works the same way.
The four things every routed interface needs
- An IP address on the interface (
layer3 ip). - Membership in a virtual router, the routing table that the interface belongs to.
- Membership in a zone, so policy can refer to it.
- A route to anywhere that is not directly connected, usually a default route to the ISP.
Then, optionally, an interface management profile if the firewall itself should answer ping, SSH or HTTPS on that interface. The full treatment is the pan-setup module and its labs. Here is the shape of it, using the lab topology: PC1 in the Pune LAN (10.0.1.0/24) on ethernet1/2, an ISP on ethernet1/1 (203.0.113.0/30), and the firewall at 10.0.1.1 and 203.0.113.2.
Two interfaces, two zones, one virtual router, one default route.
Configuration (reference build, as in the pan-setup lab)
# interface IPs set network interface ethernet ethernet1/2 layer3 ip 10.0.1.1/24 set network interface ethernet ethernet1/1 layer3 ip 203.0.113.2/30 # management profiles: what the firewall itself answers set network profiles interface-management-profile allow-ping ping yes set network profiles interface-management-profile mgmt-lan ping yes https yes ssh yes set network interface ethernet ethernet1/2 layer3 interface-management-profile mgmt-lan set network interface ethernet ethernet1/1 layer3 interface-management-profile allow-ping # router membership and zones set network virtual-router default interface [ ethernet1/1 ethernet1/2 ] set zone trust network layer3 ethernet1/2 set zone untrust network layer3 ethernet1/1 # default route to the ISP set network virtual-router default routing-table ip static-route default destination 0.0.0.0/0 nexthop ip-address 203.0.113.1 interface ethernet1/1 commit
Watch the symptoms change as you add each piece
This is one of the best ways to learn. PC1 pings the firewall's LAN address at each stage. Captured from the simulator:
Stage 0: factory default, no IP on ethernet1/2 PC1> ping 10.0.1.1 host (10.0.1.1) not reachable Stage 1: IP, virtual router and zone configured and committed, but no management profile PC1> ping 10.0.1.1 10.0.1.1 icmp_seq=1 timeout Stage 2: profile mgmt-lan (ping yes) attached to ethernet1/2 PC1> ping 10.0.1.1 84 bytes from 10.0.1.1 icmp_seq=1 ttl=64 time=0.500 ms
"Not reachable" means PC1 could not even resolve the gateway (nothing owns 10.0.1.1 yet). "Timeout" means the packet reached the firewall and was ignored: the interface exists but the firewall's own services are not allowed there. Replies appear only after the profile. Different symptoms point to different missing pieces.
Verify the final logical interface table:
admin@NK-PUNE-PA> show interface all name id vsys zone forwarding tag address ------------------- ----- ---- ---------------- ------------------------ ------ ------------------ ethernet1/2 16 1 trust vr:default 0 10.0.1.1/24 ethernet1/1 17 1 untrust vr:default 0 203.0.113.2/30
Each row shows the zone and the virtual router (vr:default). The same IP table with both columns filled is your "interface is complete" check.
Worked example. PC1 can reach 10.0.1.1 but not 8.8.8.8. The interface table is fine. The next suspect is the route and then the policy and NAT. You move from "can the firewall be reached" to "can traffic pass through": two different questions with different tools. The next chapter walks through them.
Common mistakes. Adding the IP and zone but forgetting the virtual router. Adding the interface to the virtual router but forgetting the zone. Allowing HTTPS management on the untrust interface. Using a netmask in the wrong notation: PAN-OS takes CIDR, for example 10.0.1.1/24.
Exam trap. A route to the Internet is configured in the virtual router, and an interface that is in no virtual router cannot route at all. A security zone is not the same thing as a virtual router.
The DMZ server that could not ping its own gateway
After a change, the DMZ web server 10.0.2.10 could not even ping its gateway 10.0.2.1, although the admin insisted "the IP is configured and committed". The interface table showed zone N/A and forwarding N/A on ethernet1/3: no zone, no virtual router, no management profile. One more commit with those three items fixed it. This is the second pan-setup lab.
Lesson: an IP address alone does not make an interface work.
"You configured an IP on a new interface and cannot ping it. What do you check?"
That the interface is up, that it is in a virtual router and a zone (show interface all), and that an interface management profile with ping is attached, because a data interface does not answer ping by default. Then confirm the commit actually succeeded.
Key takeaways
- A routed interface needs IP, virtual router, zone and a route to be useful.
- Management profiles decide what the firewall itself answers on that interface.
- show interface all shows zone and virtual router side by side; N/A means missing.
- "Not reachable" and "timeout" point to different missing pieces.
- Build in order and verify after each commit.
Reading the box: verify and troubleshoot a first firewall
Analogy: a doctor's checklist. A doctor does not guess. She checks pulse, then temperature, then asks questions, always in the same order. Firewall troubleshooting works best the same way: a fixed sequence of cheap checks from the bottom of the stack to the top. You can run the whole sequence in under two minutes once it is a habit.
The five-step verification flow
- Interfaces: are they up, in a zone and in a virtual router? (
show interface all) - Routing: is there a route for the destination, and which interface does it use? (
show routing route) - Policy: which rule would this flow hit? (
test security-policy-match ...) - NAT: does outbound traffic get translated? (
show running nat-policy) - Sessions and logs: did the traffic arrive, and what did the firewall do? (
show session all,show log traffic)
Always the same order: interface, route, policy, NAT, then session and log.
Step 2: the routing table
admin@NK-PUNE-PA> show routing route VIRTUAL ROUTER: default (id 1) destination nexthop metric flags interface 0.0.0.0/0 203.0.113.1 10 A S ethernet1/1 10.0.1.0/24 10.0.1.1 0 A C ethernet1/2 10.0.1.1/32 0.0.0.0 0 A H 203.0.113.0/30 203.0.113.2 0 A C ethernet1/1 203.0.113.2/32 0.0.0.0 0 A H total routes shown: 5
(Columns shortened for the page; the simulator prints the full-width table.) Flags: A active, C connected, S static, H host. A connected route appears only when the interface has an IP and is in the virtual router. This table is why "no route" problems are easy to prove.
Why the data-plane test needs a source
admin@NK-PUNE-PA> ping source 203.0.113.2 host 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=0.80 ms ... 5 packets transmitted, 5 received, 0% packet loss
A plain ping host 8.8.8.8 leaves through the management interface. Adding source with a data-interface IP tests the data plane. Before the default route existed, this same command showed "5 packets transmitted, 0 received, 100% packet loss".
Steps 3 to 5: policy, session and log
After PC1 pings 8.8.8.8 through the firewall with a rule and source NAT in place:
admin@NK-PUNE-PA> show session all
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
9361 ping ACTIVE FLOW NS 10.0.1.10[19499]/trust/1 (203.0.113.2[40001])
vsys1 8.8.8.8[8]/untrust (8.8.8.8[8])
admin@NK-PUNE-PA> show log traffic
Time App From Src Port Source
Rule Action To Dst Port Destination
2026/10/02 03:45:26 ping trust 19499 10.0.1.10
Allow-Out allow untrust 0 8.8.8.8
The session line gives you the application (ping), the zones (trust to untrust), and the NAT result: the source 10.0.1.10 was translated to 203.0.113.2 (flag NS = source NAT). The log names the rule that allowed it. Before the rule was added, the counters showed the denials:
admin@NK-PUNE-PA> show counter global filter delta yes severity drop name value rate severity category aspect description flow_policy_deny 5 0 drop flow session Session setup: denied by policy flow_host_service_deny 5 0 drop flow mgmt Device management session denied
flow_policy_deny means a security policy denied a session (here the five pings to 8.8.8.8 before the rule existed). flow_host_service_deny means traffic to the firewall's own interface was refused by the management profile (the five pings to 10.0.1.1 before the profile). Two counters, two different causes, and both are visible from the CLI.
Worked example. User: "The internet is down." You run: interface table (fine), routing table (default route present), test security-policy-match (interzone-default deny), conclusion: no rule allows trust to untrust. Total time: a minute, no guessing. One rule and a commit fixes it, and the session table then proves it.
Common mistakes. Debugging NAT before checking policy. Testing with the wrong zone in test security-policy-match (the "from" and "to" must be the real zones). Reading the traffic log without remembering that denied-by-default traffic is not logged unless you add a logging rule.
Exam trap. The test commands evaluate the configuration; they do not generate traffic. A session in the session table means the firewall allowed and created it. Know the first four commands by heart.
Everything "looked right" but one thing was wrong
After a branch migration, users could not reach a partner site. The interface and route checks were clean. test security-policy-match returned the interzone-default deny: the old rule named the zone "inside", but the new interface was in "trust". Renaming the zone in the rule fixed it. The check order found it in minutes.
Lesson: work down the checklist before touching anything.
"Users cannot reach a site through the firewall. How do you troubleshoot?"
Follow the flow: confirm interfaces, zones and virtual router; confirm a route and its egress interface; use test security-policy-match to see which rule would match; check NAT if the traffic goes out; then look at the session table and traffic log for proof. Mention global counters to spot drops that never make a log entry.
Key takeaways
- Use a fixed order: interface, route, policy, NAT, session and log.
- show interface all and show routing route prove layers 1 to 3.
- ping with source tests the data plane; plain ping uses management.
- Session flags and the log show the rule, zones and NAT result.
- Global counters explain drops: policy deny versus management denial.
Summary, exam map, practice plan and checklist
You made it. In eight chapters you went from "a firewall checks ports" to a working mental model of a Palo Alto Networks next-generation firewall. This last chapter pulls the pieces together, shows how they map to the NGFW Engineer exam, and gives you a practice plan inside this academy.
Identify, organise, decide, change safely, prove it.
Can-do checklist
- I can explain App-ID, User-ID and Content-ID in one sentence each.
- I can explain why a rule is written between zones and name the two default rules.
- I can read a security rule aloud and say why application-default matters.
- I can describe the management, control and data planes.
- I can explain candidate versus running configuration and what a failed commit means.
- I can list what a routed interface needs (IP, virtual router, zone, route, management profile).
- I can run the five-step verification flow from memory.
Mini glossary
- NGFW
- Firewall that identifies applications, users and content, not only ports.
- Zone
- Named group of interfaces; policy source and destination.
- Security rule
- Match conditions plus an action; first match wins.
- Candidate / running
- Draft configuration / enforced configuration.
- Commit
- Validate the candidate and make it running.
- Virtual router
- The routing table an interface belongs to.
- Management profile
- Controls ping, SSH, HTTPS and similar services answered on a data interface.
- Session
- The firewall's record of one allowed connection.
Most tested facts from this module
- Intrazone-default allows; interzone-default denies.
- Running is enforced; set edits the candidate; invalid candidate fails as a whole.
- Rules are evaluated top to bottom; first match wins.
- application-default means the application's standard ports only.
- An interface without a zone passes nothing; without a virtual router it cannot route.
- Plain ping uses the management interface; ping source tests the data plane.
Command cheat-sheet
# operational mode (prompt ends with >) show system info show interface all show routing route show arp all show session all show log traffic show jobs all show running security-policy show running nat-policy test security-policy-match from trust to untrust source 10.0.1.10 destination 8.8.8.8 protocol 6 destination-port 443 ping source 203.0.113.2 host 8.8.8.8 set cli config-output-format set # configure mode (prompt ends with #) configure set / delete / edit / up / top show commit revert config
How the NGFW Engineer exam fits together
The exam checks that you can deploy, configure and operate a PAN-OS firewall: interfaces and zones, policy and NAT, VPN, security profiles and decryption, User-ID, high availability, management with Panorama, and troubleshooting. Question formats and weights change between versions, so use the current official exam guide as your blueprint and treat this track as the practice ground. The labs here run in the NK-OS simulator, which is educational and not Palo Alto software, so confirm product-specific details (such as snapshot commands and new features) in Palo Alto Networks documentation.
Your practice plan
- pan-setup: two labs. First commit (factory default to a working firewall) and a ticket where the DMZ interface is dead. Do them without hints the second time.
- pan-policy: App-ID outbound policy and the rule-order ticket.
- pan-nat and pan-vlans: source and destination NAT, then subinterfaces and deployment modes.
- Then routing, VPN, profiles, decryption, User-ID, high availability and Panorama in track order.
- Revisit this module's quiz and interview questions before every exam attempt.
Common mistake. Memorising commands without the model. If you can say what the firewall does at each of the five steps, the commands follow naturally.
Exam trap. Do not rely on this chapter alone for exam weights, durations or passing scores. Those come from the vendor's current exam guide.
A fresher's first week
On day one a new engineer was asked to "check why the guest Wi-Fi cannot reach the internet". She ran the five steps: the interface was in the guest zone, the route was present, test security-policy-match returned interzone-default deny. She raised a change for one application-based rule, committed it after review, and showed the session in the table. Total time: fifteen minutes, with proof.
Lesson: a calm, ordered method beats clever guessing.
"Walk me through what you know about Palo Alto firewalls."
Start with the NGFW idea (App-ID, User-ID, Content-ID), then zones and rule order, then the candidate and commit model, then your five-step verification flow. Finish with what you have practised in labs. A structured answer shows you can build and troubleshoot, not just recite features.
Key takeaways
- NGFW = stateful firewall plus application, user and content awareness.
- Zones, rules (first match), and defaults (intrazone allow, interzone deny) drive decisions.
- Candidate, validate, commit: changes are all or nothing.
- A working interface needs IP, virtual router, zone, route and a management profile for services.
- Verify in order: interface, route, policy, NAT, session and log.
- Next: pan-setup labs, then pan-policy.