Using NAT as a layer of defense

Using NAT as a layer of defense
Implementing Network Address Translation or NAT has become a common defensive strategy.
However, it’s important to weigh the advantages with the disadvantages before implementation.
The most common advantages associated with NAT are:
NAT hides all of your internal IP addresses by converting them to a single exit address.
You don’t have to decide whether to use provider-assigned or provider-independent
addresses. You can use private addresses internally and provider-assigned addresses for
your external NAT pool.
NAT makes migration from one ISP to another extremely easy. All you have to do is
update on entry in a DNS server to move from ISP to ISP.
Your internal address space can easily grow. Purchasing large blocks of IP addresses is
expensive. By using the private Class A addresses you can have 16,777,214 hosts for the
cost of a single public address.
You can use the easy DHCP feature that comes with most operating systems to
dynamically configure all your internal hosts, without running out of IP addresses.
You can use NAT to accomplish simple TCP load distribution through translation of one
Web server IP address to many internal addresses to distribute traffic across multiple
NAT does have it’s disadvantages:
If you use NAT, then your firewall or router becomes a stateful device and must maintain
the state of every connection. This creates a single point of failure for all traffic entering
and exiting your network.
There are performance issues that can arise with NAT. The IP header has a checksum that
includes the source and destination addresses and the Internet layer must recalculated the
checksum when the address changes. This typically isn’t a problem because the IP header
only calculates 20 bytes. However, the TCP or UDP checksum calculates the value for all
the data in the packet and is more processor intensive.
Some application protocols that embed IP addresses inside the application will not work
with NAT unless the protocol developer specifically supports this operation.
Multi-channel applications such as FTP and H-323 can be challenging. NAT normally
treats these two channels as unrelated and they fail.
Access control list based on source IP address is complex and difficult to initiate.
You cannot use IPSec through NAT. The authentication protocol, by definition, detects
alterations to an IP packet header. The receiving host will discard the packet because it
has been altered through NAT.
As with any network defensive tool, it’s important to weigh the advantages and disadvantages
before implementing. If none of the disadvantages apply to your current network. I highly
encourage using NAT combined with a private internal IP address structure. It’s probably the
cheapest defensive strategy that you’ll ever implement.