Zone-Based Firewall (ZBF) Basics

The classic Cisco IOS firewall approach — applying ACLs inbound and outbound on individual interfaces — becomes unwieldy as networks grow. Every new interface needs its own ACL, return traffic requires matching rules in the opposite direction, and there is no built-in concept of which interfaces belong to the same security domain. The Zone-Based Policy Firewall (ZBF) replaces this interface-centric model with a zone-centric model: interfaces are assigned to named security zones, and traffic policies are defined between zone pairs — controlling exactly which traffic flows are permitted, inspected, or dropped between each pair of zones.

ZBF provides stateful inspection — the firewall tracks the state of each allowed connection and automatically permits the corresponding return traffic without needing an explicit return rule. A policy that inspects outbound HTTP from the inside zone to the outside zone automatically allows the HTTP response packets back in. This makes ZBF fundamentally more secure than ACL-based firewalling, where permitting return traffic often requires an overly broad inbound rule.

Before configuring ZBF, ensure basic routing is operational — ZBF policies apply after routing decisions are made. For the routing context, review Static Route Configuration or OSPF Single-Area Configuration. For the ACL concepts that ZBF replaces, see Extended ACL Configuration and ACL Overview. For common port numbers referenced throughout this lab, see Common Port Numbers. For securing management access on the router running ZBF, see AAA with TACACS+ and Login Security — Brute-Force Protection. For DMZ servers that also require static NAT mappings, see Static NAT Configuration.

1. ZBF Architecture — Core Concepts

Zones, Zone-Pairs, and the Self Zone

A zone is a named group of one or more router interfaces that share the same security level and trust requirements. Traffic between interfaces in the same zone is always permitted without any policy. Traffic between interfaces in different zones is blocked by default unless a zone-pair policy explicitly permits or inspects it:

  Zone model:
  ┌──────────────┐      zone-pair policy      ┌──────────────┐
  │  INSIDE zone │ ─────────────────────────► │ OUTSIDE zone │
  │  (Gi0/1)     │ ◄───────────────────────── │  (Gi0/0)     │
  └──────────────┘  separate return zone-pair  └──────────────┘

  Rules:
  1. Interfaces in the SAME zone: traffic always allowed — no policy needed
  2. Interfaces in DIFFERENT zones: BLOCKED by default
  3. A zone-pair enables a directional policy: source-zone → dest-zone
  4. Traffic from INSIDE → OUTSIDE: governed by zone-pair INSIDE to OUTSIDE
  5. Return traffic OUTSIDE → INSIDE: governed by zone-pair OUTSIDE to INSIDE
     (or handled automatically by stateful INSPECT action)
  6. Interfaces NOT assigned to any zone: no ZBF policy applies to them
  7. The SELF zone: represents the router itself — controls traffic TO/FROM the router

The Self Zone

The self zone is a built-in zone representing the router's own processes. It is not assigned to any interface — it automatically captures traffic destined for or originating from the router itself (SSH, OSPF, BGP, SNMP, DNS queries from the router). Zone-pairs involving the self zone control management and routing protocol access:

Zone-Pair Direction	Controls	Example Traffic
INSIDE → self	Traffic from internal hosts TO the router	SSH management from admin PC, SNMP polls from monitoring server
self → INSIDE	Traffic FROM the router TO internal hosts	OSPF Hellos sent to internal neighbours, syslog to internal server
OUTSIDE → self	Traffic from external network TO the router	Inbound BGP from ISP, ICMP ping to router's WAN IP
self → OUTSIDE	Traffic FROM the router TO external destinations	NTP sync to public NTP server, DNS resolution by router

The Three ZBF Policy Actions

Action	Command Keyword	Behaviour	Return Traffic
Inspect	`inspect`	Allows matched traffic AND creates a stateful session entry — tracks connection state	Automatically permitted — no return zone-pair policy needed for the reply
Pass	`pass`	Allows matched traffic in one direction — stateless, no session tracking	NOT automatically permitted — a separate zone-pair policy must permit return traffic
Drop	`drop`	Silently discards matched traffic — no RST or ICMP unreachable sent	N/A — traffic is discarded

ZBF vs ACL Firewall — Key Differences

Feature	ACL Firewall	Zone-Based Firewall
Configuration unit	Per-interface — each interface needs its own ACL	Per-zone-pair — one policy covers all interfaces in a zone
Return traffic	Manual — must explicitly permit return traffic (or use `established` keyword)	Automatic with `inspect` — stateful connection tracking handles returns
Default behaviour	Permit all unless denied by ACL	Block all inter-zone traffic unless a zone-pair policy explicitly permits/inspects
Same-zone traffic	Treated identically to different-zone traffic — needs ACL entries	Always permitted — no policy required for traffic between interfaces in the same zone
Scalability	Grows linearly with interfaces — hard to manage at scale	Scales by zone grouping — adding interfaces to a zone inherits existing policy

ZBF Configuration Building Blocks

ZBF uses a specific sequence of configuration objects — each must be completed in order. Understanding this hierarchy before touching the CLI prevents common errors:

  Step 1: Define zones
          zone security INSIDE
          zone security OUTSIDE

  Step 2: Define class maps (match traffic)
          class-map type inspect [match-all|match-any] HTTP-TRAFFIC
            match protocol http
            match protocol https

  Step 3: Define policy maps (assign actions to matched traffic)
          policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
            class HTTP-TRAFFIC
              inspect
            class class-default
              drop

  Step 4: Create zone-pairs (link two zones with a direction)
          zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
            service-policy type inspect INSIDE-TO-OUTSIDE-POLICY

  Step 5: Assign interfaces to zones
          interface Gi0/1
            zone-member security INSIDE
          interface Gi0/0
            zone-member security OUTSIDE

2. Lab Topology & Scenario

NetsTuts_R1 is the edge router acting as the ZBF. Three zones are defined: INSIDE (corporate LAN), OUTSIDE (internet/WAN), and DMZ (a web server accessible from both inside and outside). The policy permits inside hosts to browse the web and reach the DMZ, permits outside hosts to access only the DMZ web server, and blocks all other traffic from outside to inside:

  192.168.10.0/24                                    203.0.113.0/30
  [INSIDE LAN]                                       [OUTSIDE / ISP]
       |                                                    |
     Gi0/1 ─── INSIDE zone                    OUTSIDE zone ─── Gi0/0
       └──────────────────┬──────────────────────────────────┘
                          │         NetsTuts_R1
                          │  Gi0/2 ─── DMZ zone
                          │       |
                      192.168.20.0/24
                      [DMZ: Web Server 192.168.20.10]

  Zone-Pairs configured:
  INSIDE  → OUTSIDE : inspect HTTP, HTTPS, DNS, ICMP
  INSIDE  → DMZ     : inspect HTTP, HTTPS
  OUTSIDE → DMZ     : inspect HTTP, HTTPS (public web access)
  DMZ     → INSIDE  : drop all (server cannot initiate to LAN)
  OUTSIDE → INSIDE  : drop all (default — no policy = block)
  self    → INSIDE  : pass OSPF, SSH (router management)
  INSIDE  → self    : inspect SSH, ICMP (admin access to router)

Interface	Zone	Network	IP Address
GigabitEthernet0/1	INSIDE	192.168.10.0/24 — Corporate LAN	192.168.10.1
GigabitEthernet0/0	OUTSIDE	203.0.113.0/30 — WAN/Internet	203.0.113.2
GigabitEthernet0/2	DMZ	192.168.20.0/24 — DMZ servers	192.168.20.1

3. Step 1 — Define Security Zones

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Define the three security zones ──────────────────────
NetsTuts_R1(config)#zone security INSIDE
NetsTuts_R1(config-sec-zone)#description Corporate LAN - trusted hosts
NetsTuts_R1(config-sec-zone)#exit

NetsTuts_R1(config)#zone security OUTSIDE
NetsTuts_R1(config-sec-zone)#description Internet / ISP WAN link
NetsTuts_R1(config-sec-zone)#exit

NetsTuts_R1(config)#zone security DMZ
NetsTuts_R1(config-sec-zone)#description DMZ - public-facing web server
NetsTuts_R1(config-sec-zone)#exit

Zone names are case-sensitive and user-defined. The description is optional but recommended for documentation. At this point, no interfaces are assigned to any zone — all traffic continues to flow normally. ZBF policy takes effect only after interfaces are assigned to zones in the final step.

4. Step 2 — Define Class Maps (Traffic Matching)

Class maps define which traffic to match. ZBF uses class-map type inspect — these are separate from QoS class maps. The match-any keyword means traffic matching any one of the match criteria is classified. match-all requires all criteria to match simultaneously (less common for firewall rules):

! ── Class map: web browsing traffic ──────────────────────
NetsTuts_R1(config)#class-map type inspect match-any WEB-TRAFFIC
NetsTuts_R1(config-cmap)#description HTTP and HTTPS web browsing
NetsTuts_R1(config-cmap)#match protocol http
NetsTuts_R1(config-cmap)#match protocol https
NetsTuts_R1(config-cmap)#exit

! ── Class map: DNS resolution ─────────────────────────────
NetsTuts_R1(config)#class-map type inspect match-any DNS-TRAFFIC
NetsTuts_R1(config-cmap)#match protocol dns
NetsTuts_R1(config-cmap)#exit

! ── Class map: ICMP (ping and traceroute) ────────────────
NetsTuts_R1(config)#class-map type inspect match-any ICMP-TRAFFIC
NetsTuts_R1(config-cmap)#match protocol icmp
NetsTuts_R1(config-cmap)#exit

! ── Class map: SSH management access to router ───────────
NetsTuts_R1(config)#class-map type inspect match-any MGMT-TRAFFIC
NetsTuts_R1(config-cmap)#match protocol ssh
NetsTuts_R1(config-cmap)#exit

! ── Class map: routing protocols for self zone ───────────
NetsTuts_R1(config)#class-map type inspect match-any ROUTING-TRAFFIC
NetsTuts_R1(config-cmap)#match protocol ospf
NetsTuts_R1(config-cmap)#exit

The match protocol keyword uses Cisco's Network-Based Application Recognition (NBAR) engine to identify traffic by application protocol — not just port number. NBAR identifies HTTP even on non-standard ports, recognises protocol signatures, and handles protocols that negotiate ports dynamically (like FTP data channels). This is more robust than a simple ACL matching TCP port 80.

Common match protocol Keywords

Keyword	Protocol / Traffic	Port(s)
`http`	HTTP web traffic	TCP 80 (and non-standard ports via NBAR)
`https`	HTTPS encrypted web traffic	TCP 443
`dns`	DNS queries and responses	UDP/TCP 53
`icmp`	ICMP (ping, traceroute)	IP protocol 1
`ssh`	Secure Shell management	TCP 22
`ftp`	FTP control + data (both channels)	TCP 20/21 (NBAR handles dynamic data channel)
`ospf`	OSPF routing protocol	IP protocol 89
`smtp`	Email sending (SMTP)	TCP 25

Matching by ACL (for non-NBAR traffic)

! ── Alternative: match traffic defined by an ACL ─────────
! ── Use when NBAR does not recognise the protocol ─────────
NetsTuts_R1(config)#ip access-list extended CUSTOM-APP
NetsTuts_R1(config-ext-nacl)#permit tcp 192.168.10.0 0.0.0.255 any eq 8080
NetsTuts_R1(config-ext-nacl)#exit

NetsTuts_R1(config)#class-map type inspect match-any CUSTOM-TRAFFIC
NetsTuts_R1(config-cmap)#match access-group name CUSTOM-APP
NetsTuts_R1(config-cmap)#exit

When a protocol cannot be identified by NBAR (match protocol), use match access-group name [ACL] to reference an extended ACL. This combines the precise source/destination/port matching of an ACL with the ZBF policy framework. The ACL inside a ZBF class map acts purely as a traffic selector — its permit/deny actions are ignored; the class map action (inspect/pass/drop) in the policy map determines what happens.

5. Step 3 — Define Policy Maps (Assign Actions)

Policy maps link class maps to actions. The class class-default entry at the end of every policy map catches all traffic not matched by any named class — the action applied here (typically drop) determines the default behaviour for unmatched traffic:

! ── Policy: INSIDE to OUTSIDE (internet access) ──────────
NetsTuts_R1(config)#policy-map type inspect INSIDE-TO-OUTSIDE
NetsTuts_R1(config-pmap)#class type inspect WEB-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class type inspect DNS-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class type inspect ICMP-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#drop
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Policy: INSIDE to DMZ (access internal web server) ───
NetsTuts_R1(config)#policy-map type inspect INSIDE-TO-DMZ
NetsTuts_R1(config-pmap)#class type inspect WEB-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#drop
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Policy: OUTSIDE to DMZ (public web server access) ────
NetsTuts_R1(config)#policy-map type inspect OUTSIDE-TO-DMZ
NetsTuts_R1(config-pmap)#class type inspect WEB-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#drop
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Policy: INSIDE to self (SSH to router) ───────────────
NetsTuts_R1(config)#policy-map type inspect INSIDE-TO-SELF
NetsTuts_R1(config-pmap)#class type inspect MGMT-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class type inspect ICMP-TRAFFIC
NetsTuts_R1(config-pmap-c)#inspect
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#drop
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Policy: self to INSIDE (OSPF + routing) ──────────────
NetsTuts_R1(config)#policy-map type inspect SELF-TO-INSIDE
NetsTuts_R1(config-pmap)#class type inspect ROUTING-TRAFFIC
NetsTuts_R1(config-pmap-c)#pass
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#pass
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

The SELF-TO-INSIDE policy uses pass for routing protocols rather than inspect. OSPF is a connectionless protocol — it does not establish TCP sessions that can be tracked statelessly. Using pass for OSPF means the router's OSPF Hello and LSA packets are forwarded toward INSIDE, but the corresponding OSPF replies from INSIDE back to self must also be explicitly permitted by the INSIDE-TO-SELF policy (which inspects ROUTING-TRAFFIC or passes it via class-default). The final class class-default pass in SELF-TO-INSIDE ensures the router can reach internal hosts for all other functions without being blocked by its own firewall.

6. Step 4 — Create Zone-Pairs and Apply Policy Maps

Zone-pairs are directional — a zone-pair from INSIDE to OUTSIDE is completely independent of a zone-pair from OUTSIDE to INSIDE. Each zone-pair can have at most one service-policy applied:

! ── Zone-pair: INSIDE → OUTSIDE (outbound internet) ──────
NetsTuts_R1(config)#zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
NetsTuts_R1(config-sec-zone-pair)#service-policy type inspect INSIDE-TO-OUTSIDE
NetsTuts_R1(config-sec-zone-pair)#exit

! ── Zone-pair: INSIDE → DMZ ───────────────────────────────
NetsTuts_R1(config)#zone-pair security INSIDE-TO-DMZ source INSIDE destination DMZ
NetsTuts_R1(config-sec-zone-pair)#service-policy type inspect INSIDE-TO-DMZ
NetsTuts_R1(config-sec-zone-pair)#exit

! ── Zone-pair: OUTSIDE → DMZ (public access to web server)
NetsTuts_R1(config)#zone-pair security OUTSIDE-TO-DMZ source OUTSIDE destination DMZ
NetsTuts_R1(config-sec-zone-pair)#service-policy type inspect OUTSIDE-TO-DMZ
NetsTuts_R1(config-sec-zone-pair)#exit

! ── Zone-pair: INSIDE → self (admin SSH to router) ────────
NetsTuts_R1(config)#zone-pair security INSIDE-TO-SELF source INSIDE destination self
NetsTuts_R1(config-sec-zone-pair)#service-policy type inspect INSIDE-TO-SELF
NetsTuts_R1(config-sec-zone-pair)#exit

! ── Zone-pair: self → INSIDE (routing protocols) ─────────
NetsTuts_R1(config)#zone-pair security SELF-TO-INSIDE source self destination INSIDE
NetsTuts_R1(config-sec-zone-pair)#service-policy type inspect SELF-TO-INSIDE
NetsTuts_R1(config-sec-zone-pair)#exit

! ── Note: OUTSIDE → INSIDE has NO zone-pair configured ───
! ── This means all OUTSIDE → INSIDE traffic is DROPPED ───
! ── by default — no explicit deny needed ──────────────────

Zone-pair names are arbitrary labels. source and destination reference the zone names defined in Step 1. The keyword self is the built-in self zone — it does not need to be created. Notice that no OUTSIDE-TO-INSIDE zone-pair is configured — this is intentional. Without a zone-pair between two zones, all traffic between them is blocked by default. The inspect actions in INSIDE-TO-OUTSIDE automatically handle the return HTTP/DNS/ICMP traffic from OUTSIDE back to INSIDE through the stateful session table — no explicit OUTSIDE-TO-INSIDE zone-pair is needed for return traffic.

Why inspect Handles Return Traffic Automatically

  Inside host 192.168.10.10 opens HTTP connection to 8.8.8.8:80

  Outbound packet (INSIDE → OUTSIDE):
    Matches INSIDE-TO-OUTSIDE zone-pair
    Matches WEB-TRAFFIC class map (protocol http)
    Action: INSPECT
    → Session entry created: 192.168.10.10:54321 ↔ 8.8.8.8:80 TCP ESTABLISHED
    → Packet forwarded to OUTSIDE

  Return packet (OUTSIDE → INSIDE):
    No OUTSIDE-TO-INSIDE zone-pair exists
    ZBF checks stateful session table BEFORE applying zone-pair policy
    → Session match found: this is the return for the inspected connection
    → Packet FORWARDED without needing a zone-pair policy
    → This is stateful inspection — ZBF knows it belongs to an allowed session

  New unsolicited packet from OUTSIDE to INSIDE:
    No OUTSIDE-TO-INSIDE zone-pair exists
    Checked against session table — NO match (no existing session)
    → Packet DROPPED — default inter-zone behaviour

7. Step 5 — Assign Interfaces to Zones

This is the final step — and the most operationally sensitive. The moment an interface is assigned to a zone, ZBF policies become active on that interface. Traffic that was previously flowing without policy will now be subject to the zone-pair rules. Always assign interfaces to zones in a maintenance window and keep console access open:

! ── Assign interfaces to security zones ──────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#zone-member security INSIDE
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#zone-member security OUTSIDE
NetsTuts_R1(config-if)#exit

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

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

ZBF is now fully active on all three zones. Verify the complete configuration with show running-config and confirm all interfaces are in the correct zones with show ip interface brief. Always save after successful deployment: write memory.

Interface assignment activates ZBF immediately. Once Gi0/1 is assigned to INSIDE and Gi0/0 is assigned to OUTSIDE, all traffic between them is subject to the INSIDE-TO-OUTSIDE zone-pair policy. Any traffic not matched by a class map in the policy (e.g., FTP, SMTP) hits class-default drop and is silently discarded. Verify that all required traffic classes are in the policy maps before assigning interfaces. If connectivity breaks after assignment, the console (not ZBF-protected) is the recovery path.

Important: Interfaces Not Assigned to Any Zone

! ── Interface NOT in any zone: ZBF does NOT apply ─────────
! ── Loopback0 is intentionally left unzoned ───────────────
! ── (management plane traffic uses loopback) ──────────────
NetsTuts_R1(config)#interface Loopback0
NetsTuts_R1(config-if)#ip address 1.1.1.1 255.255.255.255
NetsTuts_R1(config-if)#exit
! ── No zone-member command — loopback is outside ZBF scope

An interface not assigned to any zone is completely outside the ZBF framework — traffic entering or leaving that interface is not subject to any ZBF policy, exactly as before ZBF was configured. This is commonly used for loopback interfaces used for management (RADIUS source, NTP source) where ZBF policy should not interfere. However, an unzoned interface can freely communicate with any zone — this can be a security gap if not intended. In production, consider assigning all interfaces to an appropriate zone.

8. Verification

show zone security

NetsTuts_R1#show zone security
zone self
  Description: System defined zone

zone INSIDE
  Description: Corporate LAN - trusted hosts
  Member Interfaces:
    GigabitEthernet0/1

zone OUTSIDE
  Description: Internet / ISP WAN link
  Member Interfaces:
    GigabitEthernet0/0

zone DMZ
  Description: DMZ - public-facing web server
  Member Interfaces:
    GigabitEthernet0/2

show zone security confirms all four zones exist (including the system-defined self zone). Each user-defined zone shows its assigned member interface. If an interface is missing from the expected zone, the zone-member security [zone] command was not applied to that interface.

show zone-pair security

NetsTuts_R1#show zone-pair security
Zone-pair name INSIDE-TO-OUTSIDE
    Source-Zone INSIDE  Destination-Zone OUTSIDE
    service-policy INSIDE-TO-OUTSIDE

Zone-pair name INSIDE-TO-DMZ
    Source-Zone INSIDE  Destination-Zone DMZ
    service-policy INSIDE-TO-DMZ

Zone-pair name OUTSIDE-TO-DMZ
    Source-Zone OUTSIDE  Destination-Zone DMZ
    service-policy OUTSIDE-TO-DMZ

Zone-pair name INSIDE-TO-SELF
    Source-Zone INSIDE  Destination-Zone self
    service-policy INSIDE-TO-SELF

Zone-pair name SELF-TO-INSIDE
    Source-Zone self  Destination-Zone INSIDE
    service-policy SELF-TO-INSIDE

All five configured zone-pairs are listed with their source/destination zones and the applied service-policy. Notably absent is an OUTSIDE-TO-INSIDE zone-pair — confirming that unsolicited traffic from outside to inside is dropped by default. If a required zone-pair is missing, check that the zone-pair security command was entered and that service-policy type inspect was applied under it.

show policy-map type inspect zone-pair — Session Statistics

NetsTuts_R1#show policy-map type inspect zone-pair INSIDE-TO-OUTSIDE sessions
policy exists on zp INSIDE-TO-OUTSIDE
 Zone-pair: INSIDE-TO-OUTSIDE

  Service-policy inspect : INSIDE-TO-OUTSIDE

    Class-map: WEB-TRAFFIC (match-any)
      Match: protocol http
        2847 packets, 3456890 bytes
        30 second rate 142 bps
      Match: protocol https
        1523 packets, 2341200 bytes

      Inspect
        Active sessions: 12
        Session creations since subsystem startup or last reset: 184

    Class-map: DNS-TRAFFIC (match-any)
      Match: protocol dns
        342 packets, 18420 bytes

      Inspect
        Active sessions: 0
        Session creations since subsystem startup or last reset: 67

    Class-map: class-default
      Drop
        3 packets, 180 bytes

This is the most detailed ZBF status command. "Active sessions: 12" for WEB-TRAFFIC confirms 12 active HTTP/HTTPS sessions currently being tracked by stateful inspection. "Session creations: 184" shows the cumulative count since startup. "class-default Drop: 3 packets" shows 3 packets that did not match any defined traffic class and were dropped — useful for identifying traffic that needs to be added to a class map. If a protocol is being dropped unexpectedly, it will appear here in the class-default counter.

show policy-map type inspect zone-pair — Drop Statistics

NetsTuts_R1#show policy-map type inspect zone-pair OUTSIDE-TO-DMZ
policy exists on zp OUTSIDE-TO-DMZ
 Zone-pair: OUTSIDE-TO-DMZ

  Service-policy inspect : OUTSIDE-TO-DMZ

    Class-map: WEB-TRAFFIC (match-any)
      Inspect
        Active sessions: 4
        Session creations since subsystem startup or last reset: 89

    Class-map: class-default
      Drop
        47 packets, 2820 bytes

"class-default Drop: 47 packets" on the OUTSIDE-TO-DMZ policy shows 47 packets from the internet that were not HTTP or HTTPS — dropped correctly. These could be port scans, protocol probes, or legitimate protocols not permitted in this policy. The drop counter growing at a steady rate during an attack is expected — it confirms ZBF is working.

Verification Command Summary

Command	What It Shows	Primary Use
`show zone security`	All zones and their assigned member interfaces	Confirm interfaces are in the correct zones — most common first-check after configuration
`show zone-pair security`	All zone-pairs with source/destination zones and applied service-policy	Verify all required zone-pairs exist and have policies applied
`show policy-map type inspect zone-pair [name] sessions`	Per-class match counters, active session count, cumulative session creation count	Confirm traffic is matching the intended class maps; identify traffic hitting class-default drop
`show class-map type inspect`	All ZBF class maps with their match criteria	Verify class map definitions — confirm match-any/match-all and protocol list
`show logging`	ZBF drop events — %FW-6-DROP_PKT syslog messages when traffic is dropped	Real-time monitoring of dropped traffic — identify attacks or misconfigured policies
`debug ip inspect detail`	Real-time ZBF session creation and teardown events	Deep troubleshooting — trace which packets are creating sessions and which are being dropped. Use `undebug all` after use

9. Troubleshooting ZBF Issues

Problem	Symptom	Cause	Fix
All traffic blocked after interface assignment	No connectivity between inside and outside after assigning interfaces to zones	Either no zone-pair is configured between the zones, or the zone-pair exists but has no service-policy applied, or all traffic hits class-default drop because no class map matches it	Check: `show zone-pair security` — confirm the zone-pair exists and has a service-policy. Check: `show policy-map type inspect zone-pair [name] sessions` — if class-default drop counter is rising rapidly, traffic is not matching any class map. Add the required protocol to the appropriate class map.
Traffic flows out but responses never return	HTTP requests go out but no web pages load — session initiated but no response received	The outbound policy uses `pass` instead of `inspect` — stateless pass does not create a session entry, so return packets from OUTSIDE have no session to match and are dropped by default	Change the action from `pass` to `inspect` in the policy map class: `policy-map type inspect [name]` → `class type inspect [class]` → `inspect`. Inspect creates the stateful session that permits return traffic automatically.
Routing protocol adjacency drops after ZBF activation	OSPF or EIGRP neighbours drop when interfaces are assigned to zones	No zone-pair policy between the self zone and the interface's zone permits routing protocol traffic. ZBF applies to traffic TO and FROM the router (self zone) once interfaces are in zones	Create zone-pairs: `zone-pair security SELF-TO-INSIDE source self destination INSIDE` with a policy that passes or inspects OSPF. Also `zone-pair security INSIDE-TO-SELF source INSIDE destination self` for inbound OSPF. Use `match protocol ospf` in the class map.
SSH to router fails after ZBF activation	Admin cannot SSH to the router from the inside network after zones are assigned	No INSIDE-TO-self zone-pair permits SSH traffic to the router. Traffic to the router itself is controlled by self zone policies	Create INSIDE-TO-SELF zone-pair with a policy that inspects SSH: `zone-pair security INSIDE-TO-SELF source INSIDE destination self` with a policy containing `class type inspect MGMT-TRAFFIC` and action `inspect`.
Static IP server in DMZ unreachable	The public web server in DMZ is reachable from OUTSIDE but not from INSIDE	INSIDE-TO-DMZ zone-pair is missing or its policy does not include the correct traffic class for the server's service type	Verify INSIDE-TO-DMZ zone-pair: `show zone-pair security`. Check the policy: `show policy-map type inspect zone-pair INSIDE-TO-DMZ sessions` — if class-default drop counter increments when accessing the server, add the missing protocol to the WEB-TRAFFIC or a dedicated class map.
FTP data transfer fails through ZBF	FTP login succeeds (port 21 works) but file transfers fail (data channel port 20 or passive ports blocked)	Active FTP data channel (TCP 20) or passive FTP ephemeral ports are not matched by the class map. If using `match protocol ftp`, NBAR handles both channels — but if using ACL match, only TCP 21 may be permitted	Use `match protocol ftp` in the class map — NBAR's FTP protocol signature handles both the control channel (21) and the data channel (20 active, ephemeral passive). Avoid using ACL-based matching for FTP as it requires opening large port ranges for passive FTP.

Key Points & Exam Tips

ZBF replaces interface-based ACL firewalling with a zone-centric model: interfaces are grouped into zones, and traffic policies are applied between zone-pairs — not on individual interfaces.
Traffic between interfaces in the same zone is always permitted without any policy. Traffic between interfaces in different zones is blocked by default unless a zone-pair policy explicitly permits or inspects it.
The self zone is built-in and represents the router itself. Zone-pairs involving self control traffic to and from the router's own processes — SSH, routing protocols, SNMP, NTP. If no self zone-pair exists, these also fail.
The three policy actions are: inspect (stateful — permits traffic and tracks session for automatic return), pass (stateless — permits one direction only, no return tracking), and drop (silently discards).
Use inspect rather than pass for TCP and UDP traffic — pass does not create session state, so return packets are dropped by default (no zone-pair exists for the return direction from OUTSIDE to INSIDE).
The ZBF configuration sequence must be followed in order: (1) define zones, (2) create class maps, (3) create policy maps referencing class maps, (4) create zone-pairs referencing zones, (5) apply service-policy to zone-pair, (6) assign interfaces to zones.
class class-default at the end of every policy map catches all unmatched traffic — always include an explicit drop action here to ensure the default deny behaviour is enforced rather than relying on implicit behaviour.
match protocol [keyword] uses NBAR for application-level identification — more robust than port matching and handles protocols that negotiate ports dynamically (FTP, SIP). Use match access-group name [ACL] as an alternative for non-NBAR protocols.
show policy-map type inspect zone-pair [name] sessions is the primary diagnostic command — shows per-class match counters, active sessions, and class-default drop counts that reveal traffic being incorrectly blocked.
On the CCNA exam: know the five-step ZBF sequence, the three policy actions and their differences (especially inspect vs pass return traffic behaviour), the self zone purpose, and the default inter-zone block behaviour.

Next Steps: With ZBF providing stateful inspection at the edge, complement it with Layer 2 protections at the access layer — see DHCP Snooping & Dynamic ARP Inspection. For the ACL concepts that ZBF extends, revisit Extended ACL Configuration. For logging the ZBF drop events generated by this configuration, see Syslog Configuration and show logging. For securing the router's management plane protected by the self zone in this lab, see SSH Configuration, SNMP Configuration, and NTP Configuration. For AAA authentication on the management interface, see AAA RADIUS Configuration. For DMZ servers that also need static NAT for inbound access, see Static NAT Configuration.

TEST WHAT YOU LEARNED

1. Two interfaces Gi0/1 and Gi0/2 are both assigned to the INSIDE zone. A host on Gi0/1 sends traffic to a host on Gi0/2. What does ZBF do with this traffic?

A. ZBF drops the traffic — all inter-interface traffic requires an explicit zone-pair policy B. ZBF permits the traffic without any policy — traffic between interfaces in the same zone always flows freely, regardless of whether a zone-pair policy exists C. ZBF checks the zone-pair policy for INSIDE-TO-INSIDE before forwarding the traffic D. ZBF blocks the traffic unless a self zone policy is configured for intra-zone traffic

Correct answer is B. This is one of ZBF's fundamental rules: traffic between interfaces that belong to the same zone is always permitted without any zone-pair policy. The zone represents a security domain where all members are trusted equally with each other. This simplifies configuration significantly — in a flat corporate LAN with multiple interfaces assigned to INSIDE, all hosts can communicate with each other without any firewall rules. Traffic only needs a zone-pair policy when crossing zone boundaries (INSIDE to OUTSIDE, INSIDE to DMZ, etc.). This is also why zone design matters: placing untrusted segments in the same zone as trusted segments grants them implicit mutual trust.

2. A zone-pair INSIDE-TO-OUTSIDE uses `pass` for HTTP traffic instead of `inspect`. An inside host opens a TCP connection to a web server. What happens to the HTTP response packets?

A. The response packets are forwarded — pass creates a stateful session just like inspect B. The response packets are forwarded through the OUTSIDE-TO-INSIDE zone-pair automatically C. The response packets are forwarded because TCP state is tracked at the IP layer regardless of ZBF action D. The response packets are dropped — pass is stateless and does not create a session entry. Return packets from OUTSIDE need either a matching session (created by inspect) or an explicit OUTSIDE-TO-INSIDE zone-pair policy with a pass or inspect action. Without either, no OUTSIDE-TO-INSIDE zone-pair exists and traffic is blocked by default

Correct answer is D. The distinction between pass and inspect is critical. inspect creates a stateful session entry in ZBF's connection table — return packets are matched against this table and forwarded even though no OUTSIDE-TO-INSIDE zone-pair exists. pass is entirely stateless — it forwards the outbound packet but creates no session record. When the response arrives from OUTSIDE destined for INSIDE, ZBF checks for a session entry (finds none), then checks for an OUTSIDE-TO-INSIDE zone-pair policy (none exists), and drops the packet. This is why pass is generally inappropriate for TCP and UDP flows that require bidirectional communication. Use pass only for one-directional traffic or when you have explicit return policies configured.

3. After assigning Gi0/1 to the INSIDE zone and Gi0/0 to the OUTSIDE zone, the OSPF adjacency with the ISP router on Gi0/0 drops. What is the cause?

A. OSPF traffic to/from the router itself is controlled by the self zone. Once Gi0/0 is in the OUTSIDE zone, OSPF Hellos sent by the router to the ISP and Hellos received from the ISP (destined for the router's process) are subject to OUTSIDE-to-self and self-to-OUTSIDE zone-pair policies. With no such zone-pairs configured, all traffic between the OUTSIDE zone and the router is dropped — including OSPF B. ZBF does not affect OSPF — routing protocols bypass firewall inspection C. The INSIDE zone policy is blocking OSPF because OSPF uses IP multicast which is dropped by class-default D. OSPF adjacency requires a static route to be configured alongside ZBF

Correct answer is A. This is one of the most common ZBF deployment mistakes. When an interface is placed in a zone, ALL traffic to and from the router's own processes on that interface becomes subject to self zone policies. OSPF on Gi0/0 generates Hellos destined to 224.0.0.5 (sent by the router — self to OUTSIDE) and receives Hellos from the ISP (OUTSIDE to self). Without zone-pairs for self→OUTSIDE and OUTSIDE→self with OSPF permitted, both directions are dropped. The fix is to create OUTSIDE-TO-SELF and SELF-TO-OUTSIDE zone-pairs with policies that pass or inspect OSPF. The same applies to any interface-facing routing protocol — BGP on the outside interface, OSPF on inside interfaces, etc.

4. What is the purpose of `class class-default` with a `drop` action at the end of a ZBF policy map?

A. It is the same as a default route — it forwards unmatched traffic to the next policy map for processing B. It is optional — traffic not matched by any class map is automatically dropped by ZBF without needing class-default C. It explicitly catches all traffic not matched by any named class map and applies a drop action — making the default-deny behaviour visible, auditable (the drop counter increments), and intentional rather than implicit. The class-default counter in show policy-map type inspect zone-pair sessions reveals what traffic is being dropped and in what volume D. It is required syntax — ZBF policy maps fail to compile without a class-default entry

Correct answer is C. While inter-zone traffic not matched by any class map is dropped by default anyway (no zone-pair = block, and unmatched traffic in a zone-pair without class-default is also dropped), explicitly configuring class class-default drop provides two operational benefits: (1) the drop counter increments for every unmatched packet, making it visible in show policy-map type inspect zone-pair [name] sessions — you can see exactly how many packets are being dropped as unmatched. Without class-default drop, these counts are invisible. (2) It documents intent — a security reviewer can see that unmatched traffic is explicitly and deliberately dropped rather than wondering whether it is implicitly dropped or silently passed. It also helps identify traffic that should be added to a class map (if the counter is unexpectedly high).

5. An inside host cannot SSH to the router's Gi0/1 interface (192.168.10.1) after ZBF is configured. The INSIDE-TO-OUTSIDE zone-pair is working correctly. What is missing?

A. The SSH configuration on the router is missing — configure crypto key generate rsa B. Gi0/1 must be in a separate MGMT zone — interfaces in INSIDE cannot be SSHed to directly C. The INSIDE-TO-OUTSIDE zone-pair must include SSH in its class map — SSH to the router routes through OUTSIDE D. A zone-pair from INSIDE to the self zone is missing. Traffic from the INSIDE zone destined for the router itself (192.168.10.1) is controlled by the INSIDE-to-self zone-pair. Without it, SSH to the router is blocked — even though SSH to external hosts might work through INSIDE-TO-OUTSIDE. Create: zone-pair security INSIDE-TO-SELF source INSIDE destination self with a policy that inspects SSH

Correct answer is D. This is a precise understanding of the self zone concept. The self zone represents the router's own processes — any traffic addressed to the router itself (SSH to its interface IP, SNMP to its IP, ICMP ping to its IP) is in the INSIDE-to-self zone-pair direction. Traffic from inside hosts to external addresses (through the router) is in the INSIDE-to-OUTSIDE direction. These are entirely separate zone-pairs. The INSIDE-TO-OUTSIDE zone-pair handles traffic that the router routes — it does not govern traffic destined for the router itself. An INSIDE-TO-SELF zone-pair with SSH in an inspect class is required for management access. Without it, any traffic destined for the router from INSIDE hits the implicit inter-zone block.

6. An interface that is not assigned to any zone co-exists with ZBF-zoned interfaces on the same router. What is the security implication?

A. The unzoned interface is completely outside the ZBF framework — it can communicate freely with all zoned interfaces without any policy restriction. This can be a security gap: traffic entering the unzoned interface can reach INSIDE or DMZ zones without being inspected or filtered by ZBF B. ZBF applies the most restrictive policy (drop all) to unzoned interfaces for safety C. Unzoned interfaces can only communicate with the self zone — not with user-defined zones D. Unzoned interfaces are automatically placed in a default zone with a deny-all policy

Correct answer is A. An interface not assigned to any zone operates completely outside the ZBF policy framework — it behaves as if ZBF does not exist for that interface. Traffic in both directions on that interface is not subject to any zone-pair policy, any class-map inspection, or any drop rule. In a router with both zoned and unzoned interfaces, an attacker who can reach the unzoned interface can send traffic to any destination reachable by the router — including into the INSIDE zone — without being blocked by ZBF. This is intentionally used for loopback interfaces and management-only interfaces in some deployments, but must be consciously designed. In production, the recommendation is to assign all physical interfaces to an appropriate zone and use ACLs on unzoned management interfaces instead.

7. `show policy-map type inspect zone-pair INSIDE-TO-OUTSIDE sessions` shows the class-default drop counter incrementing rapidly when users try to use FTP. What does this indicate and how is it fixed?

A. FTP is blocked by the VTY ACL — add permit tcp any any eq 21 to the VTY access-class B. The INSIDE zone is misconfigured — FTP requires a dedicated zone C. FTP traffic is not matched by any class map in INSIDE-TO-OUTSIDE and is falling through to class-default drop. Fix: add a class map for FTP using match protocol ftp and add it to the INSIDE-TO-OUTSIDE policy map with an inspect action. Using NBAR's match protocol ftp handles both the control channel (TCP 21) and the dynamic data channel automatically D. FTP cannot be used through a ZBF — it requires a separate ACL-based firewall for dynamic ports

Correct answer is C. The class-default drop counter incrementing when users try FTP is a diagnostic signal — the traffic is reaching the ZBF policy, not being blocked before it. The traffic traverses the INSIDE-TO-OUTSIDE zone-pair but does not match WEB-TRAFFIC, DNS-TRAFFIC, or ICMP-TRAFFIC class maps, so it falls to class-default drop. The fix involves two steps: (1) Create a class map: class-map type inspect match-any FTP-TRAFFIC then match protocol ftp. (2) Add to the policy map: in policy-map type inspect INSIDE-TO-OUTSIDE, add class type inspect FTP-TRAFFIC with action inspect. NBAR's FTP protocol inspection handles the dynamic data channel port negotiation automatically — this is a major advantage over ACL-based approaches which require opening large port ranges for passive FTP.

8. How does stateful inspection with `inspect` allow HTTP return traffic from OUTSIDE to INSIDE without an OUTSIDE-TO-INSIDE zone-pair policy?

B. When inspect forwards an outbound HTTP packet, ZBF creates a session entry in its connection table recording the 5-tuple (src IP, dst IP, src port, dst port, protocol). Return packets from OUTSIDE are checked against this session table before zone-pair policies are evaluated. A session match allows the return packet through — it is recognised as part of an already-approved connection, not as new unsolicited traffic from OUTSIDE A. ZBF automatically creates a reverse zone-pair when inspect is used — the return zone-pair is dynamically generated C. HTTP is a special protocol that ZBF always allows in both directions regardless of zone-pair configuration D. Return traffic is permitted because the OUTSIDE zone has implicit trust for TCP ACK packets

Correct answer is B. ZBF's stateful inspection works at the connection table level, which is evaluated before zone-pair policies. When an outbound HTTP packet is inspected by the INSIDE-TO-OUTSIDE policy, a session entry is created recording the full connection details (source IP, source port, destination IP, destination port, TCP/UDP). When the HTTP response arrives from OUTSIDE, ZBF first checks: "does this packet belong to an existing tracked session?" — and finds the session created when the request went out. The return packet is associated with an already-approved, inspected session and is forwarded without needing to match any OUTSIDE-TO-INSIDE zone-pair policy. This is the fundamental advantage of stateful inspection over stateless ACLs — return traffic is automatically handled based on connection state, not manually configured rules.

9. What is the correct order for ZBF configuration, and what happens if interfaces are assigned to zones before zone-pairs and policies are configured?

A. Order does not matter — ZBF compiles all configuration at once when saved with wr B. Zone-pairs must be configured before zones — otherwise the zone-pair reference is invalid C. Interfaces should be assigned to zones first — this activates ZBF in passive monitoring mode until policies are applied D. The correct order is: (1) define zones, (2) create class maps, (3) create policy maps, (4) create zone-pairs with service-policy, (5) assign interfaces to zones. If interfaces are assigned before policies are configured, ZBF becomes immediately active with no zone-pair policies — all inter-zone traffic is dropped instantly, breaking connectivity. Keep console access open and configure the complete policy before assigning any production interface

Correct answer is D. The order matters operationally, not just syntactically. IOS will accept zone assignments before zone-pairs are created, but the effect is immediate and traffic-breaking: as soon as an interface is in a zone and another interface is in a different zone, all traffic between them is dropped (no zone-pair = block). If you assign Gi0/0 (OUTSIDE) and Gi0/1 (INSIDE) to zones before creating any zone-pair policies, all inter-zone traffic stops immediately — including any SSH session you might be using to configure the router. The safe practice: configure the entire ZBF hierarchy (zones → class maps → policy maps → zone-pairs with service-policies) in a single session, verify the configuration in running-config, then assign interfaces to zones as the final step. If anything breaks, use the console for recovery.

10. A security policy requires that the DMZ web server (192.168.20.10) must never be able to initiate connections to the corporate LAN (INSIDE). Internet users must reach the web server. Inside users must reach the web server. How are the zone-pairs configured to enforce this?

A. Configure a DMZ-TO-INSIDE zone-pair with a drop-all policy, and configure INSIDE-TO-DMZ and OUTSIDE-TO-DMZ zone-pairs with inspect policies. Also configure a DMZ-TO-OUTSIDE zone-pair with inspect to allow the server to reach the internet B. Configure only INSIDE-TO-DMZ and OUTSIDE-TO-DMZ zone-pairs — the server cannot initiate to INSIDE because the inspect action handles directionality C. Configure INSIDE-TO-DMZ (inspect HTTP/HTTPS) and OUTSIDE-TO-DMZ (inspect HTTP/HTTPS) to allow access to the server. Do NOT configure a DMZ-TO-INSIDE zone-pair at all — the absence of a zone-pair means the DMZ cannot initiate ANY traffic to INSIDE by default. Return traffic for INSIDE-TO-DMZ and OUTSIDE-TO-DMZ sessions is handled automatically by stateful inspection without needing DMZ-to-INSIDE or DMZ-to-OUTSIDE policies D. Configure a DMZ zone-pair with deny source 192.168.20.10 to block the server specifically

Correct answer is C. This demonstrates the elegant power of ZBF's default-deny model. To prevent the DMZ server from initiating connections to INSIDE, simply do not configure a DMZ-TO-INSIDE zone-pair — no policy means no traffic flows from DMZ to INSIDE, period. The server cannot initiate connections to the LAN. For access to the server: INSIDE-TO-DMZ with inspect HTTP/HTTPS allows inside hosts to connect to the server, and the inspect action creates session entries so the server's HTTP responses flow back automatically. Similarly OUTSIDE-TO-DMZ with inspect HTTP/HTTPS allows internet users to reach the server, with responses handled by stateful inspection. There is no need for DMZ-TO-INSIDE or DMZ-TO-OUTSIDE zone-pairs — inspect handles all return traffic. Option A is incorrect because DMZ-TO-OUTSIDE would allow the server to initiate outbound connections (potentially used for command-and-control if compromised), which may violate the spirit of DMZ security.

Back to Home