Hands-On Lab: Configuring a Zone-Based Firewall

This hands-on lab configures a Cisco IOS Zone-Based Firewall between an inside and outside zone, defining a security policy permitting outbound-initiated traffic while blocking unsolicited inbound connections, and verifies stateful return traffic is handled automatically.

Zone-Based Firewall ConfigurationSecurity Zone PairingStateful Inspection

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure two security zones on a router, assign interfaces to each, define a class-map and policy-map inspecting traffic from the inside zone to the outside zone, apply it to a zone pair, and verify outbound connections work while unsolicited inbound connections are blocked.

Lab Purpose

The ACLs covered extensively earlier in this series are stateless — permitting return traffic requires either a separate explicit rule or relying on the ACL's own limited state tracking via the established keyword. The Zone-Based Firewall (ZBFW) provides genuine stateful inspection, automatically permitting return traffic for any connection initiated from a trusted zone without needing a matching inbound rule.

Lab Topology

R1
  Gi0/0 (INSIDE zone): 192.168.240.1/24
  Gi0/1 (OUTSIDE zone): 203.0.113.60/30

Goal: hosts on the inside can initiate
connections outbound; unsolicited inbound
connections from outside are blocked

Task 1: Configure Basic Addressing

Configure both interfaces as shown.

Task 2: Create the Security Zones

Create zones named INSIDE and OUTSIDE, and assign the respective interfaces to each.

Task 3: Define a Class-Map and Policy-Map for Inspection

Create a class-map matching all traffic, and a policy-map applying stateful inspection to it.

Task 4: Create the Zone Pair and Apply the Policy

Create a zone pair from INSIDE to OUTSIDE and apply the inspection policy to it.

Task 5: Verify Outbound Connections Succeed

Confirm a host on the inside can successfully reach an external server.

Task 6: Verify Unsolicited Inbound Connections Are Blocked

Confirm an external host cannot initiate a new connection toward an inside host.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.240.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.60 255.255.255.252
R1(config-if)# no shutdown

R1(config)# zone security INSIDE
R1(config-sec-zone)# exit
R1(config)# zone security OUTSIDE
R1(config-sec-zone)# exit

R1(config)# interface gigabitethernet0/0
R1(config-if)# zone-member security INSIDE
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# zone-member security OUTSIDE

R1(config)# class-map type inspect match-any INSIDE-TO-OUTSIDE-CLASS
R1(config-cmap)# match protocol tcp
R1(config-cmap)# match protocol udp
R1(config-cmap)# match protocol icmp

R1(config)# policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
R1(config-pmap)# class type inspect INSIDE-TO-OUTSIDE-CLASS
R1(config-pmap-c)# inspect

-- "inspect" is what enables stateful
-- tracking -- it remembers connections
-- initiated in this direction so return
-- traffic is automatically permitted

R1(config)# zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE
R1(config-sec-zone-pair)# service-policy type inspect INSIDE-TO-OUTSIDE-POLICY

InsidePC (192.168.240.10)> curl http://[external server]

-- Successful HTTP connection

R1# show policy-map type inspect zone-pair sessions

Zone-pair: IN-TO-OUT
  Class-map: INSIDE-TO-OUTSIDE-CLASS
    tcp connections: 1
      Established Sessions
        192.168.240.10:52341 -> [ext-server]:80 ...
-- The connection is tracked statefully,
-- confirming return traffic is being
-- automatically permitted

ExternalHost> curl http://192.168.240.10

-- Connection times out
-- No zone pair exists in the reverse
-- direction (OUTSIDE to INSIDE), so
-- unsolicited traffic initiated from
-- outside has no policy permitting it
-- and is dropped by default

Key Takeaway

ZBFW's default behavior between any two zones is deny-all unless an explicit zone pair and policy exist for that specific direction — configuring only an INSIDE-to-OUTSIDE zone pair with inspect automatically and statefully permits the return traffic for connections initiated inward, while leaving unsolicited outside-to-inside traffic blocked by the implicit inter-zone deny, all without needing a second, separate zone pair in the reverse direction.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue