In the previous article, we began configuring our second lab which deals with Network Address Translation (NAT). We got through configuring two of the tasks and we left the last task for this article. In this article, we will finish up our configuration tasks and also do our testing, and troubleshooting if necessary.

Our network diagram has evolved into what is shown below:

CCP-Lab-04172014

The configuration tasks for our lab #2 are as follows:

  • Create two (2) new loopback interfaces on RTR1 with IP address 11.11.11.11/32 and 111.111.111.111/32.
  • When Lo2 (111.111.111.111/32) opens a telnet connection to 22.22.22.22 (RTR2), the traffic should be seen as coming from 112.112.112.112. This connection should be allowed.
  • Hosts on or behind RTR should be able to connect to Lo1 (11.11.11.11) on IP address 192.168.12.11.

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

Note: There’s a part of this configuration that you may need to do through the CLI.

Configuration solutions

Task 3

For hosts to be able to connect to the real IP address of a host on a particular mapped IP address, then static NAT is required because it allows a one-to-one bidirectional translation. To configure this, I will need to select 1.1.1.1 as the community member and navigate to Configure > Router > NAT. I will then add a new NAT rule under the Edit NAT Configuration tab.

Notice from the image above that it shows Loopback2 as the inside interface because that’s all we have configured. However, the IP address I specified is for Loopback1. The information about the inside and outside interfaces shown is just for guidance purposes and it does not affect our configuration.

The command to be delivered to the router is:

<CODE>ipnat inside source static 11.11.11.11 192.168.12.11</CODE>

At the end of the configuration, we have both of our NAT rules present on our router as shown below:

The last thing we need to do is to configure Loopback1 as a NAT inside interface. Since this is not supported through CCP, we will add the following command through the CLI:

<CODE>
interface Loopback 1
ipnat inside
</CODE>

Testing

At this point, we seem to have configured all our tasks so it is time to test. We see our loopback interfaces there so there’s no need to test that. For the 2nd task, when we telnet from RTR1’s Loopback 2 interface to 22.22.22.22, the source of that traffic should be 112.112.112.112. We will open our console connection to test this.

This connection failed. Let’s put on our troubleshooting hat. The best way of checking what is happening is to ping. We will turn on ICMP debugging on RTR2 while sourcing a ping off RTR1’s Loopback 2 interface to 22.22.22.22.

The debug output on RTR2 is as shown below:

The first thing we notice is that RTR2 sees the traffic and replies to 112.112.112.112. This tells us that our traffic was indeed translated but something else is at play here. You will then wonder, if RTR2 is sending unreachable packets, why is RTR1 showing “.” instead of “U”? Let’s look at the routing table of RTR2:

RTR2 does not have a route to 112.112.112.112; so even though it shows that it is sending unreachable packets to that address, since it does not know how to reach that address, the traffic is effectively black holed. What do we do then?

What we can do is to add a static route for 112.112.112.112 pointing to RTR1 i.e.

<CODE>ip route 112.112.112.112 255.255.255.255 192.168.12.1</CODE>

You could also add that static route through the CCP as we did in Lab #1. Now, when we ping again from RTR1, notice what happens:

Happy? Okay. I’m happy if you are happy. But we are yet to resolve the issue. The task requires that telnet connection should be allowed. The great thing with the ping output is that it gives us a hint as to what else is wrong. Remember that our lab builds on the previous lab where we configured access lists. Let’s look at our ACL configuration again:

<CODE>
ip access-list extended OUTSIDE_IN
remark filter inbound traffic on Fa0/0
remark CCP_ACL Category=1
remark permit 1.1.1.1 to access 22.22.22.22
permitip host 1.1.1.1 host 22.22.22.22
remark deny all other connections to 22.22.22.22
denyip any host 22.22.22.22
remark permit all unmatched traffic
permitip any any
</CODE>

Do you see the problem? We have only allowed 1.1.1.1 to access 22.22.22.22. It means we have to modify this ACL to allow 112.112.112.112 (the translated IP address not the real one). We will do this through CCP.

I will select 2.2.2.2 as the community member and navigate to Configure > Router > ACL > ACL Editor. I will select the access list and click on Edit so I can add a new entry. I have done this below.

Keep in mind that the order of my access list matters: my new ACE has to be above the “deny ip any host 22.22.22.22” entry; else it will never be matched. To do this, you can use the Mode Up or Move Down buttons to alter the position of entries. The configuration to be sent to the device is:

<CODE>
noip access-list extended OUTSIDE_IN
ip access-list extended OUTSIDE_IN
remark filter inbound traffic on Fa0/0
remark CCP_ACL Category=1
remark permit 1.1.1.1 to access 22.22.22.22
permitip host 1.1.1.1 host 22.22.22.22
permittcp host 112.112.112.112 host 22.22.22.22 eq telnet
remark deny all other connections to 22.22.22.22
denyip any host 22.22.22.22
remark permit all unmatched traffic
permitip any any
exit
</CODE>

CCP first removes the entire ACL before re-adding the entries. If we wanted to do it through the CLI, we should have used the sequence numbers to place the new entry above the deny statement.

Let’s try our ping again:

Of course that will fail. I just wanted to confirm that you are following. My ACE was specific: allow telnet connection only. So let’s try our telnet again:

Cool! It works. Just to confirm what IP address is showing, I will issue the “who” command.

Finally, let’s verify our last task. Lo1 should be seen as 192.168.12.11 on RTR2. To test this, we can open a telnet connection from RTR1 using a source interface of Lo1 to any interface on RTR2 except 22.22.22.22 because of the ACL.

We can also check it in the reverse direction i.e. RTR2 should be able to open a connection to 192.168.12.11. I will also show the NAT translation:

Great! That also works but I have a question for you: why didn’t we need to add a static route on RTR2 for IP address 192.168.12.11 like we did for 112.112.112.112? Drop your answers in the comment section.

Summary

Please remember to save your configurations up to this point because we have now come to the end of this article and the end of Lab #2. In this lab, we were able to configure both dynamic and static NAT and also saw two things that can cause NAT configurations to fail testing: routing issue and access lists.

We still have a variety of security features coming up as labs including Zone-based firewall, security audit and VPNs so keep this blog bookmarked. I hope you have found this article insightful and I look forward on the next lab in the series.