You know the problem. You have dozens - or hundreds - of networked PCs that need to talk to the outside world, and they all have private RFC1918 IP addresses that can’t be allowed out on to the Internet. You don’t want to pay for public registered addresses for each one, and, to be honest, you don’t want the hassle of re-addressing them all anyway.

So you get your firewall or router to ‘NAT’ the addresses to a fewer number of publicly acceptable addresses, and off you go. Problem solved. Or is it? What problems are you creating for yourself later, and where might you going to run into difficulties?

First a quick recap of what NAT actually does. At a high level it’s pretty simple - a translation from one address to another is done as the packet passes through the ‘NATing’ device. Typically the source address is changed on the way out from your network, and the destination one on the way back in.

Fundamentals
Private IP addresses are split into two groups: a small group, ‘outside local addresses’, that will be used by the NAT routers, and the majority that are used within your network known as ‘inside local addresses’. An ISP assigns a range of IP addresses to your company. The assigned block of addresses are registered unique IP addresses and are called ‘inside global addresses’. The unique IP public addresses of devices visible to the Internet are known as ‘outside global addresses’.

Packets going from your internal network to the outside will typically be dynamically translated. In this case you configure a pool of your registered public addresses to be used as outgoing source addresses from your PCs. The NAT device will create a translation table in memory recording the mapping of inside local addresses to inside global addresses so that it can direct the corresponding incoming traffic to the correct host.

These mappings will time out after periods of inactivity. And if you don’t use all the addresses in the pool, they won’t appear in the translation table. So what happens if an outside device sends incoming traffic that happens to be addressed to one of your publicly assigned addresses? If it’s not in the table, your router/firewall won’t be able to route it to anywhere and it will be sent out a default route. This may well be through the interface to the outside world, at which point your ISP will send it straight back, knowing that that range of addresses belongs to you. You now have a routing loop and you’re using up valuable bandwidth.

The answer to this is to make sure you configure a reject route (Unix-speak) or route to null0 (Cisco speak) to make sure this traffic gets dumped before causing any issues.

Where you want the outside world to be able to access some of your internal devices such as ecommerce servers, you’ll need a static mapping so that the server always has the same address and the router knows how to get to it. This is typically done on the outside-to-inside traffic path.

Where you have many more devices than registered addresses you would use a technique known as overloading (also known as PAT or Port Address Translation). This lets you assign multiple private IP addresses to just one public one (or certainly a fewer number than you have internal devices), using discrete source port numbers to tell them apart in the translation table.

This allows you to cater for non-registered addresses, overlapping address ranges between companies, and to be honest, we could hardly manage without it. But all standard NAT and PAT devices do is swap out addresses in the IP header. Several applications embed IP addresses within the data itself. And just how will your cleverly designed NAT setup cope with that?

Read Part II next week: Digging deeper into NAT’s traps