NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. NAT Overload, also known as PAT (Port Address Translation) is essentially NAT with the added feature of TCP/UDP ports translation.
The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the public address space. For example a complete network with 100 hosts can have 100 private IP addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of NAT include security and economical usage of the IP address ranges at hand.
The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most common operation in most businesses around the world, as it enables the whole network to access the Internet using one single real IP address. If you would like to know more about the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks.
This translates to one usable real IP address - 22.214.171.124 - configured on our router's serial interface. IP address 126.96.36.199 will be used on the other end, that is, the ISP's router. Our ISP has also provided us with the necessary default gateway IP address (configured on our router - not shown) in order to route all traffic to the Internet.
Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with Internet access using one public IP address (188.8.131.52).
Configure NAT Overload - PAT (Port Address Translation)
'Overloading' means that the single public IP assigned to your router can be used by multiple internal hosts concurrently. This is done by translating source UDP/TCP ports in the packets and keeping track of them within the translation table kept in the router (R1 in our case). This is a typical NAT configuration for almost all of today's networks.
In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx. Those interested can visit our NAT Overload (PAT) article.
The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define the these interfaces for NAT overload to function.
R1# configure terminal
R1(config)# interface fastethernet0/0
R1(config-if)# ip nat inside
Next step is to set the serial interface S0/0 as the outside interface:
R1(config-if)# ip nat outside
We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s). This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will be able to access the Internet. You can use standard or extended access lists depending on your requirements:
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).
All that's left now is to enable NAT overload and bind it to the outside interface previously selected:
R1(config)# ip nat inside source list 100 interface serial 0/0 overload
From this point onward, the router will happily create all the necessary translations to allow the 192.168.0.0/24 network access to the Internet.
Verifying NAT Overload operation
Viewing the NAT translation table can sometimes reveal a lot of important information on your network's activity. Here you'll be able to identify traffic that's not supposed to be routed to the Internet or traffic that seems suspicious.
As packets start traversing the router it will gradually build up its NAT/PAT translation table as shown below:
Pro Inside global Inside local Outside local Outside global
As shown, the first 2 translations directed to 184.108.40.206 & 220.127.116.11 are DNS requests from internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP address 18.104.22.168.
Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an external server, possibly generated by an email client.
Because these entries are all dynamically created, they are temporary and will be removed from the translation table after some time.
Another point you might want to keep in mind is that when we use programs that create a lot of connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries to keep up with all connections. Having thousands of connections running through the router can put some serious stress on the CPU.
In these cases, we might need to clear the IP NAT table completely to free up resources.
This is easily done using the following command:
R1# clear ip nat translation *
Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:
R1# show ip nat translations
Pro Inside global ...........Inside local .....Outside local .......Outside global
Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current translations tracked by our NAT table, plus a lot more:
R1# show ip nat statistics
Total active translations: 200 (0 static, 200 dynamic; 200 extended)
Hits: 163134904 Misses: 0
CEF Translated packets: 161396861, CEF Punted packets: 3465356
Expired translations: 2453616
-- Inside Source
[Id: 2] access-list 100 interface serial 0/0 refcount 195
Appl doors: 0
Normal doors: 0
Queued Packets: 0
In this article we've covered configuration of NAT Overload on Cisco routers. We also saw how you can control the NAT Overload service using ACLs and obtain detailed statistics on the NAT service. The configuration and commands presented here is compatible with all Cisco router models and IOS's.
If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.
About the Writers
Ammar Muqaddas is a CCNA certified Engineer, CCNA Instructor and member of the Firewall.cx Team.
Chris Partsenidis is a CCNA certified Engineer, MCP, LCP, Founder & Senior Editor of Firewall.cx