# Lab: Configure Zone-Based Firewall

> Chapter 253 of the Courseiva CCNA curriculum — https://courseiva.com/learn/ccna/lab-zone-based-firewall

**Official objective:** 5.7 — CCNA 200-301 v2.0 Objective 5.7

## Introduction

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.

## The Embassy Security Checkpoint

A secure embassy building, multiple entrances for staff, visitors, and 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).

## Core explanation

### 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

1. **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.

2. **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.

3. **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.

4. **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.

5. **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 statistics
```

Example output for `show zone security`:

```
Router# show zone security
zone INSIDE
  member interfaces: GigabitEthernet0/0
zone OUTSIDE
  member interfaces: GigabitEthernet0/1
```

Example 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-POLICY
```

Example 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)
      Drop
```

### How 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.

## Real-world context

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`.

## Exam focus

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:

1. **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.

2. **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.

3. **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.

4. **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.

## Step by step

1. **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`.
2. **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`.
3. **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`.
4. **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`.
5. **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).
6. **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`.

## Comparisons

### Zone-Based Firewall (ZBF) vs Classic ACL Firewall

**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

## Common misconceptions

- **Misconception:** Zone-Based Firewall is the same as an ACL applied to an interface. **Reality:** 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.)
- **Misconception:** You must create a class map for all traffic you want to allow, including return traffic. **Reality:** 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.)
- **Misconception:** Applying a service policy to an interface is the correct way to activate ZBF. **Reality:** 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.)
- **Misconception:** The `pass` action provides stateful inspection. **Reality:** `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.)

## Key takeaways

- 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`.

## FAQ

**What is the difference between `inspect` and `pass` in Zone-Based Firewall?**

`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.

**How do I allow traffic from the outside to an internal web server using ZBF?**

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.

**Can I use an ACL inside a class map for ZBF?**

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.

**What is the `self` zone and when do I use it?**

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.

**How do I verify that ZBF is working and see active sessions?**

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).

**What is the default behavior for traffic within the same zone?**

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).

**Can I have multiple service policies on the same zone-pair?**

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.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/ccna/lab-zone-based-firewall