Reviewing NAT Concepts

Reviewing NAT Concepts


  • Explain the basic operation of NAT

Let’s start by reviewing the three forms of NAT:

  • Static NAT: This form of NAT provides a one-to-one translation between IP addresses (typically public and private). These types of mappings are usually used to allow Internet clients to access internal servers. It can be either a full IP address translation or translations of individual TCP or UDP ports.
  • Dynamic NAT: This form of NAT translates one pool of IP addresses to another. This is typically used as a temporary solution when companies or departments merge that have duplicate address schemes. Of the three NAT forms, this is used the least often.
  • NAT overload/PAT: This form of NAT allows multiple internal clients (typically using private IP address) to share one or more public IP addresses. This is accomplished by using unique source port numbers for each request coming from the public IP address. This is the most common form of NAT.
    In addition to reviewing the forms of NAT, I’d like to reiterate the terminology used when referencing logical locations on the network. Understanding the NAT terminology is more
    important now than in the SDM, because the SDM accomplishes most everything for you without requiring a deep understanding.
  • Inside/outside: These NAT descriptors refer to where a device is physically located. If a device is “inside,” it is under your control; it is in your network. If a device is “outside,” it is not under your control; it is outside your network.
  • Local/global: These NAT descriptors refer to where an IP address is located from the perspective of a NAT device. The NAT device is a network device that has its address
    translated through a NAT router. It could be a PC, a server, an Xbox, or any other type of host that has a private address that is translated to a real address on the Internet. If
    the IP address is considered “local,” it is seen as a device on the local subnet from the perspective of a NAT device (this may or may not be true). If the IP address is considered “global,” it is seen as not on the local subnet from the perspective of a NAT device.

Figure 21.1 shows these types of addresses on the network.

  • Reviewing NAT Concepts21.1
  • Inside local addresses: These addresses are the easiest to understand because they refer to everything inside your network. An address “inside” is physically located inside
    your network. From the perspective of the NAT device, it is “local,” meaning that it is seen on the internal network. If an inside local address were to communicate with
    another inside local address, that communication would be described as standard LAN connectivity. No routers would be needed.
  • Inside global addresses: Now the terms begin to mix a little bit. Let’s break this down into the individual pieces: First, the address is “inside,” which means that it is physically located on your network; it is under your control. “Global” means that it is seen as an IP address, not on the local subnet from the perspective of one of your NAT devices. Put all this together and you are left with the Internet valid IP address assigned to your router that is directly connected to the Internet. This is where a fundamental understanding of inside and outside can really help. If the address were an “outside global,” it would not be under your control, meaning that it could be any of
    the millions of devices attached to the Internet.
  • Outside global addresses: Outside global addresses refer to devices that are physically “outside” your network—outside your control. These addresses are “global,” meaning
    that the NAT devices on the inside of your network see these as nonlocal addresses. Put these two pieces together and you have a description of a standard Internet IP address.
  • Outside local addresses: I saved the best for last. Outside local addresses confused me for quite some time until I fully understood the capabilities of NAT. First let’s look at
    the pieces. This address is physically “outside” your network, out of your control, out on the Internet. However, it appears to NAT devices as an IP address on the “local”
    subnet. What this describes is an Internet host translated as it comes through the NAT router into your local network. You can think of this as “reverse NAT,” or just NAT in
    the other direction. As shown in Figure 21.1, when the web server speaks to the internal hosts on the network, they believe it to be co-located on
    the local subnet with them. They come to this conclusion because the NAT router translates the outside global address to something local (perhaps, the NAT gateway’s address).

Understanding the four NAT address descriptors listed is useful not only for the CCNA exam, but also for understanding any real-world NAT documentation.

NAT Configurations


  • Configure NAT for given network requirements
    Configuring NAT is not all that bad as long as you focus on your objective. I mention this because the syntax can be quite daunting when you see all the options available to you. Advanced NAT configurations can get quite complex.

For the CCNA and ICND2 exams, you should be able to perform these three NAT-related tasks:

  • Configure static NAT, translating an inside global address (or port number) to an inside local address, such as a web, DNS, or email server.
  • Configure dynamic NAT, translating a pool of inside local addresses to a pool of outside global addresses.
  • Configure NAT overload, translating many inside local addresses to a single inside global address. Of these three, I would especially focus on the first and third configurations, because they are more com mon in the real world. With that said, it’s time to walk through these configurations one at a time.

Static NAT

As discussed earlier, static NAT performs a one-to-one mapping from an inside local address to an inside global address (in English: from a private to a public address). This could mean that all traffic is translated between these addresses, or it could mean that you just choose certain ports through which to translate. As I go through the syntax, I will expand a little more on this. Figure 21.2 adds a network diagram to this syntax.

Before we get into the syntax, I want to make sure you’ve got the terms down. The internal network consists of the addresses. In NAT terms, these are all inside local addresses. The router has a single Internet IP address of This is considered the inside global address. The rest of the hosts on the Internet that will be accessing your internal servers all have outside global addresses.

Reviewing NAT Concepts21.2

FIGURE 21.2 Static NAT configuration.

Scenario 1
Configure a static NAT translation so that if any request on any port is received on the inside global address of the NAT_Router, it forwards that request to the internal web server. Here we go! First, get familiar with the current interfaces:

Everything is as shown in Figure 21.2. The first step in configuring NAT is to identify your inside and outside interfaces to the router. This is done on a per-interface basis:

With these interfaces identified to the router, it now knows which interface(s) are considered outside and inside. Setting up the static NAT translation is a little more difficult. Static NAT configurations are set up in global configuration mode with the ip nat syntax:

The primary keywords to consider are inside and outside. These two commands perform exactly the same function from different perspectives. If you choose the inside keyword, the syntax that follows translates an inside address to an outside address. If you choose the outside keyword, the syntax that follows translates an outside address to an inside address. Because NAT translations are always two-way, the keyword you choose influences the order you use for the addresses in the upcoming syntax. To avoid confusion, I recommend picking one method (inside or outside) and using it exclusively. Many moons ago, I chose to use inside, so that’s what I’ll do here:

The choice now is whether to translate the inside source IP address or inside destination IP address. If you are looking from the perspective of the inside device (what was chosen when the inside keyword was used rather than outside), you need to translate the internal device’s source IP address rather than its various destination IP addresses. (See how this can get confusing if you alternate between the inside and outside keywords?)

At this point, the router wants to know what type of translation you want to perform. The list keyword is used to perform dynamic NAT translations. Using route maps for NAT is far beyond the scope of the CCNA (and perhaps even the CCNP). In this case, you need to define a static

The router would now like to have either the inside local address or the protocol information. This scenario requests a full translation from the router’s inside global address to the web server’s inside local address. If you were choosing to use NAT to translate individual ports, you would use either TCP or UDP protocols. For this scenario, you can enter the web server’s inside local address:

The router now needs to know what inside global address to use. In this example, the router’s inside global address is, which is the same IP address assigned to its Serial0 interface. In the real world, you have the option of purchasing blocks of IP addresses from your ISP. You can then translate each of these public addresses to an inside local address without the address even being assigned to an interface! All you need to do is create static NAT mappings for each of the addresses that you have been assigned by the ISP, and your router automatically responds to them on the interface(s) you have designated as ip nat outside interfaces. This example has only a single IP address, so that’s plugged in here:

The extendable keyword enables you to have multiple inside global addresses mapped to the same inside local address (all the mappings must be marked with the extendable keyword). The no-alias command enables you to set up a one-way NAT mapping from the inside to outside. (The outside interface does not pass requests through to the inside host, but the inside host is translated to the outside.) In this case, you’re not adding either of these special functions, so you can just press the Enter key. Awesome!

You can verify this configuration by using either the show running-config command or the much more concise show ip nat translations:

Because this is a manually defined static entry, only the inside global and inside local fields are populated. If a host tried to connect to this entry (to access the internal web server), you would see the outside local and outside global columns populate as well. Let me generate some traffic from the outside to show you what this will look like:
NAT_Router#show ip nat translations Pro Inside global Inside local Outside local Outside global

In this case, an outside host accesses the address with a web browser (TCP port 80). You can see that it keeps the original static entry and adds a line below it, showing the outside local and outside global addresses of the external client. In this case, they are the same because the outside host appears as an outside host to the web server (the outside local address). Port 3367 is the dynamically generated source port number of the outside host, and port 80 is the destination port number sent to the web server. Scenario 1 accomplished!

Scenario 2
Configure two additional static NAT translations. If the NAT_Router receives a request to its inside global address that uses SMTP, it should be sent to the internal email server. If the NAT router receives a DNS request on the inside global address, it should forward it to the internal DNS server. All other traffic should keep forwarding to the internal web server. Wow! What a scenario! To tackle this, you must remember the universal rule of routing: The more specific matches always win. So, if you were to add specific static NAT entries that forward just a single port number, it would always overrule the forward all entry configured for the web server in Scenario 1. Let’s walk through these using context-sensitive help one more time, with a little less commentary:

So far, the static NAT mapping has been configured in exactly the same fashion as the previous one. Now we’ll add a little twist: Because we are just forwarding specific ports to the internal server, we need to choose the protocol those ports are using. The scenario calls for us to forward SMTP traffic to the internal E-Mail server and DNS traffic to the internal DNS server. SMTP uses TCP port 25, and DNS traffic uses UDP port 53 (remember this from Chapter 19, “Using Cisco Access Lists”?), so here’s how the syntax continues. First, we’ll focus on creating the map for the E-Mail server:

All righty, then. A specific static NAT mapping has been configured that uses the TCP protocol and that points to the inside local address of with inside local port 25. Isn’t that interesting? Now it’s time to specify an inside local port as well! This opens a bunch of possibilities. But before I expand on those, let’s finish the command: NAT_Router(config)#ip nat inside source static tcp 25

Did you see that? Not only was the command finished and the static NAT mapping added to the table, but now you can see the possibility for the global TCP/UDP port! This enables you to perform the fantastic configuration of port redirection. Here’s the idea: Perhaps for security reasons, you didn’t want to have the internal email server answering SMTP requests on port 25, so the internal port on the server is changed to 5525. Now none of the internal clients can access that email server via port 25; however, the NAT router can redirect incoming Internet requests on port 25 to the inside local port 5525! All this is seamless to the Internet clients. Are you as excited about this as I am? Finally, let’s add the last NAT translation for the DNS server:

Perfect! Three static NAT entries have now been added. Before we move on, let me call your attention to the context-sensitive help after the local port information has been entered:

So far, you have been entering the inside global address that you would like to translate. However, there may be an occasion when you do not know what your global address may be (primarily when using DHCP for your Internet address). In this case, you can use the interface keyword rather than an inside global address to translate requests received on the outside

interface to internal hosts. This can be especially useful when using a Cisco router to perform NAT on a cable or DSL connection at a home.

Dynamic Pool Translations

The next step is to move from the manual, static NAT entries to allowing the router to do the work for you. Dynamic NAT enables you to define a pool of addresses to translate from and a pool of addresses to translate to. The primary application of dynamic translations is to temporarily overcome overlapping IP addresses. For example, a company might use subnets of the address range for its internal addressing. This company might merge with another company that uses the same internal address space (this happens all the time). The IT staff could implement an intermediary design that uses NAT to translate between the two networks.

When performing this type of translation, hosts must refer to each other by hostname rather than IP address, thus requiring a DNS server be in place. When the NAT router sees a reply from a remote DNS server, it changes the remote IP address to something other than an overlapping IP address. Although the CCNA-level NAT does not get deep into design for overlapping IP addresses, you need to know the basic configurations of dynamic NAT. These configurations also act as springboards into the NAT overload configuration. First, examine Figure 21.3, a dynamic

NAT network diagram.

Scenario 3
Configure the NAT_Router so that hosts from the network are seen as IP addresses to 225 when accessing the hosts in the network.
Likewise, the hosts from the network should be seen as IP addresses to 225 when accessing the hosts in the network. This configuration is known as a two-way dynamic NAT configuration. The truth is, the NAT_Router in the middle of the diagram is not doing any routing. It’s just translating between the subnets. If you ever aspire to move on and tackle the CCIE lab, these sorts of tricks are key to have in your tool belt. Here’s the configuration walkthrough: 1. As before, configure the interfaces as NAT outside and inside interfaces. In this case, it does not really matter which one is set up as inside or outside, because just a private network is being translated.

2. Now you are introduced to a new concept: the NAT pool. This pool defines what addresses you will translate. Based on the scenarios, you need to create two NAT pools: one for the to 225 range and one for the to 225 range:

This command creates a NAT pool called Network1 that defines the correct address range necessary. Notice that this is one of the first commands you have seen that enables you to use CIDR notation (also known as “bit notation”) for your subnet mask. You now need to create a second NAT pool for the other network range:

3. You must now create a couple of standard access lists that will define the addresses that

4. Now you can put all the pieces together and turn on the NAT translation between the networks. The first thing is to define a translation going from the subnet to the network:

If you were to read the preceding line of syntax in English, it would sound something like this: “Translate the internal addresses defined in access list 50 into the pool of addresses defined in the NAT pool NETWORK2.” Keep a mental note of that overload keyword you see in the final-context sensitive help; you’ll make use of that soon. For now, let’s define the translation going back the other way:

Notice that this time an outside-to-inside translation is configured because the interface is marked as connected to the subnet as the outside interface.
At this point, the networks are translating quite well. Remember that the pool of 25 addresses defined earlier allows only 25 consecutive sessions between the subnets. Any consecutive sessions above that number will fail.

NAT Overload

Finally it’s time to explore the feature that made NAT famous around the network world: NAT overload. NAT overload is the official name of the feature that allows multiple hosts to share a single IP address. When Microsoft began allowing its servers to perform routing with the Routing and Remote Access administrative tools, it decided to call the feature Port Address Translation (PAT), which caught on in many circles. I prefer to use the term NAT overload because NAT can statically translate TCP or UDP ports to different inside local address—the true “port address translation.”

The configuration of NAT overload is a piece of cake, especially now that you’ve seen the prior dynamic NAT configuration.

Scenario 4
Configure the network pictured in Figure 21.4 for NAT overload, allowing all internal clients to access the Internet. In addition, configure a static entry that sends any incoming request on TCP port 80 or 443 to the internal web server.

Reviewing NAT Concepts21.4

Let’s walk through this new scenario step by step. In Figure 21.4, a typical network is connected to the Internet through the NAT_Router. The router needs to be configured to perform NAT overload to allow all the internal clients to access the Internet through a single IP address. Notice as well that the Internet IP address is assigned via DHCP, so there’s no way to be sure what the inside global address is at any point in time. Here goes! This first thing is to become familiar with NAT_Router:

Now the router needs to know what inside global address the inside local addresses should use. You can designate this either by using a NAT pool (as shown with the dynamic NAT configuration) or by specifying an outgoing interface to use. Because you do not know what inside global address you will have (because of the DHCP configuration), you need to specify the outgoing interface.

There it is—the magic overload keyword. That’s all it takes to turn on NAT overload for the interface connected to the Internet. The router now translates thousands of internal hosts through a single IP address. One more thing needs to be done to complete the scenario: Add the static NAT translation for the web server. By adding this configuration, you combine NAT overload with static NAT, which is a very common configuration. Here goes:

Beautiful. This has added the line that will translate incoming requests to the web server in addition to performing NAT overload for all other internal clients. If some internal clients are accessing the Internet, you can verify that the translations are working properly:

Holy cow! They sure are working, and it looks like the internal clients have taken advantage of that fact. If you look down the list of inside local addresses, you can see what inside hosts are accessing the Internet (along with what source port they are using to establish the request). Also, take a look at the inside global address; notice anything odd? It’s the same address the whole way down, just using different port numbers. This is the perfect picture of NAT overload. Finally, take a look at the translation with the “Web Server” comment next to it. This is the static NAT entry that was added for the internal web server. There are no outside local/global addresses for this because it is not in use at this time.

NAT Overload also works with a pool of addresses. In our example, we configured everything to overload the Serial 0 interface. We could also create a pool of IP addresses (see Scenario 3 where we configure dynamic NAT) and use NAT overload to translate many addresses to the pool. The advantage of doing this is that once a single IP address in the pool is “maxed out” (all the port numbers have been used up), the router can begin using a second IP address from the pool. If we created a pool of addresses for our trans
lation, we could use the following command to enable NAT Overload:

Verifying NAT Operation


  • Configure NAT for given network requirements
  • Troubleshoot NAT issues

Although a show running-config command is always useful to show what commands you have entered into your router to get NAT running, you can use a few commands to ensure that NAT is operational. The primary command you have seen many times at this point: show ip nat translations. This command gives you a snapshot view of what current NAT translations are active on your router. Its sidekick command, show ip nat statistics, gives you a view of how many translations are currently active, how many total translations have occurred, and how much of your NAT pool is being used (if performing dynamic NAT). Sample output from this command follows:

Remember that the number of “hits” and “misses” does not reflect how many NAT translations have been successful or unsuccessful. Rather, it reflects how many times a packet matches an existing translation in the table (a hit) and how many times a new translation needed to be created (a miss).

Troubleshooting NAT Operation


  • Troubleshoot NAT issues

NAT troubleshooting usually focuses on misconfiguration of some sort. It never fails that I’ll go through the complexity of creating access lists and statically mapping private and public addresses and port numbers only to forget to label the inside and outside interfaces using the ip nat inside and outside commands. So the first step of troubleshooting should always be to verify your configuration! Remember, if you are using a router-on-a-stick configuration to route between VLANs, the ip nat inside command needs to be on each subinterface for NAT to translate correctly and not only on the physical interface. That rule goes for any configuration that uses subinterfaces, including Frame Relay, which we’ll talk about in Chapter 23,

“Using Frame Relay Connections.”
If you have checked your configuration completely and found no missing links, use the verification commands we just discussed to find out if NAT translations are occurring on the router.

If you see plenty of translations displayed using the show ip nat translations command, it may just be that the client you are using has a bad configuration or an unreachable DNS
server. That brings up another point: always attempt to access a server by IP address rather than hostname. You don’t want to get knee-deep in NAT troubleshooting only to find out it was a DNS issue. My favorite test is to ping the IP address (a well-known public DNS server) from the internal client. If you attempt the ping and it is successful, try initiating a TCP connection. This brings up a big tip:

An extremely handy way to test TCP connections is to use a modified syntax of the telnet command. For example, if I wanted to test a connection to without opening a web browser, I could enter telnet 80, which initiates a TCP connection attempt on port 80. If you are successful, your command prompt will most likely blank out or return some scrambled information. This isn’t the information you are looking for; you want to know if the connection was successful. The test I use most often is to Telnet to (the now-famous DNS server address using port 53, the TCP DNS port used for server record replication) using the syntax telnet 53. This allows me to test con nectivity without needing to resolve a DNS hostname.

If you find that your connection attempts are failing from the internal client, move your tests to the router. Attempt the same ping commands and port-based telnet commands from the router. This will test your connectivity without the NAT process in the way. If the connection attempts fail, you most likely have an ISP connection or routing issue. Check your default route and attempt to ping the next-hop IP address attached to the default route. Use the troubleshooting techniques discussed in Chapters 10 through 12 to get your router communicating on the Internet.

If you find that the connection attempts are successful from the router but are still unsuccessful from the client, it may be time to use the debug ip nat command to find the issue. I hesitate to recommend this command, because it has the potential to overload a production router to the point of crashing. This command dumps translations to the screen anytime a NAT translation occurs. This following is a sample of what this looks like. Keep in mind that this output resulted from my enabling the debug for about one second on a network running in my home—and I’m showing you only about a quarter of the output! NAT_ROUTER#debug ip nat

Each line represents a packet passing through the NAT process. You can quickly see why this can overwhelm a router in an active business environment. Finally, you may encounter a situation in which a bad NAT translation is kept in the table. This happens frequently when you change your internal IP address scheme in some way, especially when you change individual host addresses that were just accessing the Internet. Although waiting for some time for the translations to time out solves the problem, impatient administrators may want to use the clear ip nat translation * command to wipe out any dynamically created NAT entries. This is not likely to disrupt service to your internal network, because active NAT translations immediately re-create themselves as the internal host sends data to or receives data from the Internet.

About the author


Leave a Comment