In the last two articles in this series, we went through our first lab which dealt with ACLs and a little bit of routing protocol configuration. In the said articles, we created a loopback interface, applied access list on an interface and discovered through troubleshooting that there was a routing issue which we resolved using both static and EIGRP routing protocol configurations. We did all these through the CCP tool.

In this article, we will be walking through our second lab on Network Address Translation (NAT). Our labs are going to run in such a way that the next lab will continue from where the previous lab stopped, meaning we will retain configuration. Our network diagram from the last article is as shown below:

The configurations we currently have on both routers are shown below:

RTR1

<CODE>
hostname RTR1
cryptopkitrustpoint TP-self-signed-4279256517
<output snipped>
!
cryptopki certificate chain TP-self-signed-4279256517
certificate self-signed 01
<output snipped>
!
usernameccp privilege 15 secret 5 $1$H7.I$nhcZRQSiaWahllRIHiDlw/
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
routereigrp 10
network 1.1.1.1 0.0.0.0
network 10.0.0.0 0.0.0.255
network 192.168.12.0
no auto-summary
!
ip http server
ip http authentication local
ip http secure-server
!
linevty 0 4
login local
</CODE>

RTR2

<CODE>
hostname RTR2
cryptopkitrustpoint TP-self-signed-4279256517
<output snipped>
!
cryptopki certificate chain TP-self-signed-4279256517
<output snipped>
!
usernameccp privilege 15 secret 5 $1$QQAN$EZ7qiGi3D7XX7COrsO4Vk.
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
ip address 22.22.22.22 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
ip access-group OUTSIDE_IN in
!
routereigrp 10
network 2.2.2.2 0.0.0.0
network 22.22.22.22 0.0.0.0
network 192.168.12.0
no auto-summary
!
ip http server
ip http authentication local
ip http secure-server
!
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
!
linevty 0 4
login local
!
</CODE>

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 1

This task requires us to create loopback interfaces on RTR1. We should already be familiar with how to go about this. I will select 1.1.1.1 and navigate to Configure > Interface Management > Interface and Connections.

At the end of my configuration, my interface management screen with the added interfaces is as shown below:

Task 2

This second task requires a translation of IP addresses, however it does not specify whether to use static NAT or dynamic NAT. NAT have been covered in other articles on the Intense School site for example, this article. However, since the task specifies a source IP address and a destination IP address, we probably want to use dynamic NAT so that we can use an access list.

To configure NAT, we navigate to Configure > Router > NAT. Notice that you also have a wizard to configure NAT: Basic and Advanced NAT wizards.

You can play around with those wizards in your study time. For this article, we will be configuring our NAT without the wizard, using the ‘Edit NAT Configuration’ tab.

To add a rule, I will select the Add button which brings up the ‘Add Address Translation Rule’ dialog box.

The first thing I will do is to choose Dynamic instead of static.

We need to use an ACL to match the traffic we want to translate. Since that the task specifies a source and destination network, therefore we have to use an extended ACL. My created ACL is as shown below:

Now I can either specify the interface as the mapped IP address or I can use an address pool.

For this task, we will need an address pool. The word ‘pool’ can be misleading in this case because we need just one IP address but the trick is to specify the same start and end IP address in the pool as we will see.

The start (and end) IP address of the pool will be 112.112.112.112 as required by the task. Also, a hint is not to use /32 as the netmask. I’m sure there is a reason why it does not work when you use /32 but I’m yet to wrap my head around it.

At the end of my NAT configuration, this is what I have:

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

<CODE>
ip access-list extended NAT-ACL1
remark Match 111.111.111.111 to 22.22.22.22
remark CCP_ACL Category=2
permitip host 111.111.111.111 host 22.22.22.22
exit
ipnat inside source list NAT-ACL1 pool NAT-POOL1
ipnat pool NAT-POOL1 112.112.112.112 112.112.112.112netmask 255.255.255.0
</CODE>

At this point, I need to designate my NAT inside and NAT outside interfaces. Loopback2 should be inside while Fa0/1 should be the outside interface.

You will notice below that our loopback interfaces are not listed. It’s either CCP does not support NAT on loopback interfaces, or this is one of the unsupported features for the hardware platform we are using. Either ways, I will mark Fa0/1 from the list below as outside (untrusted).

However, I get an error here when I specify an outside interface but not an inside interface:

One ‘hack’ I can do is to cancel this, go to the interface connection and mark that interface from that dialog box i.e. navigate to Configure > Interface Management > Interface and Connections and double-click on the interface you want to configure; under the NAT tab, you can select none, inside or outside.

The commands to be delivered are:

<CODE>
interface FastEthernet0/1
ipnat outside
exit
</CODE>

This hack does not work on the Loopback interfaces because it is not supported.

Since the Lab asks us to do everything from the CCP tool, we should have used the Configuration Editor utility but I noticed it does not work on my devices. It may have something to do with a bug listed here. In any case, let us still review this utility.

It gives us a warning because this allows us to directly access the CLI from CCP without normal CCP validation.

We should normally be able to type commands into the editor and either merge with or replace the running configuration. It may work on your routers (different platforms perhaps) so give it a shot.

The configuration we need to add on RTR1 is as shown below:

<CODE>
interfaceLoopback 2
ipnat inside
</CODE>

Summary

Let’s save our configuration up to this point while we review what we have done. In this lab, we created two new loopback interfaces on RTR1. We then began the NAT configuration by creating an ACL to match our NAT traffic: 111.111.111.111 going to 22.22.22.22. We also created an address pool which had only one IP address: 112.112.112.112. When we tried designating NAT interfaces, we discovered that CCP does not support NAT designation on Loopback interfaces. We found out that we could use the Configuration Editor but for some reason, it was not working on our devices so we configured our requirement from the CLI.

On the next article, we will configure our last task and also test our configuration. I hope you have found this helpful and I look forward on the next article in the series.

Further reading