Lack of Legal IP Addresses

Lack of Legal IP Addresses

Organizations are facing two related challenges. First, the depletion of registered IP addresses means that getting blocks of “real” addresses larger than class C is virtually impossible. Second, trying to scale larger organizations with a hodge-podge of class C addresses will reduce routing efficiency. The following private address pools (RFC 1918) provide the only logical solution, but they can’t go out on the Internet.

10.0.0.0–10.255.255.255

1 class A

16.6+ million hosts

172.16.0.0–172.31.255.255

16 class Bs

1+ million hosts

192.168.0.0–192.168.255.255

256 class Cs

65,000+ hosts

Network Address Translation (NAT) is a mechanism that allows private addresses to be translated to real addresses, so they can travel through the Internet. NAT allows an organization with unregistered “private” addresses to connect to the Internet by translating those addresses into globally registered IP addresses. Incoming traffic is translated back for delivery within the inside network.

NAT can save an organization the hassle of readdressing its network when it changes ISPs. The real addresses leased from the original ISP can continue to be used, but must be translated at the perimeter to addresses that will summarize to the new ISP. This can be a real sanity saver when an ISP fails without notice to clients.

NAT can also provide a limited level of network privacy by hiding internal IP addresses from external networks. The external hosts will see the assigned “real” address and respond to that address.

Note?

Important to know is that some applications, such as some e-mail programs, capture the internal address and store it in the data portion of the IP packet, which means that under some circumstances the internal address can be seen by the outside world. Programs like McAfee SpamKiller display the entire path back to the source, including the internal local addresses.

This chapter covers Cisco IOS NAT and how to configure it, typically on a perimeter router. You must understand NAT technology and concepts because these are revisited in the Firewall chapters (6–8 and 17–20) and IPSec chapters (9–16 and 21) and can be on any of the exams. In some form, NAT is available on personal routers (cable and DSL connections), firewall devices like the PIX devices, and proxy servers working as firewalls. This section covers basic NAT operations and the following NAT implementations:

  • Static NAT

  • Dynamic NAT

  • Dynamic NAT with overloading (PAT)

NAT Technology and Terminology

NAT is the process of altering the IP header of a packet, so the source local address of the internal host is replaced in the header by real global addresses. In some cases, the destination address might also be modified. This swapping process is performed by a NAT device, usually on the network perimeter. The NAT server then maintains a table of the translations that allows returning packets to be addressed with the correct internal address. Figure 5-5 is a simple example of NAT where the local hosts (10.0.0.0 private network) are translated by the NAT device to global addresses in the 192.168.1.0 network.

Click To expand
Figure 5-5: NAT translation for inside network 10.0.0.0

When an outside host sends a response to 192.168.1.97 or 192.168.1.98, the NAT router checks the current table of network address translations, and then replaces the destination address with the original inside source address.

Note?

Obviously, 192.168.1.0 isn’t a globally routable “real” network, but we’ll use only private addresses in all examples for two reasons. The public addresses belong to someone, and the current or future owners might not agree with their use. Second, inevitably, someone will build a “practice” lab like the ones in the book and a slim possibility would exist for impacting the real owners of the address.

Cisco IOS Software uses the following terms when working with NAT. While other implementations might change the terms, the concepts remain the same:

  • Inside local address The configured IP address assigned to a host on the inside network. Quite often, these addresses are drawn from the RFC 1918 private address pools. They could also be real addresses officially assigned to some other organization.

  • Inside global address The inside global address is the translated address. This is the IP address the outside world sees for an inside host. Typically, these addresses are allocated from a pool of real IP addresses provided by the ISP.

  • Outside local address The IP address of an outside host as it appears to the inside network. Because these addresses are only used on the inside network, they might not necessarily be real public addresses. They can be assigned from the RFC 1918 private address pools.

  • Outside global address The configured IP address assigned to a host in the outside network. This address is a real address assigned from the globally routable pool.

NAT translations can occur dynamically or statically, and can be used for a variety of purposes, as described in the following sections.

Device Interfaces

A key concept in all NAT translations is identifying the internal (inside) interface(s) and the external (outside) interface(s). NAT needs to know which interfaces are connected to inside networks and which are connected to outside networks. Only packets moving between inside and outside interfaces can be translated. At least one inside interface and one outside interface for each border router must be defined. The following configuration additions would be typical for a perimeter router with a single serial connection to the Internet and a single LAN:

interface Serial0/0
 ?ip nat outside
!
interface FastEthernet0/0
 ?ip nat inside 

Outside interfaces should never be included in internal route tables and must remain unknown to internal hosts. Similarly, internal addresses should never be advertised or shared with the outside world. The internal interface typically is either the default gateway for hosts that share that network or the next-hop address for default routes set on other internal routers.

Static NAT

Static translation involves permanently mapping an inside local address to an inside global address. For most organizations, this would be reserved for those network servers shared with the outside world that, therefore, need to keep the same address. This is particularly true for servers, such as web or e-mail servers, that will have domain name translations in DNS servers. Any change in their global address results in missed traffic until the DNS server system is fully resolved to the change. This might take the form of those dreaded 404 Page Not Found Errors when searching the Web.

Except in the smallest of networks, or those with few users authorized to go out into the Internet, static NAT isn’t a suitable implementation for users because it requires a one-for-one ratio of real addresses to inside addresses.

Configuring Static NAT

To enable static NAT of an inside source address; use the ip nat inside source command in global configuration to create a single static translation. To remove the static translation, use the no form of this command. The syntax is

Rtr1(config)#ip nat inside source static local-ip global-ip Rtr1(config)#no ip nat inside source static local-ip global-ip

local-ip

Local IP address assigned to an inside host—often taken from RFC 1918 pool

global-ip

Globally unique IP address of an inside host as it appears to the outside world

Creating three static translations for servers in the example at the beginning of this section might look like the following:

Rtr1(config)#ip nat inside source static 10.0.0.201 192.168.1.105
Rtr1(config)#ip nat inside source static 10.0.0.202 192.168.1.106
Rtr1(config)#ip nat inside source static 10.0.0.203 192.168.1.106

Confirming NAT Translations

To see the NAT translations, use the show ip nat translations command. The results would look something like the following output. The translations appear immediately because they’re permanent. An outside user could access these servers by using the 192.168.1.105–107 addresses, assuming no access lists prevent it.

Rtr1#show ip nat translations
Pro Inside global ???Inside local ???Outside local ??Outside global
--- ?192.168.1.105 ???10.0.0.201 ?????--- ????????????---
--- ?192.168.1.106 ???10.0.0.202 ?????--- ????????????---
--- ?192.168.1.107 ???10.0.0.203 ?????--- ????????????---
Rtr1#

To see any NAT activity, use the show ip nat statistics command. The results would look something like the following output. The Total active translations summarizes the current status, while hits and misses indicates no traffic has been attempted. If an outside host were to ping one of the servers, the hits would show the number of packets—four or five.

Rtr1#show ip nat statistics
Total active translations: 3 (3 static, 0 dynamic; 0 extended)
Outside interfaces:
 ?Serial0/0
Inside interfaces:
 ?FastEthernet0/0
Hits: 0 ?Misses: 0
Expired translations: 0
Dynamic mappings:
Rtr1#

Dynamic NAT

You can configure dynamic NAT in the following three steps:

  • Define a pool of global IP addresses to be allocated.

  • Use a standard ACL to define the local addresses eligible for translation.

  • Link the pool of global addresses with the eligible local addresses.

Define a Pool of Global IP Addresses to Be Allocated

To define a pool of global IP addresses for NAT, use the ip nat pool global configuration command. To remove one or more addresses from the pool, use the no form of this command. The command defines a pool of addresses using start address, end address, and either netmask or prefix length. The pool command can define either an inside global pool or an outside local pool. The syntax is

Rtr1(config)#ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-len} Rtr1(config)#no ip nat pool name

name

Name of the pool

start-ip

Starting IP address that defines the range of addresses in the address pool

end-ip

Ending IP address that defines the range of addresses in the address pool

netmask netmask

Network mask that defines address bits identifying the network ID

prefix-length prefix-len

CIDR notation indicating how many bits make up the netmask

Examples:

Rtr1(config)#ip nat pool 2net-out 172.16.2.10 172.16.2.20 netmask 255.255.255.0
Rtr1(config)#ip nat pool 3net-out 172.16.3.10 172.16.3.99 prefix-length 24

Use a Standard ACL to Define the Local Addresses?Eligible?for?Translation

A standard access list is used to define the internal addresses that can and can’t be translated. In Global Configuration mode on SanJose1, make the following entries:

Examples:

Rtr1(config)#access-list 1 permit 192.168.1.0 0.0.0.255
Rtr1(config)#access-list 1 deny 192.168.2.5
Rtr1(config)#access-list 1 permit 192.168.2.0 0.0.0.255

Link the Pool of Global Addresses with the Eligible Local Addresses

To enable dynamic NAT of the inside source addresses, use the second form of the ip nat inside source command. To remove the static translation or remove the dynamic association to a pool, use the no form of this command. The syntax is

Rtr1(config)#ip nat inside source list {acl# | acl-name} {pool name | interface dialer-name}
Rtr1(config)#no ip nat inside source list {acl# | acl-name}{pool name | interface dialer-name}

list acl# | acl-name

Standard IP ACL number or name (packets permitted by the ACL are allowed to translate)

pool name

Name of the address pool from which global IP addresses are dynamically allocated

interface dialer-name

Name of the dialer interface on which the PPP/IPCP address negotiation takes place

Examples:

Rtr1(config)#ip nat pool 3net-out 172.16.3.10 172.16.3.99 netmask 255.255.255.0
Rtr1(config)#ip nat inside source list 1 pool 3net-out
Rtr1(config)#access-list 1 permit 192.168.2.0 0.0.0.255

Clearing the NAT Translation Table

Some dynamic translations stay in the translation table for 24 hours. Clearing dynamic NAT translations from the translation table before they timeout is possible by using the clear ip nat translation * command. This is particularly useful when testing NAT configuration.

Static NAT entries are immediately reestablished in the table.

Additional options exist for clearing only part of the table. Use the clear ip nat translation ? feature, if necessary.

Changing the NAT Default Inactivity Timeout Timers

TCP translations inactivity timeout defaults to 24 hours, unless an RST or FIN bit packet is seen on the stream, in which case they timeout in one minute. To change the amount of time after which NAT translations timeout, use the global configuration ip nat translation command. To disable the timeout, use the no form of this command.

Rtr1(config)#ip nat translation timeout seconds
Rtr1(config)#no ip nat translation timeout

timeout

Applies to dynamic translations, except for overload (PAT) translations. Default is 86,400 seconds (24 hours).

seconds

Seconds after which the specified port translation times out.

Examples:

The following example demonstrates changing the NAT default timeout value to 120 seconds on Rtr1.

Rtr1(confif)#ip nat translation timeout 120

Additional timer options are covered in the overload (PAT) section.

Dynamic NAT with Overloading (PAT)

Unless an organization has a large pool of global IP addresses, it seems the basic dynamic NAT translations could prove too limiting and cumbersome. Furthermore, having to maintain a large pool of global addresses somewhat defeats the address preservation aspects of private addresses.

The alternative is to have the NAT router create a unique identifier for every session by using a single global IP address and appending a port number, such as 1.1.1.1:1540. While over 65,000 port numbers exist, the effective limit is about 4,000. This means an organization could use and pay for only one real IP address and allow up to 4,000 hosts out onto the Internet. Even if NAT has a pool of two or more IP addresses to work with, the IOS version of NAT chooses to continue using the first IP address in the pool for subsequent translations.

This process is referred to as dynamic overloading or as Port Address Translation (PAT). To implement the feature requires adding only the one word overload to the ip nat inside source list command. An example would be as follows:

Rtr1(config)#ip nat pool 3net-out 172.16.3.10 172.16.3.99 netmask
 ????255.255.255.0
Rtr1(config)#ip nat inside source list 1 pool 3net-out overload
Rtr1(config)#access-list 1 permit 192.168.2.0 0.0.0.255

When the router receives the packet from an inside computer, it saves the computer’s local IP address and port number to a NAT table. The router replaces the local IP address with a global IP address and adds the same port number. The translation table now has a mapping of the computer’s nonroutable IP address and port number along with the router’s IP address. The show ip nat translation command displays the result.

Rtr1#show ip nat translation
Pro Inside global ????Inside local ?? ?? Outside local ??Outside global
icmp 172.16.2.5:1536 ?192.168.0.21:1536 ?10.0.0.5:1536 ??10.0.0.5:1536
tcp ?172.16.2.5:1095 ?192.168.0.21:1095 ?10.0.0.19:21 ???10.0.0.19:21
tcp ?172.16.2.5:1094 ?192.168.0.21:1094 ?10.0.0.45:23 ?? 10.0.0.45:23
Rtr1#

The first column (Pro), which has been blank before, now shows the protocol used.

When a packet comes from the destination computer, the router checks the destination port on the packet. The router then looks in the address translation table to see which computer on the stub domain the packet belongs to. It changes the destination address and the destination port to the one saved in the address translation table and sends it to that computer. The NAT router continues to use that same port number for the duration of the connection. The timer is reset each time the router accesses an entry in the table. If the entry isn’t accessed again before the timer expires, the entry is removed from the table.

Changing the PAT Default Inactivity Timeout Timers

When port translation (PAT) is configured, a finer control exists over specific translation entries because each entry contains more context about the traffic using it. A separate entry is made for each timer. The syntax is

Rtr1(config)#ip nat translation {udp-timeout | dns-timeout | tcp-timeout | finrst-timeout} seconds

Rtr1(config)#no ip nat translation {udp-timeout | dns-timeout | tcp-timeout | finrst-timeout}

udp-timeout

Applies to the UDP port. Default is 300 seconds (five minutes).

dns-timeout

Applies to DNS connections. Default is 60 seconds.

tcp-timeout

Applies to the TCP port. Default is 86,400 seconds (24 hours).

finrst-timeout

To set the timeout value after a Finish or Reset TCP packet before terminating a connection. Default is 60 seconds.

seconds

Seconds after which the specified port translation times out.

Examples:

Rtr1(confif)#ip nat translation udp-timeout 120
Rtr1(confif)#ip nat translation dns-timeout 30
Rtr1(confif)#ip nat translation tcp-timeout 600

Dynamic NAT sessions can only be initiated by an internal host. Initiating a NAT translation from outside the network is impossible. To some extent, this adds a level of security to the internal network. This might also help explain why the dynamic timeout timer for overload (PAT) sessions is so short. The window of opportunity stays open just long enough to make sure legitimate replies like web pages, FTP and TFTP copies, and ICMP messages can get in.

Debugging IP NAT

To see the actual translation process and troubleshoot NAT problems, use the debug ip nat command and related options. As with all debug commands, this can have serious impacts on production routers and should be used judiciously. The debug ip nat output looks like this:

Rtr1# debug ip nat
IP NAT debugging is on
06:37:40: NAT: ?s=192.168.0.10->172.16.2.5, d=172.16.1.97 [63]
06:37:40: NAT*: s=172.16.1.97, d=172.16.2.5->192.168.0.10 [63]
06:37:41: NAT*: s=192.168.0.10->172.16.2.5, d=172.16.1.97 [64]
06:37:41: NAT*: s=172.16.1.97, d=172.16.2.5->192.168.0.10 [64]
06:37:42: NAT*: s=192.168.0.10->172.16.2.5, d=172.16.1.97 [65]
06:37:42: NAT*: s=172.16.1.97, d=172.16.2.5->192.168.0.10 [65]
06:37:43: NAT*: s=192.168.0.10->172.16.2.5, d=172.16.1.97 [66]
06:37:43: NAT*: s=172.16.1.97, d=172.16.2.5->192.168.0.10 [66]
Rtr1#
06:38:43: NAT: expiring 172.16.2.5 (192.168.0.10) icmp 1536 (1536)
Rtr1#undebug all
All possible debugging has been turned off

The previous output shows the results of a ping from workstation to Rtr2.

You can see both translations as the pings pass both ways through the NAT router. The number at the end of the row is the same for both translations of each ping. The s= indicates the source, d= indicates the destination, and -> shows the translation.

The previous 06:38:43 entry shows the expiration of a NAT translation.

Using the debug ip nat ? command indicates you can refer to an access list number to define specific traffic to debug. The detailed option provides the port numbers, as well as the IP address translations. The following output shows the results of a ping from workstation to Rtr2. The second and third NAT output lines show the actual verification of IP address and port number assignment.

Rtr1#debug ip nat ?
 ?<1-99> ???Access list
 ?detailed ?NAT detailed events
 ?<cr>

Rtr1#debug ip nat detailed
IP NAT detailed debugging is on
07:03:50: NAT: ?i: icmp (192.168.0.10, 1536) -> (172.16.1.97, 1536) [101]
07:03:50: NAT: ?address not stolen for 192.168.0.10, proto 1 port 1536
07:03:50: NAT: ?ipnat_allocate_port: wanted 1536 got 1536
07:03:50: NAT*: o: icmp (172.16.1.97, 1536) -> (172.16.2.5, 1536) [101]
07:03:51: NAT*: i: icmp (192.168.0.10, 1536) -> (172.16.1.97, 1536) [102]
07:03:51: NAT*: o: icmp (172.16.1.97, 1536) -> (172.16.2.5, 1536) [102]
07:03:52: NAT*: i: icmp (192.168.0.10, 1536) -> (172.16.1.97, 1536) [103]
07:03:52: NAT*: o: icmp (172.16.1.97, 1536) -> (172.16.2.5, 1536) [103]
07:03:53: NAT*: i: icmp (192.168.0.10, 1536) -> (172.16.1.97, 1536) [104]
07:03:53: NAT*: o: icmp (172.16.1.97, 1536) -> (172.16.2.5, 1536) [104]
Rtr1#



Part III: Virtual Private Networks (VPNs)