In the three previous parts of our tutorial on Cisco Zone Based Policy Firewalls, we had the opportunity to review the configuration steps required in order to complete the zone based policy firewall configuration and to test it for configuration validation. The following steps were deemed necessary:

  1. Zones creation.
  2. Interface assignment to zones.
  3. Zone−pairs creation.
  4. Creation of class−maps that describe traffic and must have policy applied to it as it crosses from a zone to another zone.
  5. Creation of policy−maps to apply action(s) to your class−maps and traffic they have bundled in classes.
  6. Apply policy−maps to zone−pairs with the use of the service policy command.

Of importance is the fact that the order of configuration steps has significance and that at one point, when interfaces are assigned to zones they belong to, the existing network connectivity is disrupted and will get progressively restored as the policies get configured and properly applied. This is an important point in a production network where disruption needs to be planned carefully.

We will be using the same topology:

Four policies were established on “paper”, to govern the following four traffic directions:

* INSIDE_TO_OUSIDE
* INSIDE_TO_DMZ
* OUTSIDE_TO_DMZ
* DMZ_TO_INSIDE

After successfully completing the first three steps, we went on to consecutively configure and apply the class maps, policy maps, and service policies for each zone pair. As of now the first two zone pair policy configurations were already completed and tested. The next several sections will be dedicated to the class maps, policy maps and service policies to configure and apply to the zone pair OUTSIDE_TO_DMZ.

These can be verified with the various verification commands like show zone security, show zone-pair security commands.

We will take the third policy defined on “paper” earlier and use it to go through the creation of access control lists that will then be used by the class map(s) before the latter gets called by the policy map(s). The final step will feature the policy map(s) being applied to a zone pairing.

Let us start configuring the third policy as stated in our policy design in part I of this tutorial.

Policy 3

  • From the OUTSIDE zone, only ping and traceroute are possible to DMZ router only in the DMZ zone.
  • Access control list

    To describe the traffic types involved in this policy by the source and destination IP addresses and port numbers we will create, for the ping traffic, an access control list named ECHO_OUTSIDE_TO_DMZ as shown below:

    The access control list ECHO_OUTSIDE_TO_DMZ above describes traffic from a loopback interface on the OUTSIDE router to the loopback interface and the fe0/0 interface on the DMZ router. The same access control list also describes traffic from the fe0/0 interface on the OUTSIDE router to the loopback interface and the fe0/0 interface on the DMZ router.

    That configured access control list can now be viewed with the show ip access-lists ECHO_OUTSIDE_TO_DMZ command:

    For the traceroute traffic, an access control list named ICMP_OUTSIDE_TO_DMZ will be created as shown below:

    The access control list ICMP_OUTSIDE_TO_DMZ above describes traffic from a loopback interface on the OUTSIDE router to the loopback interface and the fe0/0 interface on the DMZ router. The same access control list also describes traffic from the fe0/0 interface on the OUTSIDE router to the loopback interface and the fe0/0 interface on the DMZ router.

    That configured access control list can now be viewed with the show ip access-lists ICMP_OUTSIDE_TO_DMZ command:

  • Class map

    As we are done with the access control lists that describe and select specific traffic types, the next step will involve class maps that will call the needed access control lists so as to put the selected traffic types into a specific class.

    In this case the class map created will be named ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP. The ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP class map will bundle the ECHO and ICMP traffic type as defined in the ECHO_OUTSIDE_TO_DMZ and ICMP_OUTSIDE_TO_DMZ into one class that will later be acted upon by a policy map.

    Once again, this class map is of type inspect so as to inspect and track sessions. And since the class map will be calling two different access control lists, these two access control lists will be put together in a logical “OR” operation with the match-any option in the class-map command.

    This is done from inside the class-map command:

    The class map ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP can be viewed with the show class-map type inspect ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP command.

    Our class map ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP is given the ID number 3.

    To see all other class maps already configured on this ZBPF router, we issue the less specific show class-map type inspect command.

    The first two class maps are the class maps configured for the first two policy maps to use in part II and part III of this tutorial. We can infer from what we see that the class map IDs are assigned incrementally as they are configured on the policy firewall. That’s why the class maps assigned in this part IV of the tutorial has an ID number 3.

  • Policy map

    After configuring the class map ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP in the previous section, we are now going to start configuring policy maps through which we will define action(s) to take on the traffic class defined by the mentioned class map. In our case, we will just define one meaningful action for this policy map: the inspect action. However we will keep in mind that for every policy map, there is an implicit class map (named class-default) at the bottom of the list of explicitly defined class maps with the drop action. For debugging purposes, the drop action in the class-default class map will be transformed into a “drop log” action so that we can see all dropped packets to make sure only intended packets are dropped.

    The following command is going to create the ECHO_ICMP_OUTSIDE_TO_DMZ_POLICY-MAP policy map on the ZBPF router.

    We then specify the class of traffic we want to apply an action to. The class map is called:

    And the inspect action is configured inside that ECHO_ICMP_OUTSIDE_TO_DMZ_CLASS-MAP.

    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 to class-map configuration mode inside the policy map.

    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 the policy number 3 requirements. However we still want to modify the drop action to drop log inside the implicit class-default class map.

    We first exit the class map:

    Before we go inside the class-default class map:

    And configure the drop log command which changes the implicit command from drop to drop log.

At the end we exit from the class map and then the policy map.

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

The do show policy-map type inspect ECHO_ICMP_OUTSIDE_TO_DMZ_POLICY-MAP command will let us see how the policy map looks like:

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.

We can see the list of configured policy maps so far in this tutorial by issuing the show policy-map command without the policy map name specified.

All three policy maps configured so far have the same structure.

  • Service policy

    In the same way the previous two policies (policy 2 and policy 3) were finally applied to their related zone pairs, the above policy map will be applied to the OUTSIDE_TO_DMZ zone pair.

    We first check the zone pair OUTSIDE_TO_DMZ to see its current configuration.

This command output shows us that no service policy is configured yet on this zone pair.

To remedy that, we go into the zone pair OUTSIDE_TO_DMZ:

And attach to the zone pair the policy map ECHO_ICMP_OUTSIDE_TO_DMZ through the service-policy command:

We can see now that the zone pair OUTSIDE_TO_DMZ has a policy applied to it as can be seen with the show zone-pair security source OUTSIDE destination DMZ:

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

Testing POLICY_3

To validate our configurations, we are going to use echo requests with ping and see if the desired connectivity is re-established.

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

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

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

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

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

But when we try from the OUTSIDE router to ping the INSIDE routers (HR-and-SALES and IT-and-RESEARCH), the ping tests fail for obvious reasons: our policies don’t include any traffic from the OUTSIDE zone to the INSIDE zone.

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

From OUTSIDE router loopback 1 interface we can’t ping the loopback 1 interface on the HR-and-SALES router:

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

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

The same failures will show up on test pings from OUTSIDE router to IT-and-RESEARCH.

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

From OUTSIDE router loopback 1 interface we can’t ping the loopback 1 interface on the IT-and-RESEARCH router:

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

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

After configuring the ECHO_ICMP_OUTSIDE_TO_DMZ_POLICY-MAP policy map and testing the policy map after it has been applied to the zone pair OUTSIDE_TO_DMZ we can use the monitoring commands to view what is happening with it.

The show policy-map type inspect zone-pair command will show all the three policy maps configured but we are showing only the third policy map (in red) for screen real estate reasons. Already we can see that the class-default class map is dropping packets.

The above show policy-map command can be extended to show us current sessions and their various statistics.

We will first trigger a long ping:

Before we see the current session status.

We are at the end of part IV of the Cisco Zone Based Policy Firewall tutorial and we have successfully configured and applied the ECHO_ICMP_OUTSIDE_TO_DMZ_POLICY-MAP policy map to the OUTSIDE_TO_DMZ zone pair to enforce our own established policy #3. Policy #4 will be completed in the next part of this tutorial. Keep watching this space.