Home > Security > Cisco Zone Based Firewall

Cisco Zone Based Firewall

In this post I will talk about Cisco Zone Based Firewall (ZBF) which is a new approach to configure access control in the IOS firewall. I will first make an introduction to ZBF and then I will demonstrate how to configure it.

To illustrate the different examples in this post I will use the following topology:


 Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services.

 Side note: As I am using IOS 12.4(15)T I will only talk about ZBF rules for this IOS release. Some improvements and rules changes have been made in the last IOS releases (IOS 15.X).

 IP addressing: All routers in the topology are configured with loopback IP in the format X.X.X.X /32 where X is the router number.

Introduction to ZBF

 Before this feature, firewalling in IOS was configured using a combination of ACLs and inspection rules (CBAC), both applied directly to interfaces which may poorly reflect organization´s security policy. With Zone Based Firewall (ZBF) different interfaces are grouped into zones, sharing the same security attributes, the same level of trust. The router itself is in a zone per default called the self zone. Here are the important facts about ZBF: (for IOS 12.4(15)T):

  •  Interfaces in the same zone can communicate with each other
  • Interfaces in different zones cannot communicate with each other by default
  • Traffic from and to the self zone to any other zone is allowed by default to allow for control plane and management traffic
  • ZBF implements the same set of features as CBAC
  • ZBF configuration uses a configuration framework called Cisco Policy Language (CPL) similar to MQC used for configuring QoS for example
  • ZBF can inspect, pass, drop or rate limit traffic
  • Class-map type inspect are used to match the traffic that the Firewall should inspect, pass, drop or rate-limit
  • Policy-map type inspect are used to set an action (pass, inspect, rate-limit or drop) on the traffic matched in the class-map
  • Zone-pair are used to define the traffic flow direction.
  • If the inspect keyword is used in a policy-map then the class-map must have at least one “match protocol” statement to specify the protocols for inspection. Otherwise all protocols will be inspected
  • If a policy is applied for traffic from a zone to self zone, traffic from self zone to the other zone will be permitted but returning traffic may me blocked
  • Stateful inspection router-generated traffic is limited to TCP, UDP and ICMP and H.323. Application inspection (HTTP,FTP,Telnet, etc.) is not available for self-zone policies.
  • Rate-limiting cannot be configured on self-zone policies
  • Stateful inspection support for multicast traffic is not supported between any zones, including the self zone

ZBF Configuration

 Let´s assign each interface to a zone as illustrated by the topology. To demonstrate that interface in the same zone can communicate with each other’s I will assign R2 and R4 in the zone inside. To test will ping from R2 to R4:

Let´s ping:

Perfect! Now let´s assign R4 to zone outside and ping again:

Alright, that demonstrates that interfaces in different zone cannot communicate with each other´s.

The router itself is a member of the self zone and by default this zone is not limited from communicating with other zones. Although we cannot ping anymore from R2 to R4 as they are in different zones, the router can still ping to zone inside and outside:

Let´s assign R3 to the DMZ zone:

Perfect! So now let´s define the following security policy:

1) R1 should only be managed from the outside zone using the following protocols: Telnet, SSH and HTTP. Furthermore ICMP to R1 coming from the outside should be allowed.

2) Only Inside user (represented in this example by the loopback of R2) is allowed to surf the Internet (represented by R4) using HTTP and to send DNS request to the Internet. Telnet and SSH to the Internet should also be allowed

3) Outside user (represented by R4 loopback) is allowed to reach the DMZ server (represented by R3) on port 80 as well as ping it

4) ICMP and telnet originated by the router itself should be permitted to any zone

Let´s start by implementing the 1 policy requirement which is about the self zone and the outside zone. The flow direction is from outside to self. Only Telnet, SSH, HTTP and ICMP are allowed. So let´s configure the following:

ZBF policy 1

So let´s test to SSH to R1 from R4:

On R1 we can see that the ZBF is matching SSH packets and pass them:

But what happen if we telnet from R1 to R4:

So R1 is blocking the returning traffic when originated from R1 itself. So if we wanted to allow returning traffic we could create a new policy inspecting TCP, UDP and ICMP (as self zone does not allow for advanced application inspection) from self zone to outside zone. As we are only passing traffic in our example there is no inspection.

Side note: Please not that although we are passing traffic from out to self the returning traffic from the router is automatically allowed back as we have not configured any zone-pair from self to outside.

Side note 2: Another point here is that we didn´t explicitly allowed EIGRP traffic in the policy but the neighbor relationship between R1 and R4 is still up and running. I guess that may be an issue related to the IOS version I am using or maybe related to GNS3.

ZBF policy 2

Perfect! Let´s implement policy number 2. The policy states that inside user ( -> R2 loopback) is allowed to surf the internet (represented by R4), send DNS query to the outside as well as using telnet and SSH. Let´s configure the following to reflect this policy:

In the above configuration we are using class-map nesting in order to achieve an advanced matching. Here in the ACL we used permit ip but we could have been more specific by only allowing TCP,UDP and ICMP. But as we are only inspecting certain type of traffic it is alright.

So let´s try to make a DNS request. R4 is configured as the DNS server:

So R4 is resolving the DNS query and R2 can then telnet to R4. R1 is allowing both the DNS query and the telnet session as we are inspecting these two protocols in our policy:

The output above confirm that R1 is inspecting both sessions (DNS and TELNET), allowing return traffic from outside to inside zone.

ZBF policy 3

Let´s implement policy number 3 which states that outside user (represented by R4 loopback is allowed to reach a DMZ server via TCP on port 80 as well as ping it. All other traffic from this user towards the DNS or the INSIDE zone should be denied. So let´s configure the following to reflect this policy:

Again here we are nesting a class-map in another in order to achieve our goal. The ACL only allowed TCP traffic and ICMP from R4 to R3 and we are only inspecting HTTP and ICMP traffic which means that traffic which is TCP but not HTTP will be dropped by the class-default. Let´s test it:

To test we just copy the running-config of R3 located in flash to null via HTTP:

So we can see that HTTP traffic is being inspected and it is allowed from outside to the DMZ zone. However as we inspect only HTTP traffic, a telnet to R3 will not work as it is not seen as HTTP traffic even if it is TCP traffic:

Let´s ping:


 ZBF policy 4

 So let´s implement the last policy which concerns telnet and ping traffic originated from the router itself should be allowed to any zone. So let´s configure the following to reflect this policy:

Here basically as self zone can only inspect on ICMP, TCP, UDP and H,323 we are forced to use a combination of ACL and inspection on TCP and ICMP. If traffic is permitted by the ACL (telnet and ICMP) and the protocol is ICMP or TCP, let the traffic through and inspect TCP and ICMP sessions. So here we are doing basic inspection traffic. Let´s test:

The same will work for telnet but not SSH for example:

The SSH session is effectively dropped as only telnet is inspected.

So now we have implemented our security policy so let´s see what other features ZBF offers:

ZBF Rate Limiting

Let´s see some facts about ZBF rate-limiting first:

  • Rate-limiting applies only for traffic moving between zones and not out/in of a single interface
  • Use the syntax police rate <RATE> <BURST> under a policy-map
  • Traffic exceeding is dropped
  • ZBF also supports rate-limiting for limiting the max number/rate of half-open connections for UDP/TCP sessions. This configuration is achieved using a parameter-map which you apply to the inspected traffic for a specific class
  • Not supported for zone self

Here I will just demonstrate how to configure ZBF for rate-limiting between security zones.

For example we could limit the amount of ICMP traffic sent from the OUTISDE zone to the DMZ zone. So let´s say that no more than 128 Kbit/s of ICMP traffic should be allowed from the OUTSIDE zone to the DMZ zone.

From the earlier configuration tasks we have already defined the following policy-map for traffic flowing from the OUTSIDE zone the the DMZ zone:

So we just modify the above configuration and add the following line:

So let´s test the above configuration:

So when pinging from R4 to R3 with packet size of 1000 Bytes and timeout of 2 seconds we get the result from the output above where 5 packets of size 1000 Bytes each are sent, then a timeout of 2 seconds and 5 packets of size 1000 Bytes each are sent and so on. If we want to get a more accurate rate close to 128 Kbps we would change the burst value to be higher.

We can also check the statistics on R1:

Another feature of ZBF is to be able to do application inspection (Level 7 of the OSI models) which I will not develop in this post. Thanks to this feature you can do granular inspection filtering for example on GET/POST for HTTP or filter HTTP GET requesting a file called image.jpg. Application inspection uses a special type of class-map and policy-map in the format: class-map type inspect <PROTOCOL NAME>. The same apply to policy-map. This special type of policy-map must call the special type of class-map and be nested as a child policy under the normal inspect policy map.

 Side note: In the version I am using (12.4(15)T11), only the following application are supported for deep inspection:




P2P Application Traffic (eDonkey, Kazaa2, GNUtella etc)

IM Applications



Thanks for reading!


  1. hassan
    May 13, 2013 at 07:45

    nice demonstration ….

  2. Guga
    November 10, 2013 at 04:51

    Laurent you know man I got pissed off because that subject was the only thing that I hadn’t studied for the CCIE lab exam lol. And one question of ZFW was in my TS exam……..and I failed. (of course not only by that one…..I made some mistakes in others questions too)

    But thanks to you I’m learning ZFW very well. Thank you mate and congrats on your exam.

    • November 10, 2013 at 09:38

      Thanks a lot for your feedback and very good luck for next try;-)


  3. March 13, 2014 at 00:08

    In the ZBF policy 4 (the zone pair from self to OUTSIDE to allow telnet/icmp), I noticed that there was not a policy map in the config. Should the following be added:

    policy-map type inspect SELF->OUTSIDE_PM
    class type inspect SELF->OUT_CM
    class class-default
    drop log

  4. ersan
    April 17, 2014 at 00:08

    For the ZBF Policy 4, on the R1 configuration, you don’t show the Policy-map configuration. You have the class-maps, zone-pair configs but not the policy-map. Will be good to fix it 😉

    Thanks for this article. It is really useful and it made me feel like I know this technology.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: