Welcome to part V of the tutorial on Cisco’s zone based policy firewall. As discussed in earlier installments of this tutorial, the zone based policy firewall is a feature of the Cisco IOS that allows us to configure and operate a firewall straight out of a generic IOS router as opposed to deploying a specialized hardware firewall like the ASA firewalls. By means of network segments grouping, also known as zones, the zone based policy firewall applies policies to zone pairs to create a stateful firewall that inspects outgoing traffic sessions to determine lawful return traffic sessions and allow them back in the origin zone.

The policies are created by the access control lists, class maps and policy maps that are finally used by the service policy command applied to zone pairs.

As of now, of the four policies that we have defined on “paper”, three are in place, tested and confirmed working. In this installment of the zone based policy firewall tutorial, we are going to focus on the fourth policy so as to have the basic zone based policy firewall in place. As in the earlier installments of this tutorial, the policy implementation will entail the use of access control lists and class maps that will be called by policy maps and service policy commands.

Before we embark on the configuration and deployment of policy #4, we can consecutively verify the configurations of the three policies implemented in earlier installments.

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

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

Or the show zone security | section INSIDE command:

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

The show zone-pair security command shows us that the zone-pair DMZ_TO_INSIDE, though defined, has no service policy configured and applied to it.

The show zone-pair security can be refined to ask specific verification commands to 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.

Let us go ahead and implement the fourth policy as stated in part I of this tutorial.

Policy 4

The fourth policy was defined on “paper” as:

  • From the DMZ zone, only SSH, ping, and traceroute are possible toward the routers in the INSIDE zone.
  • Access control list

    Let’s define the access control lists that 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 ECHO_DMZ_TO_INSIDE takes care of all ECHO connections from any place in the DMZ zone to any place in the INSIDE zone.

    The access control list ECHO_DMZ_TO_INSIDE can be seen below with the show ip access-lists command:

    The access control list SSH_DMZ_TO_INSIDE takes care of all SSH connections from any place in the DMZ zone to any place in the INSIDE zone.

The access control list SSH_DMZ_TO_INSIDE can be seen below with the show ip access-lists command:

The access control list ICMP_DMZ_TO_INSIDE takes care of all ICMP connections from any place in the DMZ zone to any place in the INSIDE zone.

The access control list ICMP_DMZ_TO_INSIDE can be seen below with the show ip access-lists command:

We are now done with configuring the access control lists ECHO_DMZ_TO_INSIDE, SSH_DMZ_TO_INSIDE and ICMP_DMZ_TO_INSIDE. In the next section we will deal with the class map configurations that will create a dedicated class for the traffic type we are interested in as selected by the three access control lists above.

  • Class map

As we bundle these three access control lists into our class map, this will make a single class made of the three traffic types as they were selected by the said access control lists.

Let’s go ahead and create the class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP.

We will remember that the match-any keyword in the command above means that multiple access control lists will be combined in an “or” logical operation as opposed to the match-all keyword that would mean the access control lists should be handled in an “and” logical operation. The extended access control lists are tied to class maps of type inspect which means this class map will be used to statefuly inspect and track traffic sessions.

The class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP will now call the access control lists SSH_DMZ_TO_INSIDE, ECHO_DMZ_TO_INSIDE and ICMP_DMZ_TO_INSIDE.

The verification command show class-map type inspect can show us how the class map is set on an IOS router.

As one would expect, the class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP has been assigned the ID number 4 since this class map is, chronologically speaking, the fourth class-map to be configured on this ZBPF. The same piece of information can be displayed with the show class-map
type inspect
SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP (with the class map name appended to it).

The class map configuration is now done and at this point in the configuration, we have put in their own class three traffic types (SSH, echo, and ICMP) as selected by the three access control lists SSH_DMZ_TO_INSIDE, ECHO_DMZ_TO_INSIDE and ICMP_DMZ_TO_INSIDE.

The next section will show us a policy map being configured and getting linked to a class map before an action command of type inspect specified for the said class map.

  • Policy map

The following policy-map command will create a policy map of type inspect named SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP.

Multiple class maps can be tied to one policy map but in our case we will be using only one class map.
Whether a policy map bundles one or more than one class map, there is always at the bottom of the list of class maps an implicit default catch-all class map that is set to drop. It’s 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 your liking. In our situation here, we will edit that default class to change the drop command to drop log for troubleshooting purposes. That way, traffic that doesn’t belong to any of the classes called by the policy map will be dropped and at the same time logged to the console. This should show us traffic we wanted to see through the firewall but is being dropped for misconfiguration reasons.

The following class command will tie the class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP to the policy map SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP.

To that class command, we will append the inspect command.

The last three commands imply that the policy map command applies the inspect action to any traffic that was selected by the three access control lists SSH_DMZ_TO_INSIDE, ECHO_DMZ_TO_INSIDE and ICMP_DMZ_TO_INSIDE and laterisolated in one class by the class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP.

The informational message upon the inspect command is in this situation just that. Informational! This informational message can be overlooked because even if the class map doesn’t specify the protocols to inspect, it is calling access control lists that specify the protocols affected, so we can confidently overlook this.

This class map called inside this policy map is the only manually configured class map needed to fulfill policy number 4’s requirements. However, we still want to modify the drop action to drop log inside the implicit class-default class map.

Note: Always notice the way the command line prompt changes from ZBPF(config) to ZBPF(config-pmap) to ZBPF(config-pmap-c) as we go from privileged configuration mode to policy-map configuration mode and finally to class-map configuration mode inside the policy map.

We first exit the class map:

And go inside the class-default class map:

To issue the drop log action command so as to transform the drop action command.

We now have in place the policy map to enforce policy 3 as defined on “paper”.

The show policy-map type inspect SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP command will let us see the configured policy map.

We see in this output, the policy map calling one class map SSH_ECHO_ICMP_DMZ_TO_INSIDE_CLASS-MAP and the inspect action invoked. The implicit class-default class map is also shown and its default drop action command was changed into a drop log action command.

To view the full list of configured policy maps at the same time, the shorter command show policy-map type inspect is invoked:

We can see the four policy map commands as configured to cater for the four policies that we defined on “paper” as the enforceable policies.

The structure of the policy map is clearly apparent. It is of the type inspect, calls one class map and applies to it the inspect action, and finally calls the class-default class map with the modified drop log action.

At this point in the configuration process, access control lists, class maps and a policy map have been configured properly but have not yet been applied to a zone pair with the service policy command.

This can be illustrated by the show zone-pair security source DMZ destination INSIDE command output:

To finalize policy #4 deployment, the policy map will be applied to the appropriate zone pair with the service policy command.

  • Service policy

The service policy will call the SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP policy map and apply it to the DMZ_TO_INSIDE zone pair.

We will now go into the zone pair DMZ_TO_INSIDE:

Use the service policy command to call the SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP policy map:

The zone pair DMZ_TO_INSIDE has a policy applied to it as can be seen with the show zone-pair security source DMZ destination INSIDE command:

All the necessary configurations for policy #4 to be enforced are in place (from access control list, to class maps and policy maps) and should be working now.

The next obvious steps should be testing policy #4.

Testing POLICY_4

To validate our configurations, we are going to use echo requests with ping and see if the desired connectivity is re-established. The tests will also check and validate SSH connections from the DMZ zone to the INSIDE zone.

We should be able to ping from the DMZ router to the HR-and-SALES and IT-and-RESEARCH routers. At the same time, the same ping echo requests from the DMZ router to the OUTSIDE router should be failing because no policy has been established and configured to permit that traffic type in that direction.

From the DMZ router loopback 1 interface we can ping the fe0/0 interface on the HR-and-SALES router:

From the DMZ router loopback 1 interface we can ping the loopback 1 interface on the HR-and-SALES router:

From the DMZ router fe0/0 interface we can ping the fe0/0 interface on the HR-and-SALES router:

From the DMZ router fe0/0 interface we can ping the loopback 1 interface on the HR-and-SALES router:

As for the IT-and-RESEARCH router:

From the DMZ router loopback 1 interface we can ping the fe0/0 interface on the IT-and-RESEARCH router:

From the DMZ router loopback 1 interface we can ping the loopback1 interface on the IT-and-RESEARCH router:

From the DMZ router fe0/0 interface we can ping the fe0/0 interface on the IT-and-RESEARCH router:

From the DMZ router fe0/0 interface we can ping the loopback 1 interface on the IT-and-RESEARCH router:

However, from DMZ zone to OUTSIDE zone, no ping will work because there is no policy configured to allow such traffic type.

From the DMZ router loopback 1 interface we can’t ping the fe0/0 interface on the OUTSIDE router:

From the DMZ router loopback 1 interface we can’t ping the loopback 1 interface on the OUTSIDE router:

From the DMZ router fe0/0 interface we can’t ping the fe0/0 interface on the OUTSIDE router:

From the DMZ router fe0/0 interface we can’t ping the loopback 1 interface on the OUTSIDE router:

Let us go ahead now and test the SSH connections from the DMZ router to both of the HR-and-SALES routers.

From the DMZ router we can SSH into the fe0/0 interface on the HR-and-SALES router:

And into the loopback 1 interface on the HR-and-SALES router:

From the DMZ router we can SSH into the fe0/0 interface on the IT-and-RESEARCH router:

And into the loopback 1 interface on the IT-and-RESEARCH router:

However, from DMZ zone to OUTSIDE zone, no SSH will work because there is no policy configured to allow such traffic type.

From the DMZ router we can’t SSH into the fe0/0 interface on the OUTSIDE router:

Or into the loopback 1 interface of the OUTSIDE router:

As we close part V of this tutorial on zone based policy firewall, we can confirm that we have successfully configured and applied the SSH_ECHO_ICMP_DMZ_TO_INSIDE_POLICY-MAP policy map to the DMZ_TO_INSIDE zone pair to enforce our own established policy #4. All of the four policies we have set were deployed on our ZBPF router to put up a basic zone based policy firewall out of a generic IOS router. However, there are many aspects of the ZBPF firewall that weren’t covered in this entire tutorial as this topic is very broad and rich in features. Let’s hope we will have more opportunities to see some of these features in the future.