Zone-Based Firewall (ZBF)

1. What Is a Zone-Based Firewall?

A Zone-Based Firewall (ZBF) — also called Zone-Based Policy Firewall (ZFW) — is Cisco's modern stateful firewall feature for IOS routers. Introduced as the successor to the older Context-Based Access Control (CBAC) and classic ACL-based filtering, ZBF organises router interfaces into logical zones and controls traffic by defining policies between zone-pairs — making firewall policy significantly more structured, readable, and maintainable than applying individual ACLs to every interface.

The core concept is simple: interfaces are assigned to zones. Traffic flowing between zones is blocked by default until an explicit policy permits or inspects it. Traffic flowing within the same zone is permitted freely by default. This default-deny between zones is a fundamental security improvement over ACLs, which permit all traffic unless a deny rule is explicitly written.

Feature	Classic ACL Filtering	Zone-Based Firewall (ZBF)
Configuration model	ACLs applied per interface, per direction (in/out)	Zones assigned to interfaces; policies defined between zone-pairs
Default behaviour	Permit all (unless an explicit deny is configured)	Deny all between zones (explicit policy required to allow traffic)
Stateful inspection	No — ACLs are stateless; return traffic must be explicitly permitted	Yes — `inspect` action tracks sessions and automatically permits return traffic
Intra-zone traffic	Not a concept — each interface is independent	Permitted by default between interfaces in the same zone
Policy structure	Flat list of ACE permit/deny statements	Hierarchical: class maps → policy maps → zone-pairs
Scalability	Poor — ACLs grow large and become difficult to audit	Good — policies are named, reusable, and zone-scoped
Self zone (router traffic)	No explicit concept — managed with separate ACLs	Explicit self zone representing the router itself

2. Zones — The Foundation of ZBF

A zone is a named logical grouping of one or more router interfaces that share the same trust level and security policy requirements. Interfaces within the same zone can communicate freely with each other. Traffic attempting to cross a zone boundary is subject to the zone-pair policy — and dropped by default if no policy exists.

Typical Zone Design

  Common three-zone design for a branch or edge router:

  ┌─────────────────────────────────────────────────────────────┐
  │                        ROUTER                               │
  │                                                             │
  │  [Gi0/0] ──► INSIDE zone    (trusted — internal LAN)       │
  │  [Gi0/1] ──► OUTSIDE zone   (untrusted — internet/ISP)     │
  │  [Gi0/2] ──► DMZ zone       (semi-trusted — public servers) │
  │                                                             │
  │  [Router itself] ──► SELF zone (built-in, always exists)   │
  └─────────────────────────────────────────────────────────────┘

  Zone rules:
  ✔ Gi0/0 ↔ Gi0/0 (same zone) → traffic flows freely
  ✘ Gi0/0 → Gi0/1 (cross-zone) → BLOCKED until policy permits
  ✘ Gi0/1 → Gi0/0 (cross-zone) → BLOCKED until policy permits
  ✘ Gi0/0 → Gi0/2 (cross-zone) → BLOCKED until policy permits

Key Zone Rules

Rule	Detail
An interface can belong to only one zone	You cannot assign the same interface to INSIDE and DMZ simultaneously
An interface not assigned to any zone behaves like a classic router interface	It passes all traffic (no ZBF policy applies to it). Mixing zoned and un-zoned interfaces on the same router is possible but generally discouraged
Traffic between same-zone interfaces is permitted	No policy is needed for intra-zone traffic
Traffic between different zones is dropped by default	A zone-pair with an explicit policy must be configured to allow any inter-zone traffic
Zones are unidirectional by default	A policy from INSIDE→OUTSIDE does not automatically create a return policy. You either use `inspect` (stateful, handles returns automatically) or create explicit policies in both directions

3. Zone-Pairs — Defining the Direction of Policy

A zone-pair defines a directional relationship between two zones and is the container to which a policy map is applied. Zone-pairs are unidirectional — a zone-pair from INSIDE to OUTSIDE controls traffic leaving the inside network, while a separate zone-pair from OUTSIDE to INSIDE would control traffic originating from the outside.

With inspect (stateful inspection), you typically only need to define the zone-pair in the initiating direction. The inspect engine automatically tracks the session state and permits the return traffic without a policy in the reverse direction.

  Zone-pair directionality:

  INSIDE zone ──────────────────────────────► OUTSIDE zone
              zone-pair: INSIDE-to-OUTSIDE
              (controls outbound traffic from LAN to internet)

  OUTSIDE zone ─────────────────────────────► INSIDE zone
               zone-pair: OUTSIDE-to-INSIDE
               (controls inbound traffic from internet to LAN)

  With 'inspect' on INSIDE-to-OUTSIDE:
  → Outbound sessions initiated by inside hosts are tracked
  → Return packets for those sessions are allowed automatically
  → The OUTSIDE-to-INSIDE zone-pair is not needed for return traffic
  → But it IS needed if you want to allow new sessions FROM the internet

  Three zones = up to 6 zone-pairs possible (one per direction per pair):
  INSIDE→OUTSIDE  OUTSIDE→INSIDE
  INSIDE→DMZ      DMZ→INSIDE
  OUTSIDE→DMZ     DMZ→OUTSIDE

Creating a Zone-Pair in IOS

  ! Create zone-pair from INSIDE to OUTSIDE:
  Router(config)# zone-pair security INSIDE-to-OUTSIDE
                  source INSIDE destination OUTSIDE

  ! Attach a policy map to the zone-pair:
  Router(config-sec-zone-pair)# service-policy type inspect INSIDE-OUT-POLICY

  ! Naming convention tip: use descriptive names like
  ! "LAN-to-WAN", "INSIDE-to-OUTSIDE", "PRIV-to-PUB"
  ! that immediately indicate the direction of traffic.

Direction matters: If you configure a zone-pair only from INSIDE→OUTSIDE with inspect, inside hosts can browse the internet and receive replies. But a host on the internet trying to initiate a new connection inward will be blocked — there is no OUTSIDE→INSIDE zone-pair permitting it. This is the desired behaviour for most outbound-only policies.

4. The ZBF Policy Framework — Class Maps and Policy Maps

ZBF uses Cisco's Modular QoS CLI (MQC) framework — the same building blocks used for QoS — to define what traffic matches and what action to take. There are two key configuration objects:

Object	Purpose	IOS Command
Class Map (type inspect)	Identifies traffic — matches packets by protocol, ACL, or other criteria. Answers: "What traffic are we talking about?"	`class-map type inspect`
Policy Map (type inspect)	Assigns an action (inspect / pass / drop) to traffic matched by a class map. Answers: "What do we do with that traffic?"	`policy-map type inspect`

4.1 Class Maps — Matching Traffic

A class-map type inspect defines what traffic a policy should act on. It can match traffic by protocol name, ACL, or a combination using match-any (logical OR) or match-all (logical AND).

  ! Match common internet protocols (match-any = OR logic):
  Router(config)# class-map type inspect match-any INTERNET-TRAFFIC
  Router(config-cmap)# match protocol http
  Router(config-cmap)# match protocol https
  Router(config-cmap)# match protocol dns
  Router(config-cmap)# match protocol icmp
  Router(config-cmap)# match protocol ftp

  ! Match traffic based on an ACL:
  Router(config)# ip access-list extended WEB-SERVERS-ACL
  Router(config-ext-nacl)# permit tcp any 192.168.100.0 0.0.0.255
                           eq 80
  Router(config-ext-nacl)# permit tcp any 192.168.100.0 0.0.0.255
                           eq 443

  Router(config)# class-map type inspect match-all DMZ-WEB-TRAFFIC
  Router(config-cmap)# match access-group name WEB-SERVERS-ACL

  ! The class-default class-map matches ALL traffic not matched
  ! by any other class-map in the policy. Use it to explicitly
  ! drop or log unmatched traffic.

4.2 Policy Maps — Assigning Actions

A policy-map type inspect references one or more class maps and assigns a ZBF action to each. There are three possible actions:

Action	Behaviour	Stateful?	When to Use
inspect	Performs stateful deep packet inspection. Tracks the session in the state table and automatically allows return traffic without a reverse zone-pair policy	Yes	For most TCP and UDP protocols where you want full session tracking and automatic return-path handling
pass	Allows traffic in the specified direction only — stateless. Return traffic must be explicitly permitted in the reverse zone-pair	No	For protocols that do not benefit from stateful inspection, or where symmetric policies are explicitly configured in both directions
drop	Silently discards the matched traffic. Can optionally log dropped packets with `drop log`	No	Explicitly blocking known-bad traffic; always applied to the `class-default` class to enforce default-deny

  ! Policy map applying inspect to matched traffic,
  ! drop to everything else:

  Router(config)# policy-map type inspect INSIDE-OUT-POLICY
  Router(config-pmap)# class type inspect INTERNET-TRAFFIC
  Router(config-pmap-c)# inspect
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log
  ! 'drop log' silently drops but generates a syslog message
  ! for unmatched traffic — useful for security auditing

CCNA exam tip: Know the difference between inspect (stateful — return traffic allowed automatically) and pass (stateless — return traffic must be explicitly configured in the reverse zone-pair). Using inspect on the INSIDE→OUTSIDE zone-pair is the standard approach for outbound internet access.

5. The Self Zone — Protecting the Router Itself

The self zone is a special, built-in zone that represents the router itself — specifically, traffic that is destined for or originated by the router's own IP addresses (management traffic, routing protocol packets, SSH sessions, ICMP pings to the router, etc.).

The self zone is automatically created by Cisco IOS — you cannot assign interfaces to it, and you cannot delete it. It always exists. You interact with it by creating zone-pairs that include self as a source or destination.

  Self zone — what traffic it covers:

  Traffic TO the router (destined for router's own IP):
  [External Host] ──SSH──► [Router Gi0/1 IP 203.0.113.1]
                                    ▲
                                SELF zone
                           (router processes this packet)

  Traffic FROM the router (originated by the router):
  [Router] ──OSPF Hello──► [Neighbour router]
  [Router] ──NTP query──►  [NTP server]
  [Router] ──BGP update──► [BGP peer]
               ▲
           SELF zone
  (router generated this packet)

  Without a self zone policy:
  → All traffic TO the router from any zone is PERMITTED by default
  → All traffic FROM the router to any zone is PERMITTED by default
  (self zone default behaviour is more permissive than inter-zone defaults)

  With a self zone policy:
  → You can restrict which sources can SSH, ping, or send routing
    protocol traffic to the router

Self Zone Default Behaviour

Important distinction: Unlike inter-zone traffic (which is denied by default), traffic to and from the self zone is permitted by default when no self zone policy is configured. This means even without any ZBF policy, the router can be pinged, SSH'd to, and can run routing protocols. Once you create a zone-pair involving the self zone, the behaviour changes to deny-unless-permitted for that direction — so be careful not to accidentally lock yourself out of the router.

Common Self Zone Use Cases

  ! Allow SSH to the router only from the INSIDE zone:

  Router(config)# class-map type inspect match-any MGMT-ACCESS
  Router(config-cmap)# match protocol ssh
  Router(config-cmap)# match protocol icmp

  Router(config)# policy-map type inspect MGMT-POLICY
  Router(config-pmap)# class type inspect MGMT-ACCESS
  Router(config-pmap-c)# pass
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log

  ! Zone-pair: INSIDE zone → SELF zone (traffic to the router):
  Router(config)# zone-pair security INSIDE-to-SELF
                  source INSIDE destination self
  Router(config-sec-zone-pair)# service-policy type inspect MGMT-POLICY

  ! This restricts management access: only inside hosts can SSH
  ! or ping the router. Outside hosts are blocked.

Routing Protocols and the Self Zone

  If you apply a policy to the OUTSIDE→SELF zone-pair, you must
  explicitly permit routing protocol traffic or adjacencies will break:

  Router(config)# class-map type inspect match-any ROUTING-PROTOCOLS
  Router(config-cmap)# match protocol ospf
  Router(config-cmap)# match protocol eigrp
  Router(config-cmap)# match protocol bgp

  Router(config)# policy-map type inspect OUTSIDE-SELF-POLICY
  Router(config-pmap)# class type inspect ROUTING-PROTOCOLS
  Router(config-pmap-c)# pass
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log

6. Stateful Inspection — How inspect Tracks Sessions

The inspect action is the heart of ZBF's firewall capability. When a packet matches a class with the inspect action, the router creates an entry in its session state table recording the source IP, destination IP, source port, destination port, and protocol. Return packets are matched against this table and permitted automatically — without needing a rule in the reverse zone-pair.

  Stateful inspection flow — inside host browsing the web:

  Step 1: Inside host (192.168.1.10) sends HTTP request to 8.8.8.8:80
          Src: 192.168.1.10:51234  Dst: 8.8.8.8:80  TCP SYN

  Step 2: Packet hits ZBF on INSIDE→OUTSIDE zone-pair
          Matches class INTERNET-TRAFFIC (protocol http)
          Action: inspect
          → Router creates state table entry:
            192.168.1.10:51234 ↔ 8.8.8.8:80 TCP ESTABLISHED

  Step 3: Packet forwarded to internet (NAT also applies if configured)

  Step 4: Return packet arrives: Src: 8.8.8.8:80  Dst: 203.0.113.1:51234
          ZBF checks state table on OUTSIDE→INSIDE direction
          → Match found in state table for this session
          → Packet permitted WITHOUT needing OUTSIDE→INSIDE policy
          → Delivered to 192.168.1.10

  Step 5: When TCP FIN/RST or timeout → state table entry removed
          New connection from outside to 192.168.1.10 will be DROPPED

What inspect Tracks

Protocol	What inspect Tracks	Notes
TCP	Full TCP session state (SYN, ESTABLISHED, FIN, RST)	Most comprehensive — tracks full three-way handshake
UDP	Pseudo-session based on src/dst IP and ports with a timeout	UDP has no connection state — IOS uses a timer-based approach
ICMP	Echo request/reply pairs using ICMP sequence numbers	Allows ping replies back to the initiating host
FTP	Control channel + dynamically opened data channel	Application-layer awareness handles FTP's dual-channel nature

7. Complete ZBF Configuration — Step by Step

The following example configures a ZBF on an edge router with three zones: INSIDE (trusted LAN), OUTSIDE (internet), and DMZ (web server). Inside hosts can browse the internet; the DMZ web server accepts inbound HTTP/HTTPS from the internet; inside hosts can manage the router via SSH.

  Topology:
  [LAN 192.168.1.0/24] ── Gi0/0 ── [Router] ── Gi0/1 ── [Internet]
                                        │
                                       Gi0/2
                                        │
                              [DMZ 192.168.100.0/24]
                              [Web Server 192.168.100.10]

Step 1 — Create the Zones

  Router(config)# zone security INSIDE
  Router(config-sec-zone)# description Trusted Internal LAN

  Router(config)# zone security OUTSIDE
  Router(config-sec-zone)# description Untrusted Internet

  Router(config)# zone security DMZ
  Router(config-sec-zone)# description Semi-trusted DMZ servers

Step 2 — Assign Interfaces to Zones

  Router(config)# interface GigabitEthernet0/0
  Router(config-if)# zone-member security INSIDE

  Router(config)# interface GigabitEthernet0/1
  Router(config-if)# zone-member security OUTSIDE

  Router(config)# interface GigabitEthernet0/2
  Router(config-if)# zone-member security DMZ

Step 3 — Create Class Maps

  ! Traffic inside hosts use to reach the internet:
  Router(config)# class-map type inspect match-any INSIDE-TO-INTERNET
  Router(config-cmap)# match protocol http
  Router(config-cmap)# match protocol https
  Router(config-cmap)# match protocol dns
  Router(config-cmap)# match protocol icmp
  Router(config-cmap)# match protocol ftp
  Router(config-cmap)# match protocol smtp

  ! Web traffic inbound from internet to DMZ server:
  Router(config)# class-map type inspect match-any DMZ-WEB
  Router(config-cmap)# match protocol http
  Router(config-cmap)# match protocol https

  ! Management access to the router (SSH and ICMP from inside):
  Router(config)# class-map type inspect match-any ROUTER-MGMT
  Router(config-cmap)# match protocol ssh
  Router(config-cmap)# match protocol icmp

Step 4 — Create Policy Maps

  ! Policy for INSIDE → OUTSIDE (outbound internet):
  Router(config)# policy-map type inspect INSIDE-OUT-POLICY
  Router(config-pmap)# class type inspect INSIDE-TO-INTERNET
  Router(config-pmap-c)# inspect
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log

  ! Policy for OUTSIDE → DMZ (inbound web to DMZ server):
  Router(config)# policy-map type inspect OUTSIDE-DMZ-POLICY
  Router(config-pmap)# class type inspect DMZ-WEB
  Router(config-pmap-c)# inspect
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log

  ! Policy for INSIDE → SELF (management access to router):
  Router(config)# policy-map type inspect INSIDE-SELF-POLICY
  Router(config-pmap)# class type inspect ROUTER-MGMT
  Router(config-pmap-c)# pass
  Router(config-pmap-c)# exit
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# drop log

Step 5 — Create Zone-Pairs and Apply Policies

  ! Inside hosts → internet (outbound with stateful return):
  Router(config)# zone-pair security INSIDE-to-OUTSIDE
                  source INSIDE destination OUTSIDE
  Router(config-sec-zone-pair)# service-policy type inspect
                                 INSIDE-OUT-POLICY

  ! Internet → DMZ web server (inbound HTTP/HTTPS only):
  Router(config)# zone-pair security OUTSIDE-to-DMZ
                  source OUTSIDE destination DMZ
  Router(config-sec-zone-pair)# service-policy type inspect
                                 OUTSIDE-DMZ-POLICY

  ! Inside hosts → router management:
  Router(config)# zone-pair security INSIDE-to-SELF
                  source INSIDE destination self
  Router(config-sec-zone-pair)# service-policy type inspect
                                 INSIDE-SELF-POLICY

  ! NOTE: No OUTSIDE→INSIDE zone-pair = internet cannot
  ! initiate new connections into the LAN. Inspect on
  ! INSIDE→OUTSIDE handles return traffic for LAN sessions.

Order matters: Always create zones first, then class maps and policy maps, and finally zone-pairs. You cannot attach a policy map to a zone-pair that references a zone not yet created. Also confirm that every interface you intend to protect is assigned to a zone — un-zoned interfaces bypass ZBF entirely.

8. Parameter Maps — Tuning Inspection Behaviour

A parameter map (type inspect) allows you to tune the inspection engine's behaviour — adjusting session timeouts, half-open connection limits, and other thresholds. It is applied inside a policy map class using the inspect keyword followed by the parameter map name.

  ! Create a parameter map to customise inspection settings:
  Router(config)# parameter-map type inspect CUSTOM-TIMEOUTS
  Router(config-profile)# tcp idle-time 3600
    ! TCP session idle timeout in seconds (default: 3600)
  Router(config-profile)# udp idle-time 30
    ! UDP pseudo-session timeout in seconds (default: 30)
  Router(config-profile)# icmp idle-time 10
    ! ICMP session timeout in seconds (default: 10)
  Router(config-profile)# sessions maximum 1000
    ! Max concurrent sessions for this inspect policy
  Router(config-profile)# tcp max-incomplete host 50
    ! Max half-open TCP sessions per destination host
    ! (helps mitigate SYN flood attacks)

  ! Apply parameter map in the policy map:
  Router(config)# policy-map type inspect INSIDE-OUT-POLICY
  Router(config-pmap)# class type inspect INSIDE-TO-INTERNET
  Router(config-pmap-c)# inspect CUSTOM-TIMEOUTS

When to use parameter maps: The default inspection timeouts are suitable for most environments. Parameter maps are typically used when you need to harden the router against DoS attacks (reducing half-open session limits), or when long-lived UDP applications (like VoIP) need extended idle timers to avoid premature session teardown.

9. ZBF Verification and Troubleshooting Commands

Verification Commands

  ! Show all configured security zones:
  Router# show zone security

  ! Show zone-pair configuration and which policy is attached:
  Router# show zone-pair security

  ! Show active session state table (established inspect sessions):
  Router# show policy-map type inspect zone-pair sessions

  ! Show all policy-maps of type inspect:
  Router# show policy-map type inspect

  ! Show class-map configuration:
  Router# show class-map type inspect

  ! Show which zone an interface belongs to:
  Router# show zone security
  ! (lists interfaces per zone)

  ! Verify interface zone membership:
  Router# show interfaces GigabitEthernet0/0
  ! Look for "Member of security zone: INSIDE"

  ! Show ZBF statistics and hit counts:
  Router# show policy-map type inspect zone-pair

Sample Output — show zone-pair security

  Router# show zone-pair security

  Zone-pair name          Source Zone      Destination Zone
  ─────────────────────   ─────────────    ────────────────
  INSIDE-to-OUTSIDE       INSIDE           OUTSIDE
    service-policy inspect: INSIDE-OUT-POLICY
  OUTSIDE-to-DMZ          OUTSIDE          DMZ
    service-policy inspect: OUTSIDE-DMZ-POLICY
  INSIDE-to-SELF          INSIDE           self
    service-policy inspect: INSIDE-SELF-POLICY

Sample Output — show policy-map type inspect zone-pair sessions

  Router# show policy-map type inspect zone-pair sessions

  Zone-pair: INSIDE-to-OUTSIDE
  Policy inspect name: INSIDE-OUT-POLICY
  Class inspect name:  INSIDE-TO-INTERNET

  Established Sessions:
  Session 0x2A3B4C5D (192.168.1.10:51234)=>(8.8.8.8:443) https SIS_OPEN
  Session 0x2A3B4C5E (192.168.1.11:52100)=>(1.1.1.1:53)  dns   SIS_OPEN

  Total session count for policy exceeds configured maximum 0 - dropping
  ! (This message appears if sessions exceed the parameter map limit)

Troubleshooting Common ZBF Issues

Symptom	Likely Cause	Fix
All traffic from inside blocked after adding ZBF	Interface assigned to zone but no zone-pair or policy defined	Create a zone-pair with a policy map using `inspect` for permitted traffic
Inside hosts can reach internet but cannot be pinged from outside	Expected — no OUTSIDE→INSIDE zone-pair; inspect on INSIDE→OUTSIDE handles return traffic only	This is correct ZBF behaviour. Add OUTSIDE→INSIDE policy only if inbound pings are explicitly required
SSH to router stopped working after applying ZBF	Created a zone-pair involving the self zone without permitting SSH, or forgot to create INSIDE→SELF zone-pair	Add INSIDE→SELF zone-pair with a policy that `pass`es SSH (protocol ssh)
OSPF/EIGRP adjacency dropped after ZBF configuration	Routing protocol traffic to the router (self zone) is being blocked by a self zone policy	Add routing protocol match to the self zone policy: `match protocol ospf`
DMZ server not reachable from internet	Missing OUTSIDE→DMZ zone-pair, or class map does not match the correct protocol/port	Verify zone-pair exists, policy is attached, and class map matches the correct protocol
An interface passes all traffic (ZBF seems to have no effect)	Interface is not assigned to any zone — it operates outside ZBF entirely	Add `zone-member security <zone-name>` to the interface configuration

Real-Time Debug

  ! Enable ZBF debug (use with caution on production routers):
  Router# debug policy-firewall
  Router# debug policy-firewall detail

  ! Turn off all debugging:
  Router# no debug all
  ! or:
  Router# undebug all

10. ZBF Design Best Practices

Best Practice	Reason
Assign every interface to a zone	Un-zoned interfaces bypass ZBF completely, creating security gaps. Even interfaces that do not need policy should be placed in a zone with a drop-all policy
Use `inspect` instead of `pass` for most TCP/UDP traffic	`inspect` is stateful and handles return traffic automatically. `pass` is stateless and requires symmetric policies in both directions, increasing complexity
Always end policy maps with `class class-default drop log`	Enforces default-deny for all unmatched traffic and generates syslog entries for visibility. Without this, the implicit default action may silently drop without logging
Create explicit INSIDE→SELF and SELF→INSIDE zone-pairs for management traffic	Restricts which zones and hosts can access the router via SSH, SNMP, and other management protocols. Reduces attack surface
Use descriptive names for zones, class maps, and policy maps	ZBF configurations can become complex. Names like `INSIDE-TO-OUTSIDE`, `INTERNET-TRAFFIC`, and `DMZ-WEB-POLICY` make auditing and troubleshooting much faster than generic names
Permit routing protocol traffic explicitly when using self zone policies	OSPF, EIGRP, and BGP communicate directly with the router's own IP — they traverse the self zone. Blocking them will drop adjacencies and cause routing failures
Test with `ping` and `show policy-map type inspect zone-pair sessions`	Verifies that inspect sessions are being created correctly and that traffic is matching the intended class maps

Test Your Knowledge — Zone-Based Firewall Quiz

1. What is the default behaviour for traffic passing between two different zones in a Cisco ZBF when no zone-pair policy exists?

A. Traffic is permitted in both directions until a deny policy is configured B. All traffic between different zones is dropped by default — an explicit policy must be created to permit any inter-zone traffic C. Traffic is permitted outbound but blocked inbound by default D. Traffic is inspected but not blocked

Correct answer is B. ZBF enforces a default-deny posture between zones. The moment you assign interfaces to different zones, all traffic between those zones is dropped unless a zone-pair with a permit or inspect policy is explicitly configured. This is the opposite of classic ACL behaviour, where all traffic is permitted unless an explicit deny rule exists.

2. What is the key difference between the `inspect` action and the `pass` action in a ZBF policy map?

A. inspect drops traffic; pass permits it B. They are identical — both permit traffic in both directions C. inspect performs stateful session tracking and automatically permits return traffic; pass is stateless and only permits traffic in the specified direction — return traffic must be explicitly allowed in the reverse zone-pair D. inspect works only with TCP; pass works with all protocols

Correct answer is C. inspect is the stateful action — it creates an entry in the session state table that allows return packets to bypass the ZBF checks automatically. pass is stateless and one-directional; if you use pass on INSIDE→OUTSIDE, you also need a pass (or inspect) on OUTSIDE→INSIDE for return traffic. For most deployments, inspect is the preferred action.

3. An interface is configured with `zone-member security INSIDE` but no zone-pair or policy map references the INSIDE zone. What happens to traffic from that interface trying to reach the internet?

A. All traffic is dropped — the interface is in a zone but no policy allows it to cross to any other zone B. Traffic passes normally as if no ZBF were configured C. Traffic is inspected using the default IOS inspection profile D. Traffic is permitted outbound but blocked inbound

Correct answer is A. Once an interface is assigned to a zone, ZBF's default-deny applies to all cross-zone traffic. With no zone-pair defined between INSIDE and OUTSIDE, there is no policy to permit any traffic — so everything is dropped. This is a common ZBF pitfall: assigning an interface to a zone without simultaneously creating the necessary zone-pair and policy map.

4. What is the self zone in Cisco ZBF, and how does traffic to/from the self zone behave by default (with no self zone policy configured)?

A. The self zone is an administrator-created zone for management interfaces; traffic is denied by default B. The self zone represents DMZ servers; all traffic is inspected automatically C. The self zone is the same as an unzoned interface — traffic is blocked by default D. The self zone is a built-in zone representing the router itself. Unlike inter-zone traffic, traffic to and from the self zone is permitted by default when no self zone policy exists — so management, routing protocols, and ICMP to the router work without explicit configuration

Correct answer is D. The self zone is automatically created by IOS and represents all traffic destined for or originated by the router's own IP addresses. Its default behaviour is more permissive than inter-zone traffic — if no self zone policy exists, all traffic to the router is allowed. This is why SSH, routing protocols, and pings to the router continue to work even after deploying ZBF. Once you create a self zone-pair policy, it enforces deny-unless-permitted for that direction.

5. Which configuration object in ZBF identifies the traffic that a policy should act on?

A. Zone-pair B. Class map (type inspect) — it defines what traffic is matched using protocol names, ACLs, or other criteria C. Policy map — it defines which zone the traffic comes from D. Parameter map — it identifies traffic by timeout values

Correct answer is B. The ZBF configuration uses the MQC (Modular QoS CLI) framework. A class-map type inspect answers "what traffic?" by matching protocols, ACLs, or combinations. A policy-map type inspect answers "what action?" by referencing class maps and assigning inspect/pass/drop. A zone-pair answers "between which zones?" and is where the policy map is applied.

6. A network engineer configures `inspect` on the INSIDE→OUTSIDE zone-pair. Does a separate OUTSIDE→INSIDE zone-pair need to be created for return HTTP traffic?

A. Yes — a separate OUTSIDE→INSIDE zone-pair with pass for HTTP is always required for return traffic B. Yes — inspect only works for outbound new connections, not return traffic C. No — inspect creates a session state entry when inside hosts initiate the connection. Return packets match that state entry and are automatically permitted without an OUTSIDE→INSIDE policy D. No — ZBF automatically creates symmetric zone-pairs for all inspect policies

Correct answer is C. This is the core benefit of stateful inspect. When an inside host sends an HTTP request, the router creates a state table entry for that session. When the web server sends the reply, the router matches it against the state table and lets it through automatically — no OUTSIDE→INSIDE policy is needed for that return traffic. An OUTSIDE→INSIDE policy would only be needed if you want internet hosts to initiate new connections inward.

7. What happens to an interface that is NOT assigned to any zone when ZBF is deployed on the router?

A. It behaves as a classic (non-ZBF) router interface — all traffic passes freely as if ZBF does not exist on that interface B. It is automatically placed in the self zone C. It is placed in a default OUTSIDE zone automatically D. All traffic on that interface is dropped until it is assigned to a zone

Correct answer is A. Interfaces not assigned to any zone are completely outside the ZBF framework and pass traffic without any firewall inspection. This is a security risk — an attacker connected to an un-zoned interface bypasses all ZBF policy. Best practice is to assign every interface to a zone. If an interface should have no outbound connectivity, assign it to a zone with a drop-all policy.

8. After configuring ZBF with INSIDE, OUTSIDE, and SELF zones, an engineer notices that OSPF adjacency with a neighbour on the OUTSIDE interface has dropped. What is the most likely cause?

A. OSPF is not supported by ZBF B. The OUTSIDE interface was not assigned to a zone C. The OUTSIDE→INSIDE zone-pair is missing D. An OUTSIDE→SELF zone-pair policy was created but does not include a class permitting OSPF traffic. OSPF hello and LSA packets are destined for the router (self zone) and are being dropped by the policy's class-default drop rule

Correct answer is D. Routing protocols like OSPF send packets directly to the router's IP or multicast address (224.0.0.5 / 224.0.0.6) — these are destined for the router itself, meaning they traverse the self zone. If an OUTSIDE→SELF zone-pair policy exists with a class-default drop and no class matching OSPF, all OSPF packets are dropped and the adjacency fails. The fix is to add match protocol ospf to a class and permit it in the self zone policy. See: ZBF Lab

9. Which command displays all active inspect sessions currently tracked by ZBF?

A. show ip inspect sessions B. show policy-map type inspect zone-pair sessions C. show zone security sessions D. show firewall sessions

Correct answer is B. show policy-map type inspect zone-pair sessions displays all active sessions in the ZBF state table — showing source and destination IP addresses, ports, protocol, and session state (e.g., SIS_OPEN). This is the primary command for verifying that inspect is working correctly and that sessions are being tracked. show ip inspect sessions is the older CBAC command for the legacy IOS firewall, not ZBF.

10. How many zones can a single router interface be assigned to in Cisco IOS ZBF?

A. Up to two — one for inbound and one for outbound traffic B. Unlimited — an interface can belong to as many zones as needed C. Exactly one — each interface can belong to only a single zone at a time D. Up to four — one per zone-pair the interface participates in

Correct answer is C. In Cisco IOS ZBF, each interface can be a member of exactly one zone. If you attempt to assign an interface to a second zone, IOS will reject the command. This is a fundamental design constraint of ZBF — the zone defines the trust level of everything connected to that interface, and an interface cannot simultaneously belong to two different trust domains. Multiple interfaces can belong to the same zone. See: ZBF Configuration Lab

Zone-Based Firewall (ZBF)

1. What Is a Zone-Based Firewall?

2. Zones — The Foundation of ZBF

Typical Zone Design

Key Zone Rules

3. Zone-Pairs — Defining the Direction of Policy

Creating a Zone-Pair in IOS

4. The ZBF Policy Framework — Class Maps and Policy Maps

4.1 Class Maps — Matching Traffic

4.2 Policy Maps — Assigning Actions

5. The Self Zone — Protecting the Router Itself

Self Zone Default Behaviour

Common Self Zone Use Cases

Routing Protocols and the Self Zone

6. Stateful Inspection — How inspect Tracks Sessions

What inspect Tracks

7. Complete ZBF Configuration — Step by Step

Step 1 — Create the Zones

Step 2 — Assign Interfaces to Zones

Step 3 — Create Class Maps

Step 4 — Create Policy Maps

Step 5 — Create Zone-Pairs and Apply Policies

8. Parameter Maps — Tuning Inspection Behaviour

9. ZBF Verification and Troubleshooting Commands

Verification Commands

Sample Output — show zone-pair security

Sample Output — show policy-map type inspect zone-pair sessions

Troubleshooting Common ZBF Issues

Real-Time Debug

10. ZBF Design Best Practices

Test Your Knowledge — Zone-Based Firewall Quiz

1. What is the default behaviour for traffic passing between two different zones in a Cisco ZBF when no zone-pair policy exists?

2. What is the key difference between the inspect action and the pass action in a ZBF policy map?

3. An interface is configured with zone-member security INSIDE but no zone-pair or policy map references the INSIDE zone. What happens to traffic from that interface trying to reach the internet?

4. What is the self zone in Cisco ZBF, and how does traffic to/from the self zone behave by default (with no self zone policy configured)?

5. Which configuration object in ZBF identifies the traffic that a policy should act on?

6. A network engineer configures inspect on the INSIDE→OUTSIDE zone-pair. Does a separate OUTSIDE→INSIDE zone-pair need to be created for return HTTP traffic?

7. What happens to an interface that is NOT assigned to any zone when ZBF is deployed on the router?

8. After configuring ZBF with INSIDE, OUTSIDE, and SELF zones, an engineer notices that OSPF adjacency with a neighbour on the OUTSIDE interface has dropped. What is the most likely cause?

9. Which command displays all active inspect sessions currently tracked by ZBF?

10. How many zones can a single router interface be assigned to in Cisco IOS ZBF?

Related Topics & Step-by-Step Tutorials

2. What is the key difference between the `inspect` action and the `pass` action in a ZBF policy map?

3. An interface is configured with `zone-member security INSIDE` but no zone-pair or policy map references the INSIDE zone. What happens to traffic from that interface trying to reach the internet?

6. A network engineer configures `inspect` on the INSIDE→OUTSIDE zone-pair. Does a separate OUTSIDE→INSIDE zone-pair need to be created for return HTTP traffic?