Cisco IOS Zone-Based Firewall: Zones, Zone Pairs, Inspect

Zone-Based Policy Firewall (ZBFW) replaced the old interface-level ip inspect model on Cisco IOS and IOS XE: instead of attaching an inspection rule to a single interface, you group interfaces into named security zones and write unidirectional policy between zone pairs. The result is a stateful firewall that scales with the topology instead of the interface count, and a configuration that reads like a policy document. This guide walks the four building blocks — zones, zone pairs, class-maps and policy-maps — then shows the verification commands that prove traffic is actually matched.

The mental model

Every interface you want to filter must belong to exactly one security zone, and interfaces in the same zone can talk to each other freely. Policy only exists between zones: a zone pair is directional, so Inside-to-Outside and Outside-to-Inside are two separate policy decisions. The single most important default: if no policy exists between a pair of zones, traffic is dropped. That default is why a half-finished ZBFW deployment takes down a branch office, and why you build and verify the policy before removing legacy ACLs.

Step 1 — define zones and assign interfaces

zone security INSIDE
zone security OUTSIDE

interface GigabitEthernet0/0
 description LAN
 zone-member security INSIDE
interface GigabitEthernet0/1
 description WAN
 zone-member security OUTSIDE

An interface can be a member of only one zone. Router-generated traffic (management, routing protocols) originates from the router itself and is handled by the self-zone, not by these zone pairs — a subtlety that explains why adding an interface to a zone can break SSH to the device if you filtered it carelessly.

Step 2 — class-maps describe traffic

ip access-list extended LAN-WEB
 permit tcp 10.10.10.0 0.0.0.255 any eq 80
 permit tcp 10.10.10.0 0.0.0.255 any eq 443
!
class-map type inspect match-any WEB-TRAFFIC
 match access-group name LAN-WEB

class-map type inspect match-any ROUTER-ICMP
 match protocol icmp

Use match-any when any single condition should match, match-all when a packet must satisfy every condition in the map. For troubleshooting protocols that rely on ICMP errors (path MTU discovery, traceroute), a separate class for match protocol icmp saves a lot of head-scratching later.

Step 3 — policy-maps decide the action

policy-map type inspect INSIDE-TO-OUTSIDE
 class type inspect WEB-TRAFFIC
  inspect
 class type inspect ROUTER-ICMP
  inspect
 class class-default
  drop

Three actions matter: inspect builds a stateful session and permits the return traffic automatically; pass allows the packet without state; drop discards it silently. The return path does not need its own zone pair if the initiating direction is inspected — the state table covers it.

Step 4 — bind the policy to a zone pair

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

Only type inspect policies can be attached to a zone pair. If you want to control traffic between two interfaces inside the same zone, define a zone pair with the same zone as both source and destination and apply an inspect policy to it — otherwise intra-zone traffic is always permitted.

Parameter maps for tweaking timeouts

parameter-map type inspect INSPECT-PARAMS
 tcp idle-time 1800
 udp idle-time 30
 alert on

policy-map type inspect INSIDE-TO-OUTSIDE
 class type inspect WEB-TRAFFIC
  inspect INSPECT-PARAMS

Verification

show zone-pair security
show policy-map type inspect zone-pair sessions
show class-map type inspect
show zone security

show policy-map type inspect zone-pair sessions is the command that matters during an incident: it lists live sessions per zone pair with the matched class and the state. If traffic is dropping and no session appears, the problem is in the class-map; if sessions appear and then reset, look at asymmetric routing, since ZBFW drops packets that do not follow the expected path.

Common traps

• Forgetting class class-default — some code trains leave class-default implicit and it drops, which is fine, but making it explicit documents intent.
• Filtering the management interface by putting it in a zone and leaving no zone pair to anywhere.
• Using ZBFW alongside legacy ip inspect on the same interface — pick one model.
• Expecting WCCP or PBR-redirected traffic to survive inspection unchanged; redirection and inspection interact, so validate the combination in a lab.

Once the policy is stable, layer on visibility with Cisco Flexible NetFlow configuration so you can confirm what is being denied, and tighten the access layer separately using the port-security techniques in Cisco 802.1X and MAB configuration.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-2/sec-data-zbf-xe-2-book/sec-zone-pol-fw.html