Network Address Translation (known as NAT in network lingo) has become a

generic term for several related but different processes. The basic principle

involves changing the source IP of a host in the packet header as its traffic crosses

the NAT device. We examine the three main implementations of NAT on

Cisco routers, along with the applications, advantages, and disadvantages of the

NAT service, and finally the configuration commands to implement, verify, and

troubleshoot it.

  Introduction to Wide-Area Networks

A number of unfortunately confusing terms are associated with NAT that in a

typically evil plot are usually testable. The next figure diagrams a typical, simple

NAT setup and accurately locates the terms you need to know.

. Inside—This refers (typically) to the private side of the network, usually

. Outside—This is typically the public side of the network, the address

 . Inside Local—These addresses are assigned to inside hosts and are the

such as 192.168.x.x, 172.16–31.x.x and 10.x.x.x, but this is by no means

. Inside Global—These are the addresses to which Inside Locals get

. Outside Global—These are typically registered IPs assigned to web

. Outside Local—These are the addresses of Outside Global hosts as they

. If you have more inside hosts than you have outside IP addresses, the NAT

which a lot of IPs are available, but not enough for our requirements. In

. NAT can be used to solve two related and vexing network issues: The

. NAT can also be used to give a whole cluster of machines (each with different

 address and, if configured properly, prevents bad guys on the Internet from connecting

Static NAT refers to the creation of a one-to-one mapping of an Inside Local IP

to an Inside Global IP. Note that this type of NAT does not conserve IP addresses

at all because we need one outside IP for every inside IP. Static NAT gives

hosts such as mail or web servers access to the Internet even though they are

physically on the private network. Perhaps more importantly, it allows us to

access that web server from the Internet by creating a static NAT entry from an

outside global IP to the server’s inside local IP.

Configuring a static NAT entry is easy. The only trick is to make sure that you

get NAT working in the right direction: You must be very clear when identifying

the Inside interface and the Outside. Figure 7.11 shows a simple network

that we use to learn NAT configuration.

Let’s create a static NAT entry for the MX (Mail Exchanger) server with the IP

of 192.168.0.25. The ISP has told us that we can use a block of IP addresses as

shown, from 24.1.1.2 through 24.1.1.6, for our Inside Global addresses. We

have decided to use 24.1.1.2 for the Inside Global IP of the MX host.

 

 

The global-config static NAT command uses fairly logical syntax:

For our example, the command to enter on the NAT router would look like this:

Next, we have to identify the Inside and Outside interfaces:

And that’s all there is to creating a static NAT entry. Remember that static NAT

entries use up one outside IP for every inside IP, so they do not conserve the IP

address space at all.

www.cisco.com

198.133.219.25

Internet

ISP Addresses:

24.1.1.2

24.1.13

24.1.1.4

24.1.1.5

Mask /24

MX

192.168.0.25

192.168.0.0/24

NAT

Router

Outside

Inside

E0

S0

Dynamic NAT enables an inside host to get an outside address when needed;

this saves us the trouble of creating multiple static maps, one for each host that

wants to use the Internet. Dynamic NAT entries still don’t conserve IPs, since

we still need one IP for every host that wants to connect to the Internet.

Remember that if you have more hosts than outside IPs, some hosts will not get

a translation entry and will not be capable of using the Internet. For this reason,

it is not used much for Internet connectivity.

One of the interesting concepts introduced with dynamic NAT is that of the

Configuring dynamic NAT involves identifying which hosts are to be

translated, and to which addresses they should be translated. Both of these steps

inside source and a pool for the outside addresses. The syntax to build a NAT

pool looks like this:

The pool name is arbitrary. You can pick something that is meaningful to you.

The first-IP and last-IP are the first and last IPs in the pool range, and the mask

is the subnet mask of the network those outside IPs are on. Note that you must

have the word netmask in the syntax! Here’s what this command would look like

if we used the same network shown in Figure 7.11 and wanted to use the last

four IPs in the range that the ISP gave us:

Next, we need to identify what hosts get to be translated; we could build another

pool to do this, but it is more commonly done with a standard access list:

This list permits any address that starts with 192.168.0.x. Note that in this case,

the list is not permitting traffic to or from the hosts; rather, it is identifying those

hosts that can be translated.

Chapter 7: Introduction to Wide-Area Networks

So at this point, we have built the pool of addresses that we will be translating

to, we have identified which hosts can be translated (and possibly those that cannot),

and all that is left is to configure the NAT process itself:

The first line tells the router to use List 1 (which we built previously) to identify

which hosts can be translated (these are the Inside Source addresses), and then

identifies the pool called MyPool as the addresses to which the Inside Source

Addresses should be translated.

The next lines, as before, tell the router which interface should be Inside and

Outside. Remember, if you get these backwards, you will be translating the

Internet into your private network…that could be bad.

Note that with a pool of only four addresses, the first four hosts who request a

translation will get one (which they keep for 24 hours by default), and any additional

hosts who request a translation will not be able to get one. The next section

shows how PAT resolves this limitation.

It is a good idea (a best practice) to specifically deny any hosts that you do not want

translated, using your access list. For example, because we already have a static NAT

entry for the MX server in our example, we don’t want it to get another dynamic translation,

so we would start the access list with the line

the nature of TCP/IP communication by using the source ports of hosts to distinguish

them from each other when they are all being translated, possibly to a

single outside address.

With PAT, an inside host is given a translation entry that uses not only the host’s

IP address, but also its source port. Figure 7.12 illustrates the process as three

inside hosts are translated to a single outside IP address as they contact different

web servers.

So you can see now how PAT can hugely extend the registered Internet address

space: We could in theory translate thousands of private IPs to a single IP (often,

the IP assigned to our Outside interface) using PAT, by extending the Inside Local

IP with the randomly generated source port and mapping that to the Inside Global

IP extended by the same port number. With more than 64,000 ports available for

source port are slim; if it does happen, the conflicting hosts are forced to reset and

choose a different port number. We can further reduce the chances of this conflict

happening by using a pool for PAT, which makes it very unlikely indeed that two

Global IP with many Inside Local+Port mappings.

Configuring PAT is very easy; the commands are very similar to dynamic NAT,

Note that we have used the parameters interface serial 0 overload at the end of the

parameter simply instructs the NAT service to use the existing IP of Serial 0 as the

Inside Global IP for the translation. Here is a sample configuration that ties

together a static NAT entry, creates a pool, and overloads that pool to enable PAT:

The main command used to verify that your NAT configuration is working is

could have come from the NAT router in our previous examples.

Pro Inside Global Inside Local Outside Local Outside Global

tcp 24.1.1.1:1812 192.168.0.66:1812 63.240.93.157 63.240.93.157

tcp 24.1.1.1:5440 192.168.0.13:5440 198.133.219.25 63.240.93.157

tcp 24.1.1.1:2112 192.168.0.8:2112 64.233.187.104 64.233.187.104

Note that all three inside hosts have been translated to the same Inside Global

IP (which likely means that we have overloaded the S0 interface). We have

proved that the PAT service is functioning because we can see the different port

number extensions listed for each host. Note that the Outside Global and

Outside Local IPs are the same; this is because we are not translating those IPs

back into our inside network. If we were trying to solve the overlapping address

space problem, those two IPs would be different for each outside host.

have been performed, a general overview of how the NAT device is configured,

and how much of our pool has been used, as demonstrated in the following

output.

Network Address Translation

Total translations: 3 (0 static, 0 dynamic, 3 extended)

Outside interfaces: Serial0

Inside interfaces: Ethernet)

Hits: 38 Misses: 3

Expired Translations: 0

Dynamic Mappings:

-- Inside source

access-list 1 pool MyPool refcount 3

Pool MyPool: netmask 255.255.255.0

Start 24.1.1.3 end 24.1.1.6

Type generic, total addresses 4, allocated 3 (75%), misses 0

If you can successfully ping a remote host, chances are good that your NAT/

PAT config is at least partially functional.

If you do run into problems, it is possible to clear the NAT translations from the

and extended translation entries. To clear a static entry, you must remove the

command from your running-config.