As we start Part II of this tutorial on zone-based policy firewall, we shall first sum up what was completed in Part I of this tutorial:

  • Zones are created.
  • Zones are populated with the interfaces; or, in other words, the router interfaces are assigned to zones.
  • Zone pairs are created to reflect all possible traffic directions. The zone pairs are uni-directional, which means INSIDE_TO_OUTSIDE is not equivalent to OUTSIDE_TO_INSIDE.
  • No policies are yet configured
  • And, most important of all, the network is disrupted because for now no communication between zones is possible, although the routing is set and connectivity was fine before the interfaces were assigned to zones. This will be solved as soon as appropriate service policy configurations are applied to appropriate zone pairings.

Note that, for now, only the inter-zone connectivity is broken. Intra-zone connectivity is still working fine because intra-zone communications, by default, are not subject to policy enforcement unless specific pairing from same_zone_to_ same_zone (INSIDE_TO_INSIDE for example) is configured, in which case the IOS router applies configured policies.

In other words,

  1. Creating zones doesn’t impact previously established connectivity.
  2. Assigning interfaces to zones breaks that connectivity.
  3. Pairing zones and configuring service policies on the zones pairs will restore the connectivity that comply with new policies.

The currently configured zones can be verified with the verification command “show zone security“:

Notice the Self Zone

The “Managing Zone-Based Firewall Rules” document found at states the following:

The “self” zone is a default zone that defines the router itself as a separate security zone, which you can specify as either the source or destination zone. The self zone is the only exception to the default “deny all” policy. All traffic to any router interface is allowed until explicitly denied.

A zone-based firewall rule that includes the self zone applies to local traffic—that is, traffic directed to the router, or to traffic generated by the router; it does not apply to traffic through the router.

In this deployment example, we will leave the default zone self as is and no policy rules will be applied leaving its interfaces reachable by every other segments of the network.

Individual zones can be verified with the show zone security ZONE_NAME command

or the show zone security | section INSIDE command.

The zone pairings also can be verified with the verification command show zone-pair security.

The above screenshot shows us the four pairings corresponding to the four policies defined on “paper.” However, since the policy is not yet configured on the ZBPF router, the output tells us, for every policy, service-policy not configured.

The show zone-pair security can be refined to ask specific verification commands on your IOS command line interface, as seen below. The information is the same for a particular pairing, but this will be helpful in situations where we have numerous pairings and we don’t want to display all of them because they will fill our screen.

Inter-Zone Access Policy – Basic Configuration

The policy configuration step is itself composed of three steps:

  • Class maps configuration:

    Class maps use access control lists to select specific traffic type (e.g., SSH/HTTP traffic ) and virtually place them in a “pipe” so that policy maps can decide what action to take with them.

  • Policy maps configuration:

    Policy maps make decisions on what action to take with specific traffic going through a virtual “pipe” as created by a specific class map.

  • Service policy configuration:

    The service policy will finally apply the configured policy map to a specific zone pairing so that the policy is used on that zone pairing to decide what can go from one of these two paired zones to the other. Only when proper policy map is applied to a zone pairing will the traffic broken in the first place by the interfaces assignment to zones start to flow according to the new policy.

There is a complete elaborate language dedicated to class maps and policy maps configuration. The C3PL (Cisco Common Classification Policy Language) is focused on classification and is broadly used in CISCO QoS for traffic classification and marking. Its most important characteristics include modularity that makes easy to create complex policies.

As the scope of this tutorial is considerably smaller than the breadth of C3PL, we will see only a little C3PL action as we configure the class maps and policy maps.

To illustrate how inter-zone access policy basic configuration is made, we will take one by one the four policies defined on “paper” earlier and use them to go through the creation of access control lists that will be then be used by the class map(s) before the later get called by the policy map(s). The final step will feature the policy map(s) being applied to a zone pairing.

Let us start with the first policy, as stated in our policy design in part I of this tutorial.

Policy 1

  • From the inside zone, ping, traceroute and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to OUTSIDE router located in OUTSIDE.
  • Access control list

    This access control list will describe the source and destination IP addresses and port numbers of the traffic to classify with the upcoming class map(s).

    The access control list SSH_INSIDE_TO_OUTSIDE can be seen below. It takes care of all SSH connections from any place in the INSIDE zone to any place in the OUTSIDE zone.

    The access control list ECHO_INSIDE_TO_OUTSIDE will do the same for ping’s echo messages.

    The access control list ICMP_INSIDE_TO_OUTSIDE will do the same for traceroute’s ICMP messages.

  • Class map

    Now that the access control list helped us to specify traffic type we are interested in, let us configure the class map that will create a dedicated class for the said traffic type.

    Consider the class maps like color coding the different traffic types so that every traffic type defined by an access control list looks like one flow through an individually colored pipe. Multiple access control lists then create multiple parallel individually colored pipes: an individually colored pipe for SSH, another for ping’s echo, and another one for traceroute’s ICMP.

    If we call/bundle all these three access control list into our class map, this will be like bundling the three individually colored pipes together that we can call later with the policy map to decide the action to take on that bundled pipes.


    The match-any keyword in the command above means the multiple access control lists will be combined in an “or” operation, meaning any of those three traffic types that shows up will be bundled by the class map in one bundle that will be usable by a policy map to decide necessary actions.

    If the match-all keyword were used instead, that would mean that the access control lists should be handled in an “and” operation and for traffic to be in that class it would have to match all the conditions set in the three access control list.

    The inspect type keyword means this class map will be used to statefully inspect and track traffic sessions. The extended access control lists are tied to class maps of type inspect. Contrary to generic class-maps generally used by the QoS engines, the class-maps used for security feature like traffic inspection in zone based policy firewalls are of the type inspect.

    Below are the three access control lists being called / bundled in the class map:

    The verification command can show us what the class map looks like:

  • Policy map

    Now that traffic classification by type(s) is done, the class maps can be tied to policy maps that decide on the action to take on said traffic. Multiple class maps can be tied to one policy map.

    There is a default catch-all class map that is set to drop, pretty much like the usual implicit deny at the end of every access control list. However, this default catch-all class map can be edited to adapt its behavior from “drop” to whatever you like.

There are four possible actions for a policy map:

  • The generic PASS action: The router permits packets in this class to go from the source zone into the destination zone without stateful inspection.
  • The generic DROP action: The router simply denies and drops all traffic of this class. No inspection performed.
  • The LOG action, when combined with DROP, logs all denied packet in this class. A very useful action when troubleshooting.
  • The INSPECT action: Protocols of that class that can be statefully inspected are permitted.

The later action (INSPECT) is the right one for our case in point here, so let’s configure a policy map called SSH_ECHO_ICMP_INSIDE_TO_OUTSIDE_POLICY-MAP that will reference the SSH_ECHO_ICMP_CLASS-MAP class map and INSPECT all traffic in that class.

Let’s configure a class named class-default: the class-default class will log dropped packets for troubleshooting purposes:

  • Service policy

    Finally, the policy map will be applied to a particular zone pair to specify what action to take on a selected traffic type moving between the zone pair in a particular direction. A different policy map may be applied to other selected traffic on the same zone pair in the reverse direction.

Testing POLICY 1

From HR-and-SALES router loopback1 interface, we can ping and SSH to the loopback on OUTSIDE router:

The same is done from HR-and-SALES router to the FE0/0 on the OUTSIDE router:

From the IT-and-RESEARCH router, loopback1 interface we can ping and SSH to the loopback on OUTSIDE router:

The same is done from IT-and-RESEARCH router to the FE0/0 on the OUTSIDE router:

At this point in the deployment process, we have been able to properly configure a policy map SSH_ECHO_ICMP_INSIDE_TO_OUTSIDE_POLICY-M and apply it to the zone pair INSIDE_TO_OUTSIDE:

The said policy map is seen making use of the SSH_ECHO_ICMP_CLASS-MAP class map.

The SSH_ECHO_ICMP_CLASS-MAP class map is bundling three extended access control lists to select specific traffic type and put them in their own class that will be acted upon by the relevant policy map.

We can also see the inspect sessions information with the show policy-map type inspect zone-pair sessions command after a ping test as seen below.

The inspect session information shows that it is all about an ECHO request and that the whole session ended up with 288 bytes sent by both the initiator and the responder.

The same show policy-map type inspect zone-pair sessions command will show different information after an SSH command:

This time around, the inspect session information shows us an SSH (on Port 22) with the session (SIS_OPEN) created 1 minute. 30 seconds ago. The session information also says Last heard 00:01:21, which means that, as long as the SSH user is logged in, the inspect session will stay open.

As we close this Part II of the Cisco zone-based policy firewall, we will keep in mind that only one out of four policy rules we had established is completed. The next session will be dedicated to the remaining policy rules before we can be satisfied that a basic zone based policy firewall was deployed. Watch this space.