Zone-Based Firewall (ZBF) is Cisco's next-generation stateful firewall approach that moves beyond the limitations of classic CBAC (Context-Based Access Control). On the CCNA 200-301 exam (Objective 5.7), you must understand how ZBF uses security zones to enforce traffic policies with stateful inspection, application awareness, and advanced protection. In real networks, ZBF is the go-to firewall solution on Cisco routers and ISRs, replacing ACL-only perimeter controls with granular, zone-to-zone policy enforcement.
Jump to a section
Imagine a corporate office building with three distinct areas: the public lobby (Zone A), the general office floor (Zone B), and the secure server room (Zone C). Each zone has its own access rules. The building's security system is the Zone-Based Firewall. A visitor (traffic) entering from the street (Zone A) can walk freely into the lobby (Zone A to Zone A is allowed by default). But to go from the lobby to the office floor (Zone A to Zone B), they must pass through a security checkpoint (the firewall policy). The security guard inspects their ID, checks a list of allowed visitors, and creates a temporary badge (stateful session entry) that allows them to move within the office for a specific time. Once inside the office (Zone B), the visitor can access the break room and common areas, but not the server room (Zone B to Zone C is blocked unless explicitly permitted). The guard remembers each visitor's entry and exit, ensuring that only legitimate traffic flows and that responses are allowed back. If a visitor tries to go from the server room back to the lobby without having entered first, the guard blocks it (asymmetric routing or spoofed traffic). The guard also inspects the contents of briefcases (application inspection) to prevent weapons (malware) from entering. This zone-based approach is more secure than a simple list of allowed people (ACL) because it enforces context and state, just like ZBF enforces stateful inspection and application awareness between security zones.
What is Zone-Based Firewall and Why Does It Exist?
Zone-Based Firewall (ZBF) is a stateful firewall feature on Cisco IOS routers that provides advanced traffic filtering and inspection based on security zones. Unlike classic CBAC, which inspects traffic on an interface-by-interface basis, ZBF groups interfaces into zones and applies policies between zones. This simplifies configuration, improves scalability, and allows for more granular control. ZBF is designed to protect internal networks from external threats while permitting legitimate traffic, and it is a key component of Cisco's security architecture for branch offices and enterprise edge routers.
How ZBF Works Step-by-Step at the Packet Level
ZBF operates by defining three main components: zones, zone-pairs, and policy maps. A zone is a group of one or more interfaces that share a security level. Traffic between zones is subject to a zone-pair policy that specifies what traffic is allowed and what actions to take (inspect, drop, pass). Within the same zone, traffic is implicitly permitted.
When a packet arrives on an interface belonging to Zone A destined for an interface in Zone B, the router checks if a zone-pair exists for the direction A->B. If no zone-pair exists, traffic is dropped by default (implicit deny). If a zone-pair exists, the router applies the associated policy map. The policy map uses class maps to match traffic (e.g., by protocol, source/destination IP, port) and then applies an action: inspect (stateful inspection), drop (silently discard), or pass (allow without inspection).
For inspect action, the router creates a stateful session entry in the firewall table. Subsequent packets matching that session are allowed without re-evaluation. The session is tracked with timers: default TCP idle timeout is 3600 seconds, UDP idle timeout is 30 seconds, and ICMP timeout is 10 seconds. The router also performs application inspection for protocols like HTTP, FTP, and DNS to detect anomalies and enforce protocol conformance.
Key States, Timers, and Defaults
Default policy: Traffic between zones is denied unless explicitly permitted. Traffic within a zone is permitted.
Session timeouts:
TCP: 3600 seconds (1 hour) idle timeout; also has a half-open timeout of 30 seconds for incomplete TCP handshakes.
UDP: 30 seconds idle timeout.
ICMP: 10 seconds idle timeout.
Maximum sessions: Varies by platform; typically 128,000 on ISR 4000 series.
Application inspection: Enabled for common protocols; can be customized with parameter maps.
Logging: Syslog messages can be generated for dropped or allowed packets.
IOS CLI Verification Commands with Real Example Output
To verify ZBF configuration and operation, use the following commands:
show zone securityExample output:
Zone-pair: inside-outside
Source Zone: inside Zone: inside
Destination Zone: outside Zone: outside
Service-policy inspect: inside-outside-policyshow zone-pair securityExample output:
Zone-pair name inside-outside
Source Zone: inside
Destination Zone: outside
Service-policy inspect: inside-outside-policyshow policy-map type inspect zone-pairExample output:
Zone-pair: inside-outside
Service-policy inspect: inside-outside-policy
Class-map: HTTP (match-all)
Match: protocol http
Inspect
Session count: 25
Class-map: class-default (match-any)
Match: any
Dropshow firewall statisticsExample output:
Firewall statistics:
Sessions: 25
Half-open sessions: 2
Denied packets: 150
Inspected packets: 5000How ZBF Interacts with Related Protocols
ZBF works with NAT, VPN, QoS, and routing. When NAT is applied, ZBF inspects traffic after NAT translation. For VPN traffic, ZBF can inspect encrypted traffic if the decryption occurs before inspection (e.g., on a tunnel interface). ZBF also interacts with Cisco IOS IPS and Web Filtering features for enhanced security. It is important to order the service policy correctly: typically, ZBF inspection is applied before NAT and after routing.
Define Security Zones
First, create security zones using the `zone security` command in global configuration mode. Each zone represents a group of interfaces with similar security requirements. For example, create an 'inside' zone for trusted internal networks and an 'outside' zone for untrusted external networks. Zones are logical containers; they don't have inherent security levels like ASA security levels. Instead, policies between zones define the trust relationship. ``` zone security INSIDE zone security OUTSIDE ``` Zones can also be 'self' zone for traffic destined to the router itself, and 'default' zone for unassigned interfaces.
Assign Interfaces to Zones
Assign each interface to a zone using the `zone-member security` command under interface configuration. An interface can belong to only one zone at a time. Interfaces not assigned to any zone are part of the 'default' zone, which has no policies and thus traffic to/from them is implicitly denied (except for traffic to the router itself). ``` interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 zone-member security INSIDE ! interface GigabitEthernet0/1 ip address 10.0.0.1 255.255.255.0 zone-member security OUTSIDE ``` Now, any traffic between INSIDE and OUTSIDE zones will be subject to zone-pair policies.
Create Class Maps for Traffic Matching
Class maps define the traffic that will be matched by a policy. Use `class-map type inspect match-any` or `match-all` to categorize traffic based on protocols, ACLs, or other criteria. For example, to match HTTP traffic: ``` class-map type inspect match-any HTTP_TRAFFIC match protocol http ``` You can also use ACLs to match more specific traffic. ``` access-list 100 permit tcp any any eq 80 class-map type inspect match-any WEB_TRAFFIC match access-group 100 ``` Class maps are used in policy maps to apply actions.
Create Policy Maps with Actions
Policy maps associate class maps with actions: inspect, drop, or pass. Use `policy-map type inspect POLICY_NAME` and then specify actions for each class. The 'inspect' action enables stateful inspection. The 'drop' action silently discards packets. The 'pass' action allows traffic without stateful inspection (not recommended for most traffic). ``` policy-map type inspect INSIDE_TO_OUTSIDE class type inspect HTTP_TRAFFIC inspect class type inspect WEB_TRAFFIC inspect class class-default drop ``` The class-default catches all unmatched traffic; it is good practice to drop it.
Apply Policy to Zone-Pair
A zone-pair binds a source zone, a destination zone, and a policy map together. Use `zone-pair security ZONE_PAIR_NAME source ZONE1 destination ZONE2` and then apply the service-policy. ``` zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE service-policy type inspect INSIDE_TO_OUTSIDE ``` Now, traffic from INSIDE to OUTSIDE is inspected. Note: For traffic in the reverse direction (OUTSIDE to INSIDE), you need a separate zone-pair (if desired). Typically, you only allow inbound initiated traffic from inside to outside, and responses are allowed due to stateful inspection.
Verify and Test Configuration
Use `show zone security` and `show zone-pair security` to verify the configuration. Test by generating traffic (e.g., ping, HTTP) and check the firewall statistics with `show firewall statistics`. Ensure that allowed traffic is being inspected and that denied traffic is dropped. Use debug commands with caution: ``` debug zone-pair security ``` This shows real-time packet processing. Also, check logs for any denied packets. ``` show logging | include %FW- ``` Common issues: missing zone assignment, incorrect policy map, or misconfigured class maps.
Scenario 1: Branch Office Internet Access with Security
A branch office has an internal LAN (192.168.1.0/24) and a WAN connection to the Internet (DHCP-assigned IP). The network engineer configures ZBF to allow internal users to browse the web (HTTP/HTTPS) and use DNS, but block all inbound traffic from the Internet. The inside interface (Gig0/0) is assigned to the INSIDE zone, and the outside interface (Gig0/1) to the OUTSIDE zone. A policy map permits HTTP, HTTPS, and DNS from INSIDE to OUTSIDE with inspect action; all other traffic is dropped. This provides stateful inspection: return traffic from web servers is allowed because the firewall tracks sessions. The engineer also enables logging to monitor denied inbound attempts. Performance is adequate for up to 500 concurrent sessions on an ISR 1100 series. Misconfiguration: if the policy map accidentally has 'pass' instead of 'inspect', the firewall would not track sessions, and return traffic might be blocked by the implicit deny of the zone-pair (if no separate zone-pair for return direction).
Scenario 2: Data Center Segmentation
In a data center, multiple server zones exist: WEB zone (web servers), APP zone (application servers), and DB zone (database servers). ZBF is used to enforce strict micro-segmentation. For example, only WEB servers can initiate connections to APP servers on TCP port 8080, and only APP servers can connect to DB servers on TCP 3306. The engineer creates three zones (WEB, APP, DB) and zone-pairs: WEB->APP with inspect policy for port 8080, APP->DB with inspect policy for port 3306. All other inter-zone traffic is dropped. Intra-zone traffic (e.g., WEB to WEB) is implicitly allowed. This prevents lateral movement of threats. Performance considerations: on high-throughput data center routers (e.g., ASR 1000), ZBF can handle millions of sessions with hardware acceleration. Misconfiguration: if the zone-pair for APP->DB is missing, legitimate application traffic fails, causing application timeouts. The engineer uses 'show firewall statistics' to identify dropped packets.
Scenario 3: Guest Wi-Fi Isolation
A company provides guest Wi-Fi on a separate VLAN. The guest interface is assigned to a GUEST zone, and the corporate LAN to a CORP zone. ZBF is configured to allow guests only Internet access (HTTP/HTTPS/DNS) and block all traffic to the corporate network. Additionally, guests are allowed to communicate among themselves (intra-zone) for local services like printing to a guest printer. The engineer creates a zone-pair GUEST->OUTSIDE (Internet) with inspect policy for web traffic, and a zone-pair GUEST->CORP with drop policy. This ensures guests cannot access internal resources. Scaling: for a large conference with thousands of guests, the router must handle many short-lived sessions; tuning the UDP and TCP timeouts to lower values (e.g., 120 seconds for TCP) can free resources faster.
The CCNA 200-301 exam objective 5.7 focuses on understanding ZBF concepts, configuration steps, and verification. You are expected to know:
The difference between ZBF and classic CBAC: ZBF uses zones, CBAC uses interface-based inspection.
The three core components: zones, zone-pairs, and policy maps.
The default behavior: traffic between zones is denied; traffic within a zone is permitted.
The actions: inspect (stateful), drop, pass.
How to assign interfaces to zones using zone-member security.
How to create zone-pairs and apply service-policies.
Verification commands: show zone security, show zone-pair security, show policy-map type inspect zone-pair, show firewall statistics.
Common wrong answers and traps:
Confusing ZBF with ACLs: Candidates think that applying an ACL to an interface is enough for stateful inspection. Wrong: ACLs are stateless; ZBF provides stateful inspection. On the exam, if a question asks for stateful filtering between networks, choose ZBF over ACL.
Believing that traffic within a zone is denied: Wrong. By default, traffic within the same zone is allowed. This is a key difference from ASA firewalls where same-security-level traffic is blocked by default.
Thinking the 'pass' action provides stateful inspection: Wrong. 'Pass' simply forwards traffic without inspection; it does not create sessions. Return traffic must be explicitly allowed by another rule. Use 'inspect' for stateful behavior.
Forgetting to assign an interface to a zone: If an interface is not assigned to any zone, it belongs to the 'default' zone. Traffic to/from the default zone is implicitly denied (except to the router itself). This is a common misconfiguration.
Mixing up source and destination zones: A zone-pair is unidirectional. To allow traffic both ways, you need two zone-pairs. For example, for Inside->Outside and Outside->Inside, you need separate zone-pairs.
Decision rule for scenario questions: If the scenario involves stateful inspection between groups of interfaces, look for answers that mention zones, zone-pairs, and inspect actions. If the scenario only needs stateless filtering, ACLs may suffice. Also, remember that ZBF is configured on routers, not switches (though some switches support it).
ZBF uses security zones to group interfaces and enforce stateful inspection between them.
Default policy: traffic within a zone is allowed; traffic between zones is denied unless explicitly permitted.
Three core components: zones, zone-pairs, and policy maps (class maps + actions).
Actions: inspect (stateful), drop (silent), pass (no inspection).
Interfaces are assigned to zones with 'zone-member security' under interface config.
Zone-pairs are unidirectional; create separate zone-pairs for each direction.
Default session timeouts: TCP 3600s, UDP 30s, ICMP 10s.
Verification commands: show zone security, show zone-pair security, show policy-map type inspect zone-pair, show firewall statistics.
ZBF replaces CBAC and provides more scalable and manageable firewall solution on Cisco routers.
Common misconfiguration: interface not assigned to a zone, leading to implicit deny.
These come up on the exam all the time. Here's how to tell them apart.
Zone-Based Firewall (ZBF)
Uses security zones to group interfaces
Policy applied between zone-pairs
Supports application inspection with parameter maps
More scalable and easier to manage
Default deny between zones
Classic CBAC
Inspects traffic on a per-interface basis
Policy applied directly on interfaces with ip inspect
Limited application inspection
Less scalable, configuration becomes complex
Default permit on interfaces (if no inspect rule)
Mistake
ZBF is the same as an ACL applied to an interface.
Correct
ZBF is a stateful firewall that tracks sessions and allows return traffic automatically, while ACLs are stateless and require explicit permit rules for return traffic.
Candidates often think any filtering is an ACL; they miss the stateful nature of ZBF.
Mistake
Traffic between two interfaces in the same zone is blocked by default.
Correct
By default, traffic within a zone is permitted. This is a key ZBF behavior.
Candidates confuse ZBF with ASA firewalls where same-security-level traffic is blocked by default.
Mistake
The 'pass' action in ZBF provides stateful inspection.
Correct
'Pass' simply forwards traffic without creating a session; it does not inspect or track state.
The word 'pass' sounds like 'permit', leading candidates to assume it includes stateful tracking.
Mistake
A single zone-pair allows traffic in both directions.
Correct
Zone-pairs are unidirectional. To allow bidirectional traffic, you need two zone-pairs (one for each direction).
Candidates think of ACLs where a single permit statement can be bidirectional if applied appropriately.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
ZBF (Zone-Based Firewall) uses security zones to group interfaces and applies policies between zones. CBAC (Context-Based Access Control) applies inspection rules directly on interfaces. ZBF is more scalable and easier to manage because you define policies once per zone-pair rather than per interface. CBAC is older and less flexible. On CCNA, ZBF is the recommended approach.
Yes, ZBF can inspect application layer protocols such as HTTP, FTP, SMTP, DNS, and others. It uses application-specific inspection engines that can enforce protocol conformance and detect anomalies. You can also create custom application inspections using parameter maps.
The default action is determined by the class-default class. If you do not configure class-default, the default action is to drop the traffic. It is good practice to explicitly define class-default with a drop action to ensure no unintended traffic passes.
Yes, ZBF works with NAT. Typically, you apply ZBF inspection before NAT (on the inside interface) so that the firewall sees the original source IP. After inspection, NAT translates the address. The order of operations is: routing decision, then ZBF inspection, then NAT (if configured). Ensure that the zone membership is on the correct interface.
Use 'show zone security' to see zone-pair and policy bindings. Use 'show policy-map type inspect zone-pair' to see per-class statistics (session count, match count). Use 'show firewall statistics' for overall session and drop counts. Also, test with actual traffic and check logs with 'show logging | include %FW-'.
The default TCP idle timeout is 3600 seconds (1 hour). There is also a half-open timeout of 30 seconds for incomplete TCP handshakes. These values can be adjusted using parameter maps. On the exam, you might be asked to recall these default values.
No, an interface can belong to only one security zone at a time. If you need an interface to be part of multiple zones, you would need to use subinterfaces or VLANs, each assigned to different zones.
You've just covered Zone-Based Firewall (ZBF) — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?