A security zone is a named group of interfaces that share the same trust level, such as Trust, Untrust or DMZ (demilitarized zone). Palo Alto security policy is written between zones, not between interfaces, so zones are the backbone of every rule you will write. Traffic is always classified by a source zone, where it entered the firewall, and a destination zone, where it will leave. If an interface has no zone, the firewall will not pass traffic through it at all, which is a common surprise on a new deployment.
Zones have types that must match the interfaces placed in them: Layer 3, Layer 2, Virtual Wire, Tap, Tunnel and External. A Layer 3 interface can only join a Layer 3 zone, a vwire interface only a Virtual Wire zone, and so on. The External type is special: it exists only on firewalls with multiple virtual systems (vsys) and represents another virtual system, used for traffic passing between vsys. The Tunnel zone type is used with tunnel content inspection, where the firewall inspects the traffic carried inside a cleartext tunnel such as GRE or unencrypted GTP (GPRS Tunneling Protocol), so you can write policy on the inner traffic.
The key rule is that an interface or subinterface belongs to exactly one zone, while a zone can contain many interfaces. That is why subinterfaces are so useful: two VLANs on the same port can sit in different zones. Traffic entering and leaving interfaces in the same zone is intrazone; traffic crossing from one zone to a different zone is interzone. You create zones under Network > Zones and assign interfaces there or on the interface's Config tab. Zones are also where zone protection profiles attach, and they are the unit that logs, reports and the Application Command Center summarize by.
At the bottom of every rulebase are two predefined rules. intrazone-default allows traffic within the same zone, and interzone-default denies traffic between different zones. Neither logs by default. You cannot delete them, but you can select one and click Override to enable logging or attach security profiles, which is a common best practice so that denied interzone traffic shows up in the Traffic log. Any rule you write above them takes precedence because the rulebase is evaluated top-down and the first match wins. Security rules also have a rule type: universal (the default, matching intrazone and interzone), intrazone or interzone, which changes how the zones you list are interpreted.
Zones also control where User-ID runs. In the zone settings there is an Enable User Identification checkbox. When it is enabled, the firewall maps IP addresses from that zone to usernames, so source users appear in logs and user or group based rules can match. Enable it only on internal zones where your users actually are. Enabling it on an Internet-facing zone is a known risk: if client probing is configured, the firewall may try to probe untrusted addresses, which can expose credentials or hashes to outsiders, and it wastes resources mapping addresses that will never be users. You can further narrow mapping with include and exclude network lists on the zone.
Consider a worked example. Two web servers sit in the DMZ zone on different subinterfaces. Traffic between them is intrazone and therefore allowed by the default rule, which worries the auditor because a compromised server could attack its neighbor. You add an explicit DMZ-to-DMZ rule allowing only the application the servers genuinely need, such as mysql from the front end to the database, then add an intrazone deny rule with logging below it. You also override interzone-default to log at session end. Lateral movement between the servers is now restricted and visible in the Traffic log.
Common mistakes: expecting denied interzone traffic to appear in the Traffic log without overriding the default rule, forgetting to assign a newly created subinterface to a zone, trying to put a Layer 3 interface into a Virtual Wire zone, and enabling User Identification on the Untrust zone. Another subtle mistake is assuming intrazone traffic is inspected just because it is allowed; the default intrazone rule has no security profiles unless you override it or write your own rule.
Exam questions often ask about defaults and placement. 'Why does blocked traffic not appear in the logs?' points to overriding interzone-default to enable logging. 'Hosts in the same zone can reach each other without any rule' points to intrazone-default. 'Two VLANs on one port need different policy' points to subinterfaces in separate zones. 'Where should User-ID be enabled?' points to trusted internal zones only, and 'zone that represents another vsys' points to the External zone type.
Key terms
- Security zone
- A logical group of interfaces with the same trust level that security and NAT policy reference.
- intrazone-default
- The predefined rule that allows traffic whose source and destination zone are the same; not logged by default.
- interzone-default
- The predefined rule that denies traffic between different zones; not logged by default.
- External zone
- A zone type used on multi-vsys firewalls to represent another virtual system for inter-vsys traffic.
- Tunnel zone
- A zone type used with tunnel content inspection so policy can apply to traffic inside a cleartext tunnel.
- Enable User Identification
- A per-zone setting that tells the firewall to map IP addresses in that zone to usernames.
- Rule override
- Changing the settings, such as logging or profiles, of a predefined default rule, which cannot be deleted.
Two web servers sit in the DMZ zone on different subinterfaces. Traffic between them is intrazone and allowed by default, which worries the auditor. You add an explicit DMZ-to-DMZ rule allowing only the needed application, then an intrazone deny rule with logging below it, and override interzone-default to log. Lateral movement between the servers is now restricted and every blocked attempt is visible in the Traffic log.
Check yourself
Can one Layer 3 interface belong to two zones?
No. Each interface or subinterface belongs to exactly one zone; use subinterfaces if you need different zones on one port.
Where should 'Enable User Identification' be turned on?
Only on trusted internal zones where users originate, never on Internet-facing untrusted zones, to avoid probing or exposing credentials to outsiders.
What happens to traffic from Trust to DMZ if no rule matches it?
It hits interzone-default and is denied, without logging unless the rule is overridden.
Which zone type represents another virtual system?
The External zone type, available on multi-vsys firewalls for inter-vsys traffic.