After that simple and informative introduction to the NAT concept, it's time to find out more about how it works and this is where the NAT table comes in.
The NAT Table
The NAT table is the heart of the whole NAT operation, which takes place within the router (or any NAT-enabled device) as packets arrive and leave its interfaces. Each connection from the internal (private) network to the external (public-Internet) network, and vice versa, is tracked and a special table is created to help the router determine what to do with all incoming packets on all of its interfaces; in our example there are two. This table, known as the NAT table, is populated gradually as connections are created across the router and once these connections are closed the entries are deleted, making room for new entries.
The NAT table works differently depending on the NAT mode. This is explained in greater detail on each NAT mode's page. For now, we just need to get the feeling for this table to facilitate understanding of each NAT mode.
The larger the NAT table (which means the more memory it occupies), the more bi-directional connections it can track. This means that a NAT-enabled device with a big NAT table is able to serve more clients on the internal network than other similar devices with smaller NAT tables.
The illustration below shows you a typical table of a NAT-enabled device while internal clients are trying access resources on the Internet:
Let's explain what's happening here: The above illustration shows two requests from the private LAN, hosts 192.168.0.5 and 192.168.0.21, arriving at the NAT-enabled device's (router in this example) private interface. These packets are temporarily stored in a special area in the router's memory until small changes are made to them. In this example the router will take each packet's Source IP (which is the PC the packets have come from) value and replace it with its own Public IP (184.108.40.206).
The packets are then sent out through the Public interface to their destinations, in this case 220.127.116.11 and 18.104.22.168. In addition, before the packets leave the router, an entry is made for each packet into the router's NAT table. These entries enable the router to behave appropriately when the reply for each outgoing packet hits its Public interface.
The above example covers only one specific NAT scenario. Depending on your NAT mode, the router would have dealt with the packets in a different way. This is analysed later in each NAT mode's page but, for now, you simply need to understand what the NAT table is and the purpose it serves.
So what happens when replies come back from the Internet?
Well, strictly speaking, exactly the opposite from when they are received from the internal network and sent to the Internet:
When the reply comes back, the router will consult the NAT table, locate the correct entries and perform another change to the incoming (for the Internet) packets by replacing the "destination IP" value from 22.214.171.124 to 192.168.0.5 for the first packet, and 192.168.0.21 for the second. The new packets are then sent to their destination, which are hosts 192.168.0.5 and 192.168.0.21 so the router can then delete their NAT table entries.
With most NAT devices, the NAT session limit is bound by the available memory in the device. Each NAT translation consumes about 160 bytes in the device's memory. As a result, 10,000 translations (a lot more than would normally be handled by a small router) will consume about 1.6 MB of memory. Therefore, a typical routing platform has more than enough memory to support thousands of NAT translations but in practice the story (as always) is different.
Typically on smaller Cisco routers, e.g 700, 800, 1600 series, that have an IOS with NAT capabilities, the number of NAT sessions they are able to track is around 2000 without much trouble but this also depends on the NAT mode being used. Pump that up to something like 3000 to 4000 sessions and you start having major problems as the NAT table gets too big for the router's CPU to manage. As you see, it's not only a memory issue :) This is when you start to see big delays in ping replies and eventually an exponential increase in packet loss.
We've actually seen Cisco routers having some problems while handling NAT translations (NAT Overload mode in particular). This was also confirmed by Mike Sweeney - a good friend of Firewall.cx, so keep in mind that the earlier Cisco IOS (pre v12.4.5) seems sometimes to behave a bit weird with NAT.
The larger router models and dedicated gateway/firewall appliances are able to track a lot more connections simultaneously (8000 to 25000), which makes them ideal for large corporations that need such capacity.