Welcome back to this concluding article on Lab #5. We have been looking at the self zone of the Zone-based firewall. In the first part, we configured two tasks: the first task dealt with allowing SSH connections from the outside zone to the loopback interface of the ZFW router; in the second task, we looked at what happens when only ICMP traffic is inspected and other traffic are allowed without inspection.
We discovered that the configuration breaks connections and so we added TCP and UDP inspection back to the configuration. Finally, we began our test and found out that the SSH connection did not go through as expected, and then I promised to show you something intriguing that I stumbled on. This article is a fulfilment of that promise.
Let’s pick up from where we left off. Our network diagram remains the same as 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 184.108.40.206 to RTR1’s Lo1 interface should be successful. Telnet connections should fail.
Configuration solutions cont’d
The first test we performed was to open an SSH connection from RTR2 to RTR1’s Lo1 interface and we found out that it failed.
Let’s put our troubleshooting hats on. A good place to start will be to check if we can ping that address. In our case, because of the ZFW restrictions, our ping will probably fail. Therefore, what we can do is temporarily allow ICMP from the outside to the self zone. We do this by adding a new rule under the zone-pair of interest as I have done below.
Now we can try to ping 220.127.116.11 from RTR2.
It still fails. Let’s ping other addresses on RTR1 such as 18.104.22.168 and 192.168.12.1.
Those succeed. Hmm. So the problem is not with RTR2’s connection to RTR1. The next thing to check is our routing table.
Aha! The network is not in the router’s routing table. Why is that? We are using EIGRP in our network and that IP address is on RTR1 so let’s go back to check RTR1’s EIGRP configuration.
Note: I know what the problem is but I have decided to follow the normal troubleshooting steps in case you find yourself troubleshooting a network you are not familiar with.
From the configuration above, we can see that we are not advertising that network on RTR1. At this point, you can go ahead and advertise that network into EIGRP (which still won’t work) but allow me to let the cat out of the bag. Let us take a look at that loopback interface.
Do you now remember? Our second lab was on NAT, which is why we even created the new loopbacks on RTR1. So NAT is being applied on Loopback1 but what is the mapped address?
The mapped address is 192.168.12.11. We can try to ping that address from RTR2 now.
Success. But can we now open that SSH connection?
Nope. Now this is where it gets interesting. The first thing that came to my mind was to edit our zone-pair policy because we specified 22.214.171.124 in the rule as shown below.
Let’s go ahead and edit that rule.
As we will see (and as I discovered), this won’t work either.
I was at a loss: why is this not working? So I calmed down to think through the traffic flow: traffic is coming from the outside (Fa0/1) to the router’s interface (Lo1) which has a NAT translation on it. Which one happens first: the NAT ‘untranslation’ or the ZFW policy? If the NAT ‘untranslation’ happens before the ZFW policy, then the right IP address to use in our rule will be 126.96.36.199. However, if the ZFW policy is checked first, then the IP address to use will be 192.168.12.11.
Let’s find out what order the router uses. Follow carefully. I will log NAT translations on RTR1 so I know if a translation is created or not.
I will also clear all the counters on the zone-pairs so I know when my new connection hits.
Hint: The long command I issued above that got snipped is show policy-map type inspect zone-pair ccp-zp-out-self | section ccp-cls-ccp-permit-1
Now, let us try our SSH connection again.
From the above, we see that the SSH connection still fails. However, we also have some information from RTR1: The NAT translation was created but we see our class-map still has 0 packets matched. Currently, our ACL TO_LOOPBACK1 matches 192.168.12.11 and if we don’t have any matched packets, it means we have matched the wrong IP address.
Therefore, from what we said above, NAT is happening before ZFW, meaning we have to match 188.8.131.52 instead of 192.168.12.11. We had it right the first time. Let’s make that change now and run this test again to see if indeed the packets will be matched.
I hope you are as excited as I am about this discovery, although I’m sure Cisco would have documented it somewhere to save us all this stress.
Moving on with our solution: if we have matched the correct rule, why is the SSH connection still failing? *whistling* It gets more interesting. The forward traffic gets to the router (as we can see in the hit count) but what of the return traffic? The return traffic is controlled by the other zone-pair: self to out-zone.
As we can see from the above screenshot, the return traffic is matched under the TCP protocol inspection. In summary, I think we have screwed up the head of the router. Enough of the fun, let’s go to the resolution. There are two ways to resolve this as we will now consider.
The first solution is to remove the self to out-zone zone-pair policy completely. Since traffic from the self zone to other zones is normally permitted by default, then the return SSH traffic should also be permitted. Rather than deleting the zone-pair completely, let us remove only the policy under it for testing purposes.
The command we will enter is:
zone-pair security ccp-zp-self-out source self destination out-zone no service-policy type inspect ccp-permit-icmpreply
Let’s perform our test again.
It worked! *cool face* However, before we get too excited, we cannot use this option because the task requires us to do inspection for router-generated ICMP traffic. This brings us to the second solution.
First, we will put the configuration that we removed back. Currently, the rule we configured “allows” SSH traffic from the outside to 184.108.40.206 (pass action). However, if we could “inspect” that connection, then ZFW will automatically allow the return traffic. The only problem is that we can only apply the inspect action to TCP, UDP, ICMP, h225ras and h323 when dealing with the self zone.
So the way we can do it is to remove SSH from the service list and add TCP. We will then edit our ACL TO_LOOPBACK1 to make it more specific matching SSH traffic. However, it seems as though CCP does not allow us specify the service and protocol/port for access lists used by ZFW. It means we have to do it from the console.
As you can see from the screenshot below, I have also changed the service to TCP from SSH, with an inspect action.
Moment of truth: Let us run the test again.
It also works and this time, we can see the session that’s created.
Whew, that was tiring but well worth it. Just to complete the test task, it says Telnet connections should fail.
Also, remember to remove the ICMP rule we added for testing purposes.
This brings us to the end of this lab where we have looked deeply at the self zone of the Zone based firewall. The lab task required us to allow SSH connections from the outside zone to the self zone and we discovered some issues that arose with our configuration which we provided two solutions for.
I should take a break now because writing this article was so much fun due to its brain-tasking nature. I hope you enjoyed it also and I look forward to the next article in the series. I have attached the configuration of the devices so far to this article.
Zone-Based Policy Firewall Design and Application Guide: http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html
CCNA Security Certification Series – #1 Cisco Firewall Technologies: http://resources.intenseschool.com/ccna-security-certification-series-1-cisco-firewall-technologies/
CCNA Security Certification Series – #2 Cisco Firewall Technologies cont’d: http://resources.intenseschool.com/ccna-security-certification-series-2-cisco-firewall-technologies-contd/
NAT Order of Operation: http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html