Female Voice: “Don’t tell me which zone’s for stopping and which zone’s for loading!
Male Voice: “Listen, Betty, don’t start your white zone sh*t again. There is just no stopping in the white zone.” – Airplane 1980

In an earlier blog post, we introduced you to the IOS Zone-Based Firewall from Cisco Systems. You can find that post here if you need it.
This post will walk you through an example of the Zone-Based Firewall at the command line. Here is the simple topology we will use in this example:


For this example, we will pretend the R1 device is in the Inside, private, protected network. R3 represents a device in the Outside, public, unprotected Internet. R2 in the middle will be our IOS Zone-Based Firewall. We want to inspect Telnet traffic sourced from the Inside network traveling to the Outside network, and we want to dynamically permit return traffic back in from the Outside based on session information.

From our first blog post on this topic, we recall the four steps of this configuration:

  • Step 1 – Define and populate zones.
  • Step 2 – Define the class maps that identify traffic that is permitted between zones.
  • Step 3 – Configure a policy map that specifies actions for the traffic.
  • Step 4 – Configure the zone pair and apply the policy.

Now that we have reviewed the steps of this configuration, let us begin.

Step 1: Define and populate our zones:

R2(config)#zone security ZONE_PRIVATE
R2(config-sec-zone)#zone security ZONE_INTERNET
R2(config-sec-zone)#interface fa0/0
R2(config-if)#zone-member security ZONE_PRIVATE
R2(config-if)#interface fa0/1
R2(config-if)#zone-member security ZONE_INTERNET

Step 2: Define the class maps that identify traffic that is permitted between zones:

R2(config)#class-map type inspect match-any CM_INTERNET_TRAFFIC
R2(config-cmap)#match protocol telnet

Step 3: Configure a policy map which specifies the action for the class map:

R2(config)#policy-map type inspect PM_PRIVATE_TO_INTERNET
R2(config-pmap)#class type inspect CM_INTERNET_TRAFFIC

Step 4: Configure the zone pair and apply your policy:

R2(config)#zone-pair security ZONEP_PRIV_INT source ZONE_PRIVATE destination ZONE_INTERNET
R2(config-sec-zone-pair)#service-policy type inspect PM_PRIVATE_TO_INTERNET

Now it is time for some verification. Can we ping through the firewall (R2) and get a response from R3? We would expect this to fail since we are not inspecting ICMP traffic.

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

Can we Telnet to this same address on R3? We would expect this to work thanks to the inspection of Telnet traffic.

Trying ... Open
User Access Verification

Can we Telnet from R3 (Outside) into R1 (Inside)? No we cannot:


Trying ...

Connection timed out; remote host not responding


Now for a further verification, let us examine R2.

R2#show policy-map type inspect zone-pair

We will use a very powerful command:

R2#show policy-map type inspect zone-pair
Service-policy inspect : PM_PRIVATE_TO_INTERNET
Class-map: CM_INTERNET_TRAFFIC (match-any)
Match: protocol telnet
5 packets, 120 bytes
30 second rate 0 bps
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:40]

Looking for more information on this Version 4.X feature, or many others? check out these products:

Thanks for reading – and happy studying!

You can leave a response, or trackback from your own site.

7 Responses to “CCIE R&S 4.X: Zone-Based Firewall Tier 1”

  1. Hello,

    Maybe you should have used their names, Dick and Jane. :o )

  2. VOICENY says:

    @Joshua hehehehehehehehe

    Thanx, great post.

  3. Giorgio P. says:

    Thanks, another great effort.
    I was just wondering when you will be starting to upgrade the CCIE written COD to ver 4.0.

  4. Rizzo says:

    Thanks for simple and to the point tutorial


    Guys, You can do same tutorial with Cisco PacketTracer 5.2 :)

  5. Carlo says:

    Thanks for the article. But I must say that this new Zone Based FW is quite a work of ART literally! What was Cisco thinking! It sounds like a nightmare. I would probably never implement this in production. It’s just tying together a set of already horrible IOS FW features when compared to ASA or FWSM. The only benefit is that you can group multiple interfaces, which is not a big deal. I would much rather deal with extended/reflexive access lists. But none the less great article.


Leave a Reply


CCIE Bloggers