In part I of this tutorial, we focused on defining (according to the policies we made) different zones on different sides of the Zone Based Policy Firewall. The different interfaces on the zone based policy firewall were assigned to the different zones they belonged to. This was followed by the zone pairing exercise to define the various possible traffic directions going from one given zone to another zone. We also noted how assigning an interface to a zone disrupted all traffic crossing that interface until the proper policies were defined and applied to the zone based policy firewall.

In the second part of this tutorial we saw, for one specific policy on “paper”, how to create extended access control lists that will be used by class maps to define specific traffic classes. The latter were then called by policy maps for defined action(s) to be applied to the said traffic classes. Finally the policy maps were subsequently applied to zone pairs to specify the traffic directions on which the policy maps were to be enforced.

Since of the four policies we had defined only one was completely translated in real world policy map to apply to the INSIDE_TO_OUTSIDE zone pair, we are going to go on and apply the same techniques to the second policy and configure the class maps, policy maps and service policy to apply to the INSIDE_TO_DMZ zone pair.

Policy 2

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

    Let us configure the access control lists that will let us describe the source and destination IP addresses and port numbers of the traffic to put in classes with the class maps that will subsequently follow.

    The access control list SSH_INSIDE_TO_DMZ defines SSH connections from places in the INSIDE zone to places in the DMZ zone. It can be seen below thanks to the show ip access-lists SSH_INSIDE_TO_DMZ command:

To do the same for the ping commands, we will need the following access control list:

The access control list ECHO_INSIDE_TO_DMZ defines ping’s echo tests from places in the INSIDE zone to places in the DMZ zone. It can be seen below thanks to the show ip access-lists ECHO_INSIDE_TO_DMZ command:

To do the same for traceroute’s tests from the inside zone to the DMZ zone, let us create the following access control lists:

The access control list ICMP_INSIDE_TO_DMZ defines traceroute’s tests from places in the INSIDE zone to places in the DMZ zone. It can be seen below thanks to the show ip access-lists ICMP_INSIDE_TO_DMZ command:

  • Class map

    After the access control lists are configured, we have now a tool in place to select specified traffic types by their source and destination characteristics and even by their protocol types. In our case, the three access control lists created in the sections above can now be bundled in one class map that will be used later by a single policy map that will apply to them a single action, namely the “inspect” action.

    Let’s go ahead and create the class map that will bundle the three access control lists and define one traffic class. The class map SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP will call the access control lists SSH_INSIDE_TO_DMZ, ECHO_INSIDE_TO_DMZ and ICMP_INSIDE_TO_DMZ:

    We will notice that, as in the previous articles, the class map of type inspect to tell the IOS this class map will be used to statefuly 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 features like traffic inspection in zone based policy firewalls are of the type inspect. The match-any option tells the IOS that the access control lists called by this class map will be combined in a logical “or” operation.

    We will now, from inside the class map, call the three access control lists that interest us.

    To see how the class map SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP looks like, we use the show class-map type inspect SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP command:

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

    We can also see in the show class-map command output that the class map ID is shown. Our class map inspect SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP is given the ID number 2.

  • Policy map

    The policy map we are going to configure now will be used to define the action to take for the traffic type defined with the class map SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP. Suffice it to remind us that the policy map command allows four different possible actions: pass, drop, log and inspect. The interesting action for this case is the inspect action, with which protocols of the designated traffic class that can be statefuly inspected performs a permit action. If the inspection fails, the inspect action will result in a drop action.

    Generally, a policy map can call multiple class maps to apply an action to but here we will only call one class map as mentioned above in bold font.

    Now let us go ahead and create the policy map SSH_ECHO_ICMP_INSIDE_TO_DMZ_POLICY-MAP of the type inspect.

    The policy map will call the class type of the type inspect also:

    And the action to apply to the traffic type isolated by the class map will be the inspect action.

    This informational message can be overlooked because even if the class map doesn’t specify the protocols, it is calling access control lists that specify the protocols affected.

    We exit the class map inside the policy map.

    Inside the policy map we configure the class map class-default to log the dropped packets for troubleshooting purposes. Without the log option the default class map class-default would be dropping any traffic type that didn’t get matched by the access control lists contained in the class maps called in the policy map.

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

The less specific do show policy-map type inspect command will instead show us all policy maps configured:

  • Service policy

    The last step involves applying the policy map above to a zone pair. The target zone pair here will be the INSIDE_TO_DMZ zone pair.

    As of now the zone pair INSIDE_TO_DMZ has no policy applied to it as can be seen with the show zone-pair security source INSIDE destination DMZ command:

    Now let’s go inside that zone pair:

    And apply our policy map using the service policy command:

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

    Testing POLICY_2

    Now that we have configurations in place for policy 2, we are going to test the various traffic types to confirm the policy works as intended so we can validate the configurations.

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

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

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

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

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

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

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

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

At this point in the deployment process, we have been able to properly configure the policy map SSH_ECHO_ICMP_INSIDE_TO_DMZ_POLICY-MAP and apply it to the zone pair INSIDE_TO_DMZ. This can be seen with the command show policy-map type inspect zone-pair.

Because this was the second policy map configured on this ZBPF router, we can see the two zone pairs (see blue and green markers). The output above was truncated for the sake of space. To display only the policy map configurations for the INSIDE_TO_DMZ zone pair, we can get more specific and issue the command show policy-map type inspect zone-pair INSIDE_TO_DMZ:

The SSH_ECHO_ICMP_INSIDE_TO_DMZ_POLICY-MAP policy map is seen making use of the SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP class map.

The SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP class map is bundling three extended access control lists (SSH_INSIDE_TO_DMZ, ECHO_INSIDE_TO_DMZ and ICMP_INSIDE_TO_DMZ) to select specific traffic types (SSH, echo and ICMP) and put them in their own class (SSH_ECHO_ICMP_INSIDE_TO_DMZ_CLASS-MAP) that will be acted upon by the relevant policy map (SSH_ECHO_ICMP_INSIDE_TO_DMZ_POLICY-MAP).

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:

The inspect session information shows that this was an ECHO request, and that the whole session ended up with 3600 Bytes sent by both the initiator and the responder. The session started 24 seconds ago and was last heard 00:00:00 seconds ago which actually means it is no longer open.

With a different traffic type, SSH for example, the output for the inspect session will show the following:

This time around, the inspect session information shows us an SSH ( on port 22 ) with the session established (SIS_OPEN) created 09sec ago. The session information also says Last heard 00:00:02, which means that as long as the SSH user is logged in , the inspect session will stay open.

In case the two traffic types were crossing the network at the same time, which is rather the real life case where a network is crossed by a multitude of different traffic types, we would need a longer list of established sessions in the command output. In this case two established sessions in the list.

As we close this part III of the Cisco Zone Based Policy Firewall tutorial, we will keep in mind that as of now only two out of the four policy rules we established has been 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. Stay tuned.