[Part one of this feature can be viewed here]

At its most basic level, Network Address Translation (NAT) operates at layer 3, the IP layer, changing IP header information by modifying source, destination addresses, port numbers, and recalculating the checksums accordingly. So far so good.

But NAT does not concern itself with layers 4 to 7, and many applications embed IP addresses within these layers. If NAT doesn't change them when it changes the header, how will your application work? And what happens when you're securing your network with encryption mechanisms - can NAT get enough information to do its job?

IPSec and NAT
NAT transforms the network part of the address. The IP checksum must, of course, be recalculated. But because TCP checksums are computed from a pseudo-header containing source and destination IP address (prepended to the TCP payload), NAT must also regenerate the TCP checksum. This can cause problems. To start with, if just the TCP data is encrypted (for example, when using SSL and SSH), then NAT can see the TCP header and regenerate checksums. If the header is encrypted as well, then it can't.

Take the encrypted IPSec Authentication Header (AH) used with VPN connectivity. AH runs the entire IP packet, including header fields such as source and destination IP address, through a message digest algorithm to produce a keyed hash. This hash is used by the recipient to authenticate the packet. If any field in the original IP packet is modified, authentication will fail and the recipient will discard the packet. But NAT, by definition, modifies IP packets. Therefore, AH plus NAT simply cannot work.

It's better with Encapsulating Security Payload (ESP), which doesn't use the outer header in its hash algorithm. But you have to watch that too, as it has its own issues.

In tunnel mode (i.e. the security is between two firewalls, or a host and RAS) there's no problem. If you have to use transport mode, where IPSec is host to host, NAT will change the TCP packet and have to recalculate the checksum. If it does this, ESP will fail. If it doesn't, TCP verification will fail.

Even with ESP in tunnel mode you may run into problems with Internet Key Exchange (IKE), if you're using shared keys, since this depends on the source address. Change that and again you're running into trouble.

You may be able to find a way round all of this, but by far the easiest way to get it to work is to avoid the issue altogethe You can do this by having your IPSec termination points in publicly addressable space so that you perform NAT on the way out before the security part. Alternatively, have one device doing both NAT and IPSec - as long as it can do it in the order you want. On the way out, do NAT, then IPSec: vice versa on incoming traffic. If you really have to perform IPSec operations in the middle somewhere, try to design for ESP tunnel mode.

Application Level Gateways
What about other applications? In many instances there's a need for something more complicated than a simple NAT device - you're going to need something that can look into and amend the data payload too. Even then, sometimes, there's just nothing you can do.

NAT devices that deal with the application layers are often referred to as Application Layer Gateways (ALGs) and use something commonly known as Fixup Protocol. You'll need such a device, fortunately common in many firewalls, if you want to run the likes of ICMP, FTP or DNS, all of which have address information within the payload.

Some ICMP packets have addresses within the ICMP message, which will need to be altered if NAT is used. FTP PORT and PASV commands also have addressing information buried within them. If you're running NetBIOS over TCP, then try your best not to let it out past your firewall as the address information within its payload tends not to appear consistently, and there can be multiple addresses embedded within the packet which can make it extremely difficult and process-intensive to sort out.

Then there's Voice over IP, H.323, SIP, SCCP and MGCP. All have embedded IP address and port number information deep within the packets, that have to be made to match a NAT address. RTP and RTCP also use dynamic port allocation that has to be allowed through a firewall. Without Fixup support you would have to allow swathes of ports through your firewall - not a good security practice.

You'll find that different vendors support ALG for different protocols and it's unlikely to be consistent across their product ranges. So make sure you know exactly how their boxes handle these issues. Design your network to allow you to protect yourself, optimise your IP addressing and still get your applications to work.