In the CCNA 200-301 exam, understanding Zone-Based Firewall (ZBF) is critical because it represents Cisco's modern approach to stateful firewall inspection on routers. Unlike legacy ACL-based firewalls, ZBF offers granular policy control by grouping interfaces into security zones and applying policies between them. This lab will walk you through configuring ZBF from scratch, covering zone pairs, class maps, policy maps, and service policies. By mastering ZBF, you not only prepare for exam objective 5.7 but also gain a practical skill for securing branch offices and campus networks.
Jump to a section
Imagine a secure embassy building with multiple entrances: one for staff, one for visitors, and one for deliveries. The embassy is divided into zones: the outside world (untrusted), the visitor lobby (less trusted), and the inner offices (trusted). Each entrance is like a router interface assigned to a zone. The security guards at each entrance enforce rules based on the zone the person is coming from and going to. For example, a person from the outside world (Zone A) entering the visitor lobby (Zone B) must pass through a metal detector and show ID (inspect traffic). But a person moving from the visitor lobby to the inner offices (Zone C) needs additional clearance (more restrictive policy). The guards don't just check each person individually; they also remember who has already been cleared and allow them to move freely within the zone for a time (stateful inspection). If someone tries to go from the inner offices to the outside world without permission (traffic from trusted to untrusted), the guard blocks them unless explicitly allowed (default deny). The guards use a rulebook (policy map) that tells them what actions to take for each type of visitor (protocol). This zone-based approach is far more scalable and secure than having a single guard at one door trying to remember everyone (ACL-based firewall).
What is Zone-Based Firewall and Why It Exists
Zone-Based Firewall (ZBF) is Cisco's next-generation stateful firewall implementation for IOS routers. It replaces the older Context-Based Access Control (CBAC) and provides a more intuitive, zone-oriented security model. In ZBF, interfaces are assigned to security zones, and firewall policies are applied between zone pairs. Traffic between zones is subject to inspection, while traffic within the same zone is allowed by default (unless explicitly blocked). This model aligns with the network security principle of least privilege: traffic from a higher-security zone to a lower-security zone may be restricted, while traffic from lower to higher is typically inspected.
The exam objective 5.7 specifically tests your ability to configure and verify ZBF on Cisco IOS. You must understand the building blocks: zones, zone-pairs, class maps, policy maps, and service policies. The configuration is modular, allowing you to create reusable policies.
How ZBF Works Step by Step at the Packet Level
Zone Assignment: Each router interface is assigned to a zone using the zone-member security command. An interface can belong to only one zone. Traffic entering or exiting an interface is evaluated based on the source and destination zones.
Zone-Pair Definition: A zone-pair defines the direction of traffic between two zones: source and destination. For example, zone-pair INSIDE-OUT with source INSIDE and destination OUTSIDE controls traffic from inside to outside. Traffic in the opposite direction (outside to inside) requires a separate zone-pair.
Class Map: Class maps match traffic based on criteria such as protocol, source/destination IP, or port. There are two types: class-map type inspect for application-level inspection and class-map type match-any for simple ACL-like matching. For ZBF, we use class-map type inspect to define traffic classes.
Policy Map: A policy map binds class maps to actions. Actions include inspect (stateful inspection), pass (allow without inspection), drop (silently drop), and drop-log (drop and log). The policy map is applied to a zone-pair.
Service Policy: The service-policy type inspect command applies the policy map to a zone-pair in the global configuration mode. This activates the firewall rules.
When a packet arrives at an interface, the router identifies the source and destination zones. If a zone-pair exists for that direction, the corresponding service policy is evaluated. The packet is matched against class maps in order. The first match determines the action. If the action is inspect, the router creates a stateful session entry, allowing return traffic. If no match, the default action is drop (unless overridden with pass for all traffic).
Key States, Timers, and Defaults
Default action: For any zone-pair, if no matching class map is found, traffic is dropped. There is no implicit permit.
Inspect action: Creates a session table entry. The default session timeout is 60 minutes for TCP and 30 seconds for UDP (configurable via ip inspect tcp idle-time and ip inspect udp idle-time).
Zone membership: An interface can belong to only one zone. Traffic between interfaces in the same zone is allowed by default (no inspection). To block intra-zone traffic, you must apply an ACL or use a self-zone policy.
Self zone: The router itself is considered a separate zone. Traffic to/from the router (e.g., SSH, SNMP) is controlled by zone-pairs involving the self zone.
IOS CLI Verification Commands with Example Output
After configuring ZBF, use these commands to verify:
show zone security
show zone-pair security
show policy-map type inspect zone-pair
show class-map type inspect
show ip inspect sessions
show ip inspect statisticsExample output for show zone security:
Router# show zone security
zone INSIDE
member interfaces: GigabitEthernet0/0
zone OUTSIDE
member interfaces: GigabitEthernet0/1Example output for show zone-pair security:
Router# show zone-pair security
Zone-pair name INSIDE-OUT
Source zone: INSIDE
Destination zone: OUTSIDE
service-policy type inspect: INSIDE-OUT-POLICYExample output for show policy-map type inspect zone-pair:
Router# show policy-map type inspect zone-pair
Zone-pair: INSIDE-OUT
Service-policy inspect: INSIDE-OUT-POLICY
Class-map: HTTP (match-all)
Inspect
Class-map: class-default (match-any)
DropHow ZBF Interacts with Related Protocols
ZBF can inspect many protocols, including HTTP, HTTPS, DNS, FTP, and ICMP. For TCP, it tracks sequence numbers and ensures proper three-way handshake. For UDP, it creates sessions based on source/destination IP and port. ZBF can also integrate with Network Address Translation (NAT) and VPN. When NAT is configured, ZBF inspects the translated addresses. For VPN traffic, ZBF can inspect after decryption if the interface is in a zone.
ZBF is not an intrusion prevention system (IPS); it does not perform deep packet inspection beyond what is configured. However, it can be combined with Cisco IOS IPS for enhanced security.
Define Security Zones
First, create the security zones that will group your interfaces. Use the `zone security` command in global configuration mode. For example, to create an INSIDE zone for trusted internal network and an OUTSIDE zone for the untrusted internet: ``` Router(config)# zone security INSIDE Router(config-sec-zone)# exit Router(config)# zone security OUTSIDE Router(config-sec-zone)# exit ``` You can also create additional zones like DMZ if needed. The zone name is arbitrary but should be descriptive. After creating zones, assign interfaces to them using the `zone-member security` command under the interface configuration. For example: ``` Router(config)# interface GigabitEthernet0/0 Router(config-if)# zone-member security INSIDE Router(config-if)# exit Router(config)# interface GigabitEthernet0/1 Router(config-if)# zone-member security OUTSIDE Router(config-if)# exit ``` Verify with `show zone security`.
Create Zone-Pairs
A zone-pair defines the direction of traffic flow between two zones. You need a zone-pair for each direction you want to control. For example, to control traffic from INSIDE to OUTSIDE: ``` Router(config)# zone-pair security INSIDE-OUT source INSIDE destination OUTSIDE Router(config-sec-zone-pair)# exit ``` Similarly, for traffic from OUTSIDE to INSIDE (if you want to allow inbound traffic like a web server): ``` Router(config)# zone-pair security OUTSIDE-IN source OUTSIDE destination INSIDE Router(config-sec-zone-pair)# exit ``` If you need to control traffic to the router itself (e.g., SSH management), create a zone-pair with the `self` zone as source or destination. For example: ``` Router(config)# zone-pair security SELF-OUT source self destination OUTSIDE Router(config)# zone-pair security INSIDE-SELF source INSIDE destination self ``` Verify with `show zone-pair security`.
Configure Class Maps for Traffic Matching
Class maps define which traffic will be inspected or allowed. Use `class-map type inspect` to create a class that matches specific protocols. For example, to match HTTP and HTTPS traffic: ``` Router(config)# class-map type inspect match-any HTTP-TRAFFIC Router(config-cmap)# match protocol http Router(config-cmap)# match protocol https Router(config-cmap)# exit ``` Use `match-any` if any one condition should match; use `match-all` if all conditions must match. You can also match based on access lists: ``` Router(config)# access-list 100 permit tcp any any eq 80 Router(config)# class-map type inspect match-all HTTP-ACL Router(config-cmap)# match access-group 100 Router(config-cmap)# exit ``` For ICMP (ping), create a class map: ``` Router(config)# class-map type inspect match-any ICMP Router(config-cmap)# match protocol icmp Router(config-cmap)# exit ``` Verify with `show class-map type inspect`.
Create Policy Maps with Actions
A policy map binds class maps to actions. The actions are `inspect` (stateful inspection), `pass` (allow without inspection), `drop` (silently drop), or `drop-log` (drop and log). Create a policy map for each zone-pair. For example, for INSIDE-OUT, allow HTTP and ICMP with inspection, and drop everything else: ``` Router(config)# policy-map type inspect INSIDE-OUT-POLICY Router(config-pmap)# class type inspect HTTP-TRAFFIC Router(config-pmap-c)# inspect Router(config-pmap-c)# exit Router(config-pmap)# class type inspect ICMP Router(config-pmap-c)# inspect Router(config-pmap-c)# exit Router(config-pmap)# class class-default Router(config-pmap-c)# drop Router(config-pmap-c)# exit Router(config-pmap)# exit ``` For OUTSIDE-IN, you might want to allow only specific inbound traffic (e.g., HTTP to a web server). Create a class map for that traffic and use `inspect`. For traffic to the router (INSIDE-SELF), you might allow SSH: ``` Router(config)# class-map type inspect match-any SSH Router(config-cmap)# match protocol ssh Router(config-cmap)# exit Router(config)# policy-map type inspect INSIDE-SELF-POLICY Router(config-pmap)# class SSH Router(config-pmap-c)# inspect Router(config-pmap-c)# exit Router(config-pmap)# class class-default Router(config-pmap-c)# drop Router(config-pmap-c)# exit ``` Verify with `show policy-map type inspect`.
Apply Service Policy to Zone-Pairs
The final step is to apply the policy map to the corresponding zone-pair using the `service-policy type inspect` command in zone-pair configuration mode. For example: ``` Router(config)# zone-pair security INSIDE-OUT Router(config-sec-zone-pair)# service-policy type inspect INSIDE-OUT-POLICY Router(config-sec-zone-pair)# exit Router(config)# zone-pair security INSIDE-SELF Router(config-sec-zone-pair)# service-policy type inspect INSIDE-SELF-POLICY Router(config-sec-zone-pair)# exit ``` If you have an OUTSIDE-IN policy, apply it similarly. After applying, the firewall is active. Verify with `show policy-map type inspect zone-pair` and `show ip inspect sessions` to see active sessions. ``` Router# show ip inspect sessions Established Sessions Session 82A3B0 (10.0.0.2:34567)=>(203.0.113.1:80) tcp SIS_OPEN Created 00:00:05, Last heard 00:00:05 Bytes sent (initiator:responder) [1500:2500] ``` Test connectivity: from an inside host, ping an outside host; it should succeed. From outside, ping inside; it should fail (unless allowed).
Verify and Troubleshoot
Use verification commands to ensure the firewall is working as expected. Key commands: - `show zone security` – shows zone members. - `show zone-pair security` – shows zone-pairs and attached policies. - `show policy-map type inspect zone-pair` – shows the policy applied to each zone-pair. - `show ip inspect sessions` – shows active stateful sessions. - `show ip inspect statistics` – shows packet counts for inspected traffic. - `debug ip inspect detailed` – enables debugging (use with caution in production). If traffic is unexpectedly blocked, check the following: - Is the interface assigned to the correct zone? - Is the zone-pair defined for the direction of traffic? - Does the class map match the traffic? Use `show class-map type inspect` to verify. - Is the policy map applied to the correct zone-pair? - Check the default class action; if it's `drop`, any unclassified traffic will be dropped. - For return traffic, ensure stateful inspection is working; if you used `pass` instead of `inspect`, return traffic may be blocked unless explicitly allowed. Example debug output: ``` Router# debug ip inspect detailed *Mar 1 00:01:23.456: %FW-6-SESS_CREATED: (target:class)-(INSIDE-OUT:HTTP-TRAFFIC) session 82A3B0 created for tcp 10.0.0.2:34567 -> 203.0.113.1:80 *Mar 1 00:01:23.789: %FW-6-SESS_DELETED: (target:class)-(INSIDE-OUT:HTTP-TRAFFIC) session 82A3B0 deleted ``` If sessions are not being created, verify that the `inspect` action is used and not `pass`.
In enterprise networks, Zone-Based Firewall is commonly deployed on Cisco ISR routers at branch offices to provide stateful inspection between the internal LAN (trusted) and the WAN or internet (untrusted). For example, a retail store with a router connecting to corporate HQ via MPLS and to the internet for credit card processing. The router can have three zones: INSIDE (store LAN), DMZ (POS terminals), and OUTSIDE (internet). The DMZ zone might allow only HTTPS traffic to specific payment gateways, while the INSIDE zone allows general web access but with inspection.
Another scenario is a campus network where the router connects multiple VLANs. ZBF can be used to enforce policies between student, staff, and guest networks. For instance, guests can only access the internet, not internal resources. Staff can access both. This is achieved by creating zones for each VLAN and applying zone-pairs with appropriate policies.
Performance considerations: ZBF is stateful and consumes memory for session tables. On low-end routers, too many concurrent sessions can degrade performance. Cisco recommends using the ip inspect max-incomplete high and ip inspect one-minute high commands to limit session creation under DoS attacks. Also, ZBF can be combined with QoS to prioritize critical traffic.
Misconfiguration example: A common mistake is forgetting to create a zone-pair for the reverse direction. For example, if you allow traffic from INSIDE to OUTSIDE but not the reverse, return traffic will be dropped because the stateful inspection creates a temporary opening only for return packets. However, if you use inspect, the return traffic is automatically allowed. But if you use pass, you must create a separate zone-pair for the reverse direction with a matching class map. Another misconfiguration is assigning an interface to the wrong zone, causing traffic to be blocked unexpectedly. Always verify with show zone security.
The CCNA 200-301 exam objective 5.7 covers configuring and verifying Zone-Based Firewall. The exam expects you to know the configuration steps in order: zones, zone-pairs, class maps, policy maps, and service policies. You will likely see a scenario where you must identify the missing command or the correct syntax. Common wrong answers include:
Applying the service policy directly to an interface: Many candidates think of classic firewall rules applied to interfaces. In ZBF, you apply the service policy to the zone-pair, not the interface. The interface is only assigned to a zone.
Using `ip inspect` commands: The older CBAC syntax (e.g., ip inspect name) is not used in ZBF. ZBF uses class-map type inspect, policy-map type inspect, and zone-pair. Candidates who studied older material may confuse these.
Forgetting the default drop: The default action for a zone-pair is to drop all traffic. If you only define a class map for HTTP and apply inspect, all other traffic is dropped. Candidates may assume that unspecified traffic is allowed, but it is not.
Confusing `pass` and `inspect`: pass allows traffic without stateful inspection, meaning return traffic is not automatically allowed. inspect creates a session. On the exam, if a question asks for stateful inspection, inspect is the correct action.
Specific values: The default TCP idle timeout is 3600 seconds (60 minutes), UDP is 30 seconds. These are configurable. The show ip inspect sessions command shows active sessions. The show policy-map type inspect zone-pair command shows the applied policy.
Decision rule: When given a scenario, first identify the zones and zone-pairs needed. Then determine the traffic to be allowed (e.g., HTTP, DNS). Create class maps for those protocols. Then create a policy map with inspect for those classes and drop for class-default. Finally, apply to the zone-pair. If the scenario involves the router itself (e.g., SSH), use the self zone.
Zone-Based Firewall uses security zones, zone-pairs, class maps, policy maps, and service policies.
An interface can belong to only one zone; traffic within the same zone is allowed by default.
The default action for a zone-pair is to drop all traffic unless a matching class map with an allow action (inspect or pass) is defined.
Use `inspect` for stateful inspection; use `pass` for stateless allow (return traffic not automatically permitted).
Apply the service policy to the zone-pair, not the interface.
The `self` zone represents the router itself; use zone-pairs with `self` to control traffic to/from the router.
Verify with `show zone security`, `show zone-pair security`, `show policy-map type inspect zone-pair`, and `show ip inspect sessions`.
These come up on the exam all the time. Here's how to tell them apart.
Zone-Based Firewall (ZBF)
Stateful inspection; tracks sessions
Zone-oriented; policies between zones
Default deny between zones
Uses class maps, policy maps, zone-pairs
Automatic return traffic handling
Classic ACL Firewall
Stateless; each packet evaluated independently
Interface-oriented; ACL applied inbound/outbound
Implicit deny at end of ACL
Uses access-list entries
Requires explicit permit for return traffic
Mistake
Zone-Based Firewall is the same as an ACL applied to an interface.
Correct
ZBF is stateful and zone-oriented. ACLs are stateless and applied per interface. ZBF inspects traffic and allows return traffic automatically, while ACLs require explicit permit statements for return traffic.
Candidates familiar with ACLs may think ZBF works similarly, but ZBF's zone-pair model is fundamentally different.
Mistake
You must create a class map for all traffic you want to allow, including return traffic.
Correct
Return traffic is automatically allowed when using the `inspect` action. You only need to define class maps for the initial traffic direction.
Candidates may think they need to create symmetric rules, but stateful inspection handles the reverse flow.
Mistake
Applying a service policy to an interface is the correct way to activate ZBF.
Correct
Service policies are applied to zone-pairs, not interfaces. Interfaces are assigned to zones, and the zone-pair defines the direction.
This is a carryover from older firewall configurations where policies were applied to interfaces.
Mistake
The `pass` action provides stateful inspection.
Correct
`pass` allows traffic without creating a session. Return traffic is not automatically allowed unless another rule permits it. `inspect` provides stateful inspection.
The word 'pass' might imply it's a full allow, but it is stateless.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`inspect` performs stateful inspection: it creates a session entry and allows return traffic automatically. `pass` allows traffic statelessly; it does not create a session, so return traffic is not automatically permitted. Use `inspect` for most traffic to leverage stateful filtering. Use `pass` only for traffic that does not require state tracking (e.g., IPsec ESP) or when you want to bypass inspection for performance reasons.
Create a zone-pair from OUTSIDE to INSIDE (e.g., `zone-pair security OUTSIDE-IN source OUTSIDE destination INSIDE`). Then create a class map that matches HTTP traffic (e.g., `match protocol http`). In the policy map, assign `inspect` to that class. Apply the policy to the zone-pair. Also ensure the internal server's interface is in the INSIDE zone.
Yes, you can use an ACL to match traffic. For example: `access-list 100 permit tcp any any eq 80` and then `class-map type inspect match-all HTTP-ACL` with `match access-group 100`. This allows more granular matching beyond protocol.
The `self` zone represents the router itself. Use it to control traffic to/from the router, such as SSH, SNMP, or routing protocols. For example, to allow SSH from inside, create a zone-pair `INSIDE-SELF` with a policy that inspects SSH. To allow the router to ping outside, create a zone-pair `SELF-OUTSIDE` with a policy that inspects ICMP.
Use `show ip inspect sessions` to see active stateful sessions. Use `show policy-map type inspect zone-pair` to see the applied policies. Use `show zone security` and `show zone-pair security` to verify zone configuration. You can also use `debug ip inspect detailed` for real-time inspection (use with caution).
Traffic between interfaces in the same zone is allowed by default without inspection. If you want to block intra-zone traffic, you must apply an ACL on the interface or use a self-zone policy (but self-zone is for traffic to/from the router, not between interfaces).
No, only one service policy can be applied to a zone-pair. However, a single policy map can contain multiple class maps with different actions. If you need different policies for different traffic types, combine them into one policy map.
You've just covered Lab: Configure Zone-Based Firewall — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?