Cisco Zone-Based Firewall (ZBFW) — Zones, Zone-Pairs, Policy-Maps

The one-sentence mental model

ZBFW turns a Cisco router into a stateful firewall by grouping interfaces into zones and writing rules for zone-to-zone traffic flows. Instead of “ACL on interface X inbound”, you say “traffic from the INSIDE zone to the OUTSIDE zone matches this class; do this action.” One policy per direction per zone-pair.

The pieces

Zone

A logical group of interfaces sharing the same security profile. Common zones:

• INSIDE — trusted LAN interfaces
• OUTSIDE — untrusted internet-facing interfaces
• DMZ — semi-trusted, publicly-reachable servers
• VPN — remote-access VPN termination
• SELF — implicit zone that includes the router’s own IP addresses. Always present.

Every interface must belong to exactly one zone. An unassigned interface is treated as if in no zone, and by default, traffic to/from it is denied.

Zone-pair

A directional relationship — traffic from zone A to zone B. Policy is applied to the pair. INSIDE → OUTSIDE is one zone-pair; OUTSIDE → INSIDE is a different one.

Traffic between interfaces in the same zone is permitted by default (no zone-pair needed).

Traffic between two zones with no zone-pair is denied by default.

Class-map

Identifies traffic — inspect type class-maps (specific to ZBFW):

class-map type inspect match-any WEB-TRAFFIC
  match protocol http
  match protocol https
  match protocol dns

Policy-map

Applies an action to matched traffic:

policy-map type inspect INSIDE-TO-OUTSIDE
  class type inspect WEB-TRAFFIC
    inspect
  class type inspect INSIDE-TO-OUTSIDE-DENY
    drop log
  class class-default
    drop

Actions:

• inspect — stateful; automatically permits return traffic
• pass — stateless permit; doesn’t track state (used for asymmetric flows or when explicit inspection is unwanted)
• drop — deny
• log — modifier on drop for logging

Zone-pair binding

zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE
  service-policy type inspect INSIDE-TO-OUTSIDE

Traffic ingressing from an INSIDE-zone interface heading to an OUTSIDE-zone interface hits this policy.

Interface assignment

zone security INSIDE
zone security OUTSIDE

interface GigabitEthernet0/1
  zone-member security INSIDE
interface GigabitEthernet0/2
  zone-member security OUTSIDE

The self zone

self is the implicit zone representing the router itself. Traffic destined to a router IP or generated by the router hits the self zone.

By default, traffic from any zone to self is permitted, and self to any zone is permitted. This is a design choice so you don’t lock yourself out during config. But it’s also a security hole.

For a hardened box, add explicit zone-pairs to self:

class-map type inspect match-any MGMT-ALLOWED
  match protocol ssh
  match protocol snmp

policy-map type inspect FROM-INSIDE-TO-SELF
  class type inspect MGMT-ALLOWED
    inspect
  class class-default
    drop

zone-pair security INSIDE-TO-SELF source INSIDE destination self
  service-policy type inspect FROM-INSIDE-TO-SELF

Now only SSH and SNMP from INSIDE reach the router itself. Everything else drops.

Typical enterprise pattern

Three zones: INSIDE, OUTSIDE, DMZ. Zone-pairs:

• INSIDE → OUTSIDE — inspect (allow LAN to internet, stateful, return traffic auto-permitted)
• DMZ → OUTSIDE — inspect (allow servers to update, reach out for external APIs)
• OUTSIDE → DMZ — inspect only specific services (HTTP/HTTPS to web server, DNS to DNS server)
• INSIDE → DMZ — inspect (users reach servers)
• DMZ → INSIDE — usually drop (no reason for DMZ to initiate to LAN)
• OUTSIDE → INSIDE — drop (inbound blocked by default, no zone-pair needed)

Common exam / real-world mistakes

1. Forgetting to assign every interface to a zone. Unassigned interfaces can’t send or receive across zones. Common cause of “why is my WAN not working after ZBFW”.
2. Missing the return-path zone-pair. ZBFW is stateful with inspect — return traffic is auto-permitted. But if you pass instead of inspect, you need explicit both-direction zone-pairs.
3. Locking yourself out via self zone. If you configure a zone-pair to self and get the classification wrong, SSH stops working. Test out-of-band access before applying.
4. Overlapping class-maps. Class-maps in a policy-map are top-down, first match wins. Order matters.
5. Assuming ZBFW replaces ACLs. Interface ACLs still work below ZBFW. Both are evaluated. Use one or the other consistently.
6. Turning on ZBFW without a change window. Any misconfiguration = production outage. Always deploy with a rollback plan.

Verifying

show zone security                              ! zones and their interfaces
show zone-pair security                         ! zone-pairs and their policies
show policy-map type inspect zone-pair          ! runtime hit counters per class
show policy-firewall sessions                   ! active stateful sessions

Cheat strip

Model         zones (groups of interfaces) + zone-pairs (directional rules)
Default       same-zone traffic ALLOWED
              different-zone traffic DENIED (until zone-pair permits)
Special       self zone = the router itself (SSH/SNMP/routing)

Config flow   class-map inspect → policy-map inspect → zone-pair → apply
Actions       inspect (stateful, returns permitted) | pass | drop | log

Typical zones INSIDE | OUTSIDE | DMZ | VPN | self

Verify        show zone security
              show zone-pair security
              show policy-firewall sessions