Index › Policy & Segmentation
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Policy & Segmentation

← Back to full guide index

~3 min read
Prerequisites: Foundations, Traffic Classification — zone/policy rules match on App-ID/User-ID output.

Security Policy & Zone-Based Architecture 08

Learning objectives

  • Explain how zones express trust boundaries and why that scales better than per-interface ACLs
  • Describe the rulebase evaluation order, including the role of Authentication Policy and the implicit intrazone-allow/interzone-deny defaults
  • Use Policy Optimizer to identify port-based rules that can be safely migrated to App-ID-based rules

Security rules decide whether to allow or block a session using attributes like source/ destination zone, IP, application, user, and service — evaluated top-to-bottom, first match wins.

Why

Zones let you express "trust boundaries" (e.g. Trust, DMZ, Untrust) instead of writing rules per interface/subnet, and they keep the rulebase readable as the network grows.

How

Every packet is matched to a session, every session to a rule. Authentication Policy is evaluated before Security Policy. Default rules (bottom of the rulebase) allow intrazone and deny interzone traffic unless overridden. Rules are evaluated left-to-right/top-to-bottom — the first match applies and stops evaluation, so specific rules must precede general ones. Policy Optimizer highlights unused apps/ports so port-based rules can be migrated to App-ID-based ones.
Zone-based policy enforcement through the NGFW with top-to-bottom rule evaluation.
Zone-based policy enforcement through the NGFW with top-to-bottom rule evaluation.

Pros

  • Zone model scales far better than per-IP/interface ACLs
  • Single rule can combine zone + app + user + content-inspection profile
  • Policy Optimizer actively helps shrink an overgrown, insecure rulebase

Cons

  • Rule order matters — a broad rule placed too high silently shadows more specific ones below it
  • Default intrazone-allow can be a blind spot if a zone spans multiple trust levels
  • Rulebases that grow organically without audit comments/tags become hard to safely change later

Exam Trap

A broad rule placed too high in the rulebase silently "shadows" more specific rules below it — traffic matches the first rule top-to-bottom and stops evaluating, so the more specific rule underneath never fires even though it looks correct in isolation. Always check rule order, not just rule content.

Self-check: Security Policy & Zone-Based Architecture
Q1. An admin adds a new, more specific "deny FTP from Contractors" rule below an existing broad "allow any Trust-to-Untrust" rule. Contractor FTP traffic still gets through — why?
A: Rules are evaluated top-to-bottom, first match wins. The broad "allow any" rule above it already matches and allows the traffic, so the deny rule below is never reached — it must be moved above the broad allow rule.
Q2. Two hosts in the same zone need to be blocked from talking to each other by default — will PAN-OS do this out of the box?
A: No. The default rulebase allows intrazone traffic and denies interzone traffic unless overridden — same-zone traffic needs an explicit deny rule (or finer-grained zone/subzone design) to be blocked.

Source: pan-os/11-1/pan-os-admin/policy/security-policy

NAT (Network Address Translation) 09

Learning objectives

  • Distinguish static, dynamic-IP, and dynamic-IP-and-port (DIPP) source NAT
  • Explain how destination NAT rules map to internal servers, one-to-one or one-to-many
  • Describe NAT rule evaluation order and how it relates to Security Policy evaluation

NAT translates private, non-routable addresses to routable ones — and, on PAN-OS, also handles IPv4/IPv6 interop (NAT64) and IPv6 prefix translation (NPTv6). Like Security Policy, NAT rules are evaluated top-to-bottom with first-match-wins, but against a separate rulebase evaluated before the security rule lookup — the firewall determines the translation first, then matches Security Policy against the resulting (post-NAT for destination, pre-NAT for source) addresses.

Why

Conserves public IPv4 space, hides internal addressing from the outside world, resolves overlapping-subnet conflicts, and provides a migration path to IPv6.

How

NAT policy rules define which packets get translated and how. Source NAT comes in three flavors: static IP (one-to-one, bidirectional, no port translation — common for servers that must keep a consistent public identity), dynamic IP (pool of public IPs, one-to-one per session but no port sharing, so the pool can exhaust), and dynamic IP and port (DIPP) (many internal hosts share one or a few public IPs by also translating the source port — the default choice for general outbound internet access). Destination NAT inbound-forwards to internal servers, either static (one external IP/port to one internal host) or with a dynamic destination NAT / translated port range for one-to-many load-style mappings. Supported on Layer 3 and virtual-wire interfaces; DIPP oversubscription lets one public IP serve many internal hosts by multiplying available source ports per translated IP.
Source NAT and destination NAT translation patterns.
Source NAT and destination NAT translation patterns.

Pros

  • Conserves public IPs and obscures internal topology
  • Solves duplicate-subnet conflicts during mergers/acquisitions
  • NAT64/NPTv6 support smooths IPv6 migration

Cons

  • NAT and Security Policy are evaluated separately — rules must be written against the correct (pre- or post-NAT) address, a common source of misconfiguration
  • DIPP oversubscription, if pushed too aggressively, can exhaust port pools under heavy load
  • Adds a layer of indirection that complicates troubleshooting and logging correlation

Exam Trap

NAT and Security Policy are separate rulebases — a classic exam (and real-world) mistake is writing the security rule against the wrong address. Destination NAT rules are matched and applied first, so the Security Policy rule must reference the original (pre-NAT) destination, not the translated internal address, while the source side of a security rule is also always evaluated pre-NAT.

Self-check: NAT
Q1. You configure destination NAT to forward 203.0.113.10:443 to an internal web server at 10.1.1.50:443. What destination address should the matching Security Policy rule use?
A: 203.0.113.10 (the original, pre-NAT destination) — the firewall evaluates the security rule against the original packet header, not the translated one, even though NAT translation happens first in packet processing order.
Q2. Fifty branch office users need outbound internet access but you only have two public IPs. Which source NAT type fits, and why?
A: Dynamic IP and Port (DIPP) — it lets many internal hosts share a small pool of public IPs by also translating the source port, unlike dynamic IP (which is still one-to-one per session and can exhaust a small pool).

Source: pan-os/11-1/pan-os-networking-admin/nat

Zone Protection & DoS Protection 10

No license required

Learning objectives

  • Differentiate Zone Protection profiles (whole-zone) from DoS Protection profiles/rules (specific critical systems)
  • List the attack categories a Zone Protection profile can defend against
  • Explain why default thresholds usually need tuning per environment

Where Security Policy controls which traffic is allowed, Zone/DoS Protection guards against volumetric and reconnaissance attacks that try to overwhelm the network or specific hosts before policy even matters.

Why

Segmenting a network into zones reduces attack surface, but the zone boundaries themselves (and critical servers behind them) still need defense against floods, port scans, and non-IP protocol abuse.

How

Zone Protection profiles apply per-zone defenses against flood, reconnaissance, packet-based, and non-IP-protocol attacks (one profile can cover multiple similar zones). DoS Protection profiles/rules target specific high-value systems (internet-facing web/DB servers) against flood and session-exhaustion attacks.
Zone Protection and DoS Protection profiles shielding networks and critical servers.
Zone Protection and DoS Protection profiles shielding networks and critical servers.

Pros

  • Included at no extra license cost
  • Granular: whole-zone profiles plus per-critical-device DoS rules
  • Stops reconnaissance and floods before they reach application-layer inspection

Cons

  • Consumes dataplane CPU alongside decryption and other services — undersized hardware needs active monitoring
  • Thresholds need tuning per environment; defaults can be too loose or too aggressive

Exam Trap

Zone Protection and DoS Protection are commonly confused: Zone Protection profiles attach to a zone and defend the network broadly (floods, recon, packet-based, non-IP attacks); DoS Protection profiles/rules attach to specific addresses (e.g. one internet-facing server) via a DoS Protection Policy rule. Enabling one does not enable the other, and both operate before Security Policy is ever consulted.

Self-check: Zone Protection & DoS Protection
Q1. You want to protect one specific internet-facing database server from a SYN flood without changing behavior for the rest of the DMZ zone. What do you configure?
A: A DoS Protection profile and rule targeting that server's specific address, not a Zone Protection profile — Zone Protection would apply to the entire zone, not just that host.
Q2. Does Zone Protection require a subscription license?
A: No — Zone Protection and DoS Protection are included at no extra license cost, unlike Threat Prevention or WildFire.

Source: ngfw/administration/zone-protection-and-dos-protection

Module Quiz

1. Two Security policy rules could both match a session: a broad "allow any" rule near the top of the rulebase, and a specific deny rule several positions below it. Which rule actually applies to matching traffic?

PAN-OS evaluates the rulebase top-to-bottom and stops at the first match — a broad rule placed too high silently shadows more specific rules below it, a very common misconfiguration.

2. A newly stood-up zone has no explicit intrazone or interzone Security policy rules configured yet. By default, how does PAN-OS handle traffic between hosts in the same zone versus traffic crossing zones?

The implicit default rules at the bottom of the rulebase allow intrazone-default and deny interzone-default traffic unless explicitly overridden — a blind spot when a single zone spans multiple trust levels.

3. An engineer inherits a rulebase full of legacy port-based rules and wants to identify which ones can be safely converted to App-ID-based rules without breaking production traffic. Which built-in tool should they use?

Policy Optimizer analyzes real traffic hit counts against each rule and highlights port-based rules whose observed applications could be safely migrated to App-ID-based matching.

4. Fifty internal hosts need simultaneous outbound internet access, but the organization owns only two public IP addresses. Which NAT type should be configured?

DIPP lets many internal hosts share a small pool of public IPs by multiplexing the source port as well as the address, which plain Dynamic IP (without port translation) cannot do at this ratio.

5. A Security policy rule needs to match inbound traffic destined for an internal server that sits behind a destination NAT rule translating a public IP to the server's private IP. Which destination address should the Security policy rule reference?

Security policy is evaluated against the original (pre-NAT) destination address even though NAT translation is applied as part of the same packet-processing flow — a classic misconfiguration source when engineers write policy against the post-NAT address instead.

6. An engineer configures DIPP with an aggressive oversubscription ratio to conserve public IPs. Under heavy concurrent load, what risk does this introduce?

Pushing DIPP oversubscription too aggressively can exhaust the shared port pool for a translated IP under heavy concurrent session load, causing new outbound connections to be dropped.

7. While investigating a SYN flood attack, an administrator discovers legitimate client traffic is also being dropped by an existing DoS/Zone Protection configuration set to Random Early Drop. Which two actions would specifically limit drops to only the attacking sessions? (Choose two.)

SYN Cookies validates the TCP handshake before committing session resources, so only connections that fail the handshake are dropped, unlike Random Early Drop, which drops traffic probabilistically and can catch legitimate sessions.

8. A customer asks whether enabling Zone Protection and DoS Protection profiles requires a separate paid subscription like Threat Prevention. What is the accurate answer?

Zone Protection and DoS Protection profiles are both core NGFW capabilities included with the platform, unlike Threat Prevention, WildFire, and other content-based subscriptions.

9. An organization is migrating a legacy IPv4-only application environment and needs traffic between IPv6-only clients and IPv4-only servers to interoperate. Which PAN-OS feature addresses this?

NAT64 (with NPTv6 for prefix translation) provides the IPv4/IPv6 interoperability and migration path; the other options address entirely different problems.
← Encrypted TrafficFirewall Fundamentals & Admin →