In the last article, we began with the configuration of our Lab #4 which deals with Zone Based Firewall. We configured the 1st and 2nd tasks before we stopped. In this article, we will review the configuration made by CCP and then complete the lab tasks.

Our network diagram is shown below:

ZoneBasedFirewall05132014

Let’s refresh our memory with the configuration tasks for the lab:

  1. Using the Basic Firewall Configuration Wizard, configure Zone Based Firewall on RTR1 using two zones: inside and outside. Interface Fa0/1 should be the outside (untrusted) interface and Fa0/0 should be the trusted interface. Leave all other interfaces unmarked.
  2. Inspect TCP, UDP and other protocols from the inside zone to the outside zone.
  3. Allow ONLY ICMP traffic from the outside zone to inside zone.
  4. Test your configuration:
  • *Telnet traffic from the CCP host (10.0.0.100) to RTR2’s Lo0 interface (2.2.2.2) should be allowed and inspected;
  • * RTR2’s Lo0 interface should be able to ping the CCP Host;
  • * Assume you have an HTTP server running on the CCP Host. RTR2’s Lo0 should not be able to access that HTTP server. The logs should reveal the denial.

Your entire configuration should be done through the Cisco Configuration Professional tool.

Configuration solutions Cont’d

Configuration review

I suppose you are already familiar with the Zone-based firewall so I will just run through the configuration now. For better understanding, I will break the configuration down into different segments that are not necessarily in the order we saw in the last article.

zone security in-zone
zone security out-zone
!
interface FastEthernet0/1
zone-member security out-zone
exit
interface FastEthernet0/0
zone-member security in-zone
exit

The configuration above creates two zones: in-zone and out-zone. The names are logical enough although you may be used to inside and outside; whatever works for you. Also, the interfaces are assigned to their respective zones: Fa0/0 to in-zone and Fa0/1 to out-zone.

ip access-list extended SDM_EIGRP
remark CCP_ACL Category=1
permit eigrp any any
exit
!
class-map type inspect match-any SDM_EIGRP
match access-group name SDM_EIGRP
exit
class-map type inspect match-any SDM_EIGRP_TRAFFIC
match class-map SDM_EIGRP
exit
class-map type inspect match-all SDM_EIGRP_PT
match class-map SDM_EIGRP_TRAFFIC
exit
!
policy-map type inspect ccp-permit
class type inspect SDM_EIGRP_PT
no drop
pass
exit
class class-default
exit
!
zone-pair security ccp-zp-out-self source out-zone destination self
service-policy type inspect ccp-permit
exit

The configuration section above deals with permitting EIGRP between the outside zone and the self zone. First, an ACL was created matching EIGRP traffic (permit eigrp any any). That ACL was then matched in an inspect-type class map which was in turn matched in another class map and then another class map. Whew. CCP is an automated tool so it gets the job done even though some of the things are unnecessary. We only need the first class map to get it to work; the other two (SDM_EIGRP_TRAFFIC and SDM_EIGRP_PT) are unnecessary. A policy of pass is then configured for the class map and this policy is applied to the zone-pair ccp-zp-out-self i.e. between the outside and the self zone. Remember that zone-pairs are unidirectional, therefore outside to self is NOT the same as self to outside.

If we were doing the configuration manually, we can remove the unnecessary statements and have something like:

ip access-list extended SDM_EIGRP
remark CCP_ACL Category=1
permit eigrp any any
exit
!
class-map type inspect match-any SDM_EIGRP
match access-group name SDM_EIGRP
exit
!
policy-map type inspect ccp-permit
class type inspect SDM_EIGRP
no drop
pass
exit
class class-default
exit
!
zone-pair security ccp-zp-out-self source out-zone destination self
service-policy type inspect ccp-permit
exit

Let’s move on with the review now. The next section we will consider is the self zone to outside zone.

class-map type inspect match-any ccp-cls-icmp-access
match protocol icmp
match protocol tcp
match protocol udp
exit
class-map type inspect match-all ccp-icmp-access
match class-map ccp-cls-icmp-access
exit
!
policy-map type inspect ccp-permit-icmpreply
class type inspect ccp-icmp-access
no drop
inspect
exit
class class-default
no drop
pass
exit
exit
!
zone-pair security ccp-zp-self-out source self destination out-zone
service-policy type inspect ccp-permit-icmpreply
exit

According to CCP, it would add policy to inspect router-generated ICMP traffic.

Router-generated in zone-based firewall language simply means the self zone. However, the configuration above does not only inspect ICMP traffic, it also inspects TCP and UDP traffic. It seems we found a bug in the CCP configuration. In the next article, we will check that indeed the configuration is inspecting TCP, UDP and ICMP instead of just ICMP traffic.

Let’s now move on to the final piece of the configuration. I saved the best, or rather the bulkiest, for the last.

access-list 100 remark CCP_ACL Category=128
access-list 100 permit ip host 255.255.255.255 any
access-list 100 permit ip 127.0.0.0 0.255.255.255 any
access-list 100 permit ip 192.168.12.0 0.0.0.255 any
!
class-map type inspect match-any ccp-h225ras-inspect
match protocol h225ras
exit
class-map type inspect match-all ccp-protocol-http
match protocol http
exit
class-map type inspect match-all ccp-invalid-src
match access-group 100
exit
class-map type inspect match-any ccp-cls-insp-traffic
match protocol cuseeme
match protocol dns
match protocol ftp
match protocol https
match protocol icmp
match protocol imap
match protocol pop3
match protocol netshow
match protocol shell
match protocol realmedia
match protocol rtsp
match protocol smtp extended
match protocol sql-net
match protocol streamworks
match protocol tftp
match protocol vdolive
match protocol tcp
match protocol udp
exit
class-map type inspect match-all ccp-insp-traffic
match class-map ccp-cls-insp-traffic
exit
class-map type inspect match-any ccp-h323-inspect
match protocol h323
exit
class-map type inspect match-any ccp-sip-inspect
match protocol sip
exit
class-map type inspect match-any ccp-skinny-inspect
match protocol skinny
exit
!
policy-map type inspect ccp-inspect
class type inspect ccp-invalid-src
drop log
exit
class type inspect ccp-protocol-http
no drop
inspect
exit
class type inspect ccp-insp-traffic
no drop
inspect
exit
class type inspect ccp-h323-inspect
no drop
inspect
exit
class type inspect ccp-h225ras-inspect
no drop
inspect
exit
exit
!
zone-pair security ccp-zp-in-out source in-zone destination out-zone
service-policy type inspect ccp-inspect
exit
!

The ACL 100 matches traffic with invalid source addresses. We also have class maps that match voice traffic and another class map that matches most of the protocols to be inspected (ccp-cls-insp-traffic). Also notice that there are two class maps that are configured above but not used under any policy: ccp-skinny-inspect and ccp-sip-inspect. I wonder what they are doing there.

In the policy map, a drop and log action is configured for the class map that matches traffic with invalid source addresses; all other class maps have the inspect action configured. The policy map is then applied to the ccp-zp-in-out zone-pair i.e. traffic from the inside zone to the outside zone.

Task #3

We can now continue with the lab tasks. From the above configuration, notice that there is no zone-pair for outside zone to inside zone – we only have an inside zone to outside zone zone-pair. By default, traffic will not flow between zones without a configured policy. This means that all traffic initiated from the outside zone to the inside zone will be denied. We can do a quick test for this: I will ping the CCP host (10.0.0.100) from RTR2 which is in the outside zone.

Note that I can ping successfully in the reverse direction as shown below:

Task #3 requires us to allow only ICMP traffic from the outside zone to the inside zone. To do this, we have to edit the firewall policy we have configured.

The Add a Rule screen shows up which allows me to choose/create the source and destination zones and also select what service(s) I want to match and thus configure the policy to be applied: inspect, allow or deny.

You will find ICMP under the Network Management protocol group. An easier way may be to show the services in alphabetical order and then select the service(s) you want to match. At the end of my configuration, I have a screen similar to what is shown below:

The configuration to be sent to the router is as shown below:

class-map type inspect match-any allow-icmp
match protocol icmp
exit
policy-map type inspect ccp-policy-allow-icmp
class type inspect allow-icmp
no drop
pass
exit
exit
zone-pair security sdm-zp-out-zone-in-zone source out-zone destination in-zone
service-policy type inspect ccp-policy-allow-icmp
exit

The rule now shows up in the firewall policy screen:

Task #4

Finally, we are at the fun part – testing. Zone-based firewall is one of those configurations that may easily be misconfigured but since we did it through the wizard, we should be fine. The first test already succeeded as we saw above. The CCP host can ping RTR2 on its loopback interface.

We can use the show command to see that the session is actually being inspected.

The second test should succeed if we correctly configured Task #3. I will ping from 2.2.2.2 to 10.0.0.100.

For the last test, we can simulate an HTTP connection using Telnet to port 80. Notice from the show output above that the class-default is still “0 packets.” Our HTTP simulation should generate some packets which should be dropped.

It’s cool to see things work. Before we end this article, let us use the monitoring interface of the CCP tool to look at what is happening with our firewall. I will navigate to Monitor > Security > Firewall Status.

I will initiate a continuous ping from 10.0.0.100 to 2.2.2.2 which is the ccp-zp-in-out zone-pair and click on Monitor Policy.

You can try the same thing for the other tests.

Summary

This brings us to the end of this article on the CCP Lab #4. However, we are not yet done with the zone-based firewall as the next lab will also consider more configurations on ZFW. In this article, we have configured basic ZFW on RTR1 with one inside zone (and interface) and one outside zone. We did this using the Basic Firewall Configuration Wizard provided by CCP. We also added a new rule from the Edit Firewall Policy screen to allow ICMP traffic from the outside to the inside zone.

I hope you have found this article insightful. The next article will focus on the ZFW self zone. I look forward to the next article in the series.

Further reading