Welcome back to this CCP series where we have gone through four labs already. The last lab we dealt with was on zone-based firewalls and in this new lab, we are still on the same security feature. This time, we will be focusing on the self zone because of its uniqueness from other created zones. As with our other labs, this lab will build on the previous one so just restart your GNS3 devices if you have been following with the configuration.

Our network diagram is shown below:

The configuration tasks for Lab #5 are as follows:

  • * Edit the configuration from Lab #4 to allow hosts on the outside interface to open SSH connections to RTR1’s Lo1 interface.
  • * Edit the configuration from Lab #4 to inspect only router-generated ICMP traffic to the outside zone. All other traffic should pass through uninspected. What issue does this create? Fix it.
  • * Test your configuration: SSH connections from to RTR1’s Lo1 interface should be successful. Telnet connections should fail.

Configuration solutions

Task #1

Let’s revisit the self zone of the zone-based firewall before we continue with our configuration. By default, if you don’t have any configured policies between zones, traffic will not flow between those zones. However, the self zone is an exception: traffic to the self zone from other zones and traffic from the self zone to other zones is allowed by default. This does not mean that policies cannot be configured for the self zone as we saw in the previous lab. Currently, we have two zone-pairs relating to the self zone: out-zone to self and self to out-zone.

For this first task, we are required to allow SSH connections to RTR1’s Lo1 interface. Let’s confirm that this connection is not allowed at the moment.

I have purposely made a mistake here and I hope you see it but let’s continue; it is part of the difficulty of this task.

To configure this task, we will add a rule to the out-zone to self zone-pair because this is the direction of the traffic we want to permit.

We will add a rule that matches SSH traffic from any source IP address to RTR1’s Lo1 interface.

The configuration to be delivered to the router is as follows:

ip access-list extended TO_LOOPBACK1
remark CCP_ACL Category=128
permit ip any host
class-map type inspect match-any SSH
match protocol ssh
class-map type inspect match-all ccp-cls-ccp-permit-1
match class-map SSH
match access-group name TO_LOOPBACK1
policy-map type inspect ccp-permit
no class type inspect SDM_EIGRP_PT
class type inspect ccp-cls-ccp-permit-1
no drop
class type inspect SDM_EIGRP_PT
no drop

From the configuration above, we can see that CCP created an access-list to match traffic going to and then matched that access-list along with protocol SSH in an inspect-type class-map. This class-map was then added to the policy map with an action of pass.

Task #2

Let’s move on to the second task. If you remember from the last article, we said that we discovered a bug in CCP because it created a class-map to inspect TCP, UDP and ICMP for the self zone instead of just the router-generated ICMP. Let’s confirm this. First I will ping from RTR1 to and this should create an inspected session in the self to out-zone zone-pair.

Now, I will open a telnet connection from RTR1 to RTR2 and because CCP is inspecting TCP sessions, it will also show up under the active sessions.

So we have seen that both TCP and ICMP traffic are inspected. We can now move on with the task which asks us to inspect only router-generated ICMP traffic. To do this, we will edit the self to out-zone zone-pair configured.

By right-clicking on the rule of focus, we can edit it.

I can then use the Remove button to remove the services I don’t want inspected: TCP and UDP.

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

class-map type inspect match-any ccp-cls-icmp-access
no match protocol tcp
no match protocol udp

The zone-pair policy has now been changed and reflected on the Edit Firewall Policy screen.

The task also specifies that all other traffic should be allowed uninspected. This has already been configured by default through the Basic Firewall Configuration wizard because looking at the screenshot above, we see that Unmatched Traffic is allowed.

But what have we done? Let’s try our tests again.

Now ping goes through but telnet fails. Why? The reason is because we are inspecting ICMP traffic; therefore return traffic (echo reply) is automatically allowed back in. However, we are not inspecting TCP so the return traffic from the telnet session is not allowed back in automatically. The block is actually being enforced by the out-zone to self zone-pair policy. I hope you understand this and if not, drop me a message or comment for me to explain further. In summary, we did not discover a bug in CCP. #Sad. Let’s re-add the TCP and UDP protocols to be inspected.

Task #3

We can now begin our tests. The first test requirement is that an SSH connection from to RTR1’s Lo1 interface should be allowed.

Hmm, what’s the problem? The SSH connection is still not successful. I’m here grinning because my plan is working perfectly. I hope I have whetted your appetite for more because during this article, I stumbled on something really fascinating.


In this article, we have begun the configuration for our fifth lab which is still on zone-based firewall but focuses on the self zone. We dispelled the discovery that CCP had a bug in the way it handled the inspection of the router-generated ICMP. We found that if it did not add inspection for TCP and UDP, then connections would be broken.

While I planned this article to be a bit convoluted, even I was stunned by the issue that arose from our configuration as we will see in the next article.

Further reading