Configuring NAT Using SDM

Configuring NAT using the SDM is really much easier that anyone would think—except for you of course, because you’ve already! Anyway, all you have to do is click Configure NAT and you get a handy wizard that does a lot more that just hold your hand to create a NAT rule. It’s a lot like the one we used to create our firewall, and also just like , there’s more than one wizard. Again you get to pick between basic and advanced:

Basic NAT Use this wizard if you have some basic PCs/hosts on your trusted network that need access to the Internet. This wizard will guide you through the process of creating a basic NAT configuration.

Advanced NAT If you have a DMZ, or servers on your inside network that users from the outside need to access, you definitely want to opt for the Advanced NAT configuration.

The first screen is the Create NAT Configuration screen.

From here, I’m just going to simply connect up and create a basic NAT. After that, I click Launch the Selected Task, and get the next screen, which tells me what the Basic NAT Wizard is going to do.

As you might guess, it rocks—all I have to do is to click Next to get to a screen from which I’m able to select all my inside and outside addresses. Seem familiar? Good—that means you’ve been paying attention!

After choosing my inside and outside interfaces, I click Next. A NAT pool is created and all my interfaces are assigned inside or outside configurations, just like that!

Finally, I click Finish. Let’s see what doing that did to my router. Here are the interfaces it configured:
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
description Connection to 1242 AP
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
[output cut]
!
interface Serial0/2/0
description Connection to R3$FW_OUTSIDE$
ip address 64.1.1.5 255.255.255.252
ip access-group 103 in
ip verify unicast reverse-path
ip nat outside
ip inspect SDM_LOW out
ip virtual-reassembly
clock rate 2000000
!
[output cut]
Here is the ip nat inside source list it created:
ip nat inside source list 2 interface Serial0/2/0 overload
!
[output cut]
And last, here is the access list created for each interface I chose as in inside network:
access-list 2 remark SDM_ACL Category=2
access-list 2 permit 1.1.1.0 0.0.0.255
access-list 2 permit 10.1.4.0 0.0.0.255
access-list 2 permit 10.1.1.0 0.0.0.255
access-list 2 permit 10.1.2.0 0.0.0.255
access-list 2 permit 10.1.3.0 0.0.0.255

I know I’ve said this over and over in the book, but I like to repeat this because I want to assure you that SDM really is an incredibly useful tool for creating advanced configurations like ACLs, VPNs, and NAT.

Configuring NAT on Our Internetwork

Okay, now I’m going to go ahead and connect the link between our Corp router and the R3 router
using a 64.1.1.4/30 network and the LAN F0/0 link on the R3 router using the 64.1.1.8/30 network.
After NAT is working, I’ll then walk you through the verification commands I’ve been talking
about throughout this article.

Our inter network is shown in Figure 11.6, and the inside local addresses that I’ve been
using throughout this article are shown in Table 11.3.

I know—Figure 11.6 shows the same network we’ve been using, but there’s a difference
here. The connection between the Corp router and the R3 router is now using global PAT
addresses. They can’t talk because the other Corp connections have private IP addresses. (In
the real world, the ISP would block these, right? So let’s make this work!) Remember, we call
them “inside locals” when using NAT, meaning before translation, and our ISP is blocking the
private IP address ranges. What do we do? Well first we need to configure NAT on the Corp
router, so let’s get to work!

Now we all know we need to be able to communicate from all the networks connected
to the Corp router out to all the networks connected to the R3 router using the new global
address of 64.1.1.5/30. Right? You’re nodding your head yes—good! Here we go:
Corp#config t
Corp(config)#ip nat pool Todd 64.1.1.5 64.1.1.5 net 255.255.255.252
Corp(config)#access-list 1 permit 10.1.0.0 0.0.255.255
Corp(config)#ip nat inside source list 1 pool Todd overload
Before I add the interface configurations, notice I used the IP address of the Corp’s outside
interface 64.1.1.5 as both a start and finish address of the pool. I did that because it works just
fine when using PAT.
Anyway, it’s important not to forget to configure NAT on all interfaces:
Corp(config)#int s0/2/0
Corp(config-if)#ip nat outside
Corp(config-if)#int f0/1
Corp(config-if)#ip nat inside
Corp(config-if)#int s0/0/0
Corp(config-if)#ip nat inside
Corp(config-if)#int s0/0/1
Corp(config-if)#ip nat inside
Corp(config-if)#int s0/1/0
Corp(config-if)#ip nat inside
Corp(config-if)#
Now that PAT is configured and our interfaces are all set, let’s telnet from HostC to HostD—
wait, first I’ll ping from host to host, then I’ll telnet:
Corp#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
icmp 64.1.1.5:271 10.1.9.2:271 64.1.1.10:271 64.1.1.10:271
tcp 64.1.1.5:11000 10.1.9.2:11000 64.1.1.10:23 64.1.1.10:23
Corp#
Now I’m going to turn on debug ip nat on the Corp router, then telnet from HostB to
HostD. Let’s take a look at the output on the Corp router:
Corp#debug ip nat
*May 9 22:57:47.679: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.679: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [0]
*May 9 22:57:47.683: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:47.683: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [0]
*May 9 22:57:47.699: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.699: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [1]
*May 9 22:57:47.703: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:47.703: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [1]
*May 9 22:57:47.707: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.707: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [2]
*May 9 22:57:47.711: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.711: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [3]
*May 9 22:57:47.719: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:47.719: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [2]
*May 9 22:57:47.723: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:47.723: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [3]
*May 9 22:57:47.723: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.723: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [4]
*May 9 22:57:47.731: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.731: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [5]
*May 9 22:57:47.735: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:47.735: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [4]
*May 9 22:57:47.735: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.735: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [6]
*May 9 22:57:47.747: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.747: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [7]
*May 9 22:57:47.951: NAT*: TCP s=11000->1024, d=23
*May 9 22:57:47.951: NAT*: s=10.1.6.2->64.1.1.5, d=64.1.1.10 [8]
*May 9 22:57:48.103: NAT*: TCP s=23, d=1024->11000
*May 9 22:57:48.103: NAT*: s=64.1.1.10, d=64.1.1.5->10.1.6.2 [5]
Corp#
Well, well—this is some pretty interesting output to say the least! You can see that the first
line shows our source and destination port numbers that are being used on HostB. The second line
shows our inside source being translated to our inside global with the outside local/global address
listed last—and then, from the outside host back to our HostB. Let’s verify all this with the show
ip nat translation command:
Corp#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 64.1.1.5:11000 10.1.9.2:11000 64.1.1.10:23 64.1.1.10:23
Corp#

Now, let’s use the command show ip nat statistics on the Corp router:
Corp#sh ip nat stat
Total active translations: 2 (0 static, 2 dynamic; 2 extended)
Outside interfaces:
Serial0/2/0
Inside interfaces:
FastEthernet0/1, Serial0/0/0, Serial0/0/1, Serial0/1/0
Hits: 269 Misses: 13
CEF Translated packets: 227, CEF Punted packets: 0
Expired translations: 27
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 pool Todd refcount 2
pool Todd: netmask 255.255.255.252
start 64.1.1.5 end 64.1.1.5
type generic, total addresses 1, allocated 1 (100%), misses 0
Queued Packets: 0
Corp#

What we can see here is a summary of our configuration, our two active translations,
as well as the inside and outside interfaces that are being used. The pool is listed right there
toward the bottom of the output. And it all looks good, so it’s time to move on to configure
NAT using SDM.

Testing and Troubleshooting NAT

Cisco's NAT gives you some serious power—and without too much effort, because the configurations are really pretty simple. But we all know nothing’s perfect, so in case something goes wrong, you can figure out some of the more common causes by going through this list of possible snags:

1.Check the dynamic pools—are they composed of the right scope of addresses?

2.Check to see if any dynamic pools overlap.

3.Check to see if the addresses used for static mapping and those in the dynamic pools overlap.

4.Ensure that your access lists specify the correct addresses for translation.

5.Make sure there aren't any addresses left out that need to be there, and ensure none are included that shouldn't be.

6.Check to make sure that you've got both the inside and outside interfaces delimited properly.

One thing to keep in mind is that one of the most common problems with a new NAT configuration isn't specific to NAT at all—it usually involves a routing blooper. So, make sure that because you're changing a source or destination address in a packet, your router knows what to do with the new address after the translation!

Supposedly the sky’s the limit regarding the number of mappings the NAT table can hold. In reality, however, it comes down to things like memory and CPU or the boundaries set in place by the scope of available addresses or ports that do, in fact, cause there to be limitations placed on the number of entries possible. You see, each NAT mapping devours about 160 bytes of memory. And sometimes—but not very often—the amount of entries has to be limited for the sake of performance or because of policy restrictions. In situations like these, just use the ip nat translation max-entries command for help.

Another handy command for troubleshooting is show ip nat statistics. Deploying this gives you a summary of the NAT configuration, and it will count the number of active translation types. Also counted are hits to an existing mapping, as well any misses—the latter will result in an attempt to create a mapping. This command will also reveal expired translations. If you want to check into dynamic pools, their types, the total available addresses, how many addresses have been allocated and how many failed, plus the number of translations that have occurred, just use the pool (refcount) command.

And did you know you can manually clear dynamic NAT entries from the NAT table? Doing this can come in pretty handy if you need to get rid of a specific rotten entry without sitting around waiting for the time-out to expire. A manual clear also is really useful when you want to clear the whole NAT table to reconfigure a pool of addresses.

You also need to know that the Cisco IOS software just won’t allow you to change or delete address pools if any of that pool’s addresses are mapped in the NAT table. The clear ip nat translations command clears entries—you can indicate a single entry via the global and local address and through TCP and UDP translations (including ports), or you can just type in an asterisk (*) to wipe out the entire table. But know that if you do that, only dynamic entries will be cleared because this command does not remove static entries.

Oh, and there's more—any outside device’s packet destination address that happens to be responding to any inside device is known as the IG address. This means that the initial mapping has to be held in the NAT table so that all packets arriving from a specific connection get translated consistently. Holding entries in the NAT table also cuts down on repeated look ups happening each time the same machine sends packets to the same outside destinations on a regular basis.

Here’s what I mean: When an entry is placed into the NAT table the first time, a timer begins ticking; the duration of that timer is known as the translation timeout. Each time a packet for a given entry translates through the router, the timer gets reset. If the timer expires, the entry will be unceremoniously removed from the NAT table and the dynamically assigned address will then be returned to the pool. Cisco’s default translation timeout is 86,400 seconds (24 hours), but you can change that with the command ip nat translation timeout.

Before we move on to the configuration section and actually use the commands I just talked about, let’s go through a couple of NAT examples and see if you can figure out the configuration that needs to be used. To start, look at Figure 11.4 and ask yourself two things: Where would you implement NAT in this design, and what type of NAT would you configure?

In Figure 11.4, the NAT configuration would be placed on the corporate router and the configuration would be dynamic NAT with overload (PAT). In this NAT example, what type of NAT is being used?

The above command uses dynamic NAT. The pool in the command gives the answer away, plus there is more than one address in the pool, which means we probably are not using PAT. In the next NAT example, we’ll use Figure 11.5 to see if we can figure out the configuration needed.

The example in Figure 11.5 shows a border router that needs to be configured with NAT and will allow the use of six public IP addresses, 192.1.2.109 through 114. However, on the inside network, you have 63 hosts that use the private addresses of 192.168.10.65 through 126. What would your NAT configuration be on the border router?

 Two different answers would work here, but the following would be my first choice:

The command ip nat pool Todd 192.1.2.109 192.1.2.109 netmask 255.255.255.248 sets the pool name as Todd and creates a dynamic pool of addresses for the NAT to use address 192.1.2.109. Instead of the netmask command, you can use the prefix-length 29 statement. (And I know what you’re thinking, but no, you cannot do this on router interfaces as well.) The second answer would end up with the exact same result of having only 192.1.2.109 as your inside global, but you can type this in and have it work too: ip nat pool Todd 102.1.2.109 192.1.2.114 netmask 255.255.255.248. This is a waste because the second through sixth addresses would only be used if there was a conflict with a TCP port number.

If you do not understand the second line where the access-list is set, please see, “Security.”

The command ip nat inside source list 1 pool Todd overload sets the dynamic pool to use Port Address Translation (PAT) by using the overload command.

Be sure to add the ip nat inside and ip nat outside statements on the appropriate interfaces.

Simple Verification of NAT

Once you have configured the type of NAT you are going to use, typically overload (PAT), you need to be able to verify the configuration.

To see basic IP address translation information, use the following command:

Router# show ip nat translation

When looking at the IP NAT translations, you may see many translations from the same host to the same host at the destination. This is typical of many connections to the Web.

In addition, you can verify your NAT configuration with the debug ip nat command. This output will show the sending address, the translation, and the destination address on each debug line:

Router# debug ip nat

How do you clear your NAT entries from the translation table? Use the clear ip nat translation command. To clear all entries from the NAT table, use an asterisk (*) at the end of the command.

PAT (Overloading) Configuration

This last example shows how to configure inside global address overloading. This is the typical NAT that we would use today. It is rare that we would use static or dynamic NAT unless we were statically mapping a server, for example.

The nice thing about PAT is that the only differences between this configuration and the previous dynamic NAT configuration is that our pool of addresses has shrunk to only one IP address and at the end of our ip nat inside source command we included the overload command.

Notice in the example that the one IP address that is in the pool for us to use is the IP address of the outside interface. This is perfect if you are configuring NAT Overload for yourself at home or for a small office that only has one IP from your ISP. You could, however, use an additional address such as 170.168.2.2 if you had the address available to you. This could be helpful in a very large implementation where you may have so many internal users that you have to have more than one overloaded IP address on the outside.

Dynamic NAT Configuration

Dynamic NAT means that we have a pool of addresses that we will use to provide real IP addresses to a group of users on the inside. We do not use port numbers, so we have to have real IP addresses for every user trying to get outside the local network.

Here is a sample output of a dynamic NAT configuration:

The ip nat inside source list 1 pool Todd command tells the router to translate IP addresses that match access-list 1 to an address found in the IP NAT pool named Todd.

The access list in this case is not being used to permit or deny traffic as we would use it for security reasons to filter traffic. It is being used in this case to select or designate what we often call interesting traffic. When interesting traffic has been matched with the access list, it is pulled into the NAT process to be translated. This is a common use for access lists; they don’t always have the dull job of just blocking traffic at an interface.

The IP nat pool todd 170.168.2.2 192.168.2.254 command creates a pool of addresses that will be distributed to those hosts that require NAT.

Static NAT Configuration

Let’s take a look at a simple basic static NAT configuration:

In the preceding router output, the IP Nat inside source command identifies which IP addresses will be translated. In this configuration example, the IP Nat inside source command configures a static translation between the inside local IP address 10.1.1.1 to the outside global IP address 170.46.2.2.

If we look farther down in the configuration, we see that we have an ip nat command under each interface. The IP Nat inside command identifies that interface as the inside interface. The ip nat outside command identifies that interface as the outside interface. When you look back at the ip nat inside source command, you see that the command is referencing the inside interface as the source or starting point of the translation. The command could also be used like this—IP Nat outside source—which is referencing the interface you designated as the outside interface to be the source or starting point for the translation.