Networking 101: Understanding NAT and PAT

By Charlie Schluting | Sep 17, 2006 | Print this Page
http://www.enterprisenetworkingplanet.com/netsp/article.php/3632496/Networking-101-Understanding-NAT-and-PAT.htm

Due in large part to alleged NAT support on consumer devices, many people are confused about what NAT really is. Network Address Translation is used for many purposes, including but certainly not limited to, saving IP addresses. In this installment of Networking 101, we'll try to clear all this up.

NAT is a feature of a router that will translate IP addresses. When a packet comes in, it will be rewritten in order to forward it to a host that is not the IP destination. A router will keep track of this translation, and when the host sends a reply, it will translate back the other way.

Home users who talk about NAT are actually talking about PAT, or Port Address Translation. This is quite easy to remember: PAT translates ports, as the name implies, and likewise, NAT translates addresses. Sometimes PAT is also called Overloaded NAT. It doesn't really matter what you call it, just be careful about blanket "NAT can't" statements: they are likely incorrect.

Now that that's out of the way, let's clarify some terminology required for a NAT discussion. When we refer to the inside, we're talking about the internal network interface that receives egress traffic. This internal network may or may not be using private addresses—more on those in a minute. The outside refers to the external-facing network interface, the one that receives ingress traffic. In the real world, it is not the case that NAT is simply using a single outside IP; translating traffic into internal IPs and ports. That's what your Linksys does.

The "inside" of a NAT configuration is not synonymous with "private" or RFC1918 addresses. The often-referred-to "non-routable" addresses are not unroutable. You may configure most any router to pass traffic for these private IP subnets. If you try and pass a packet to your ISP for any of these addresses, it will be dropped. This is what "non-routable" means: not routable on the Internet. You can and should mix RFC1918 addresses (for management interfaces) on your local internal network.

NAT is not used to simply share a single IP address. But when it is, in this strange configuration that's really called PAT, issues can arise. Say two geeks want to throw up an IPIP tunnel between their networks so they can avoid all the issues of firewall rules and state-keeping. If they both use the same IP subnet, they can't just join two networks together: they won't be able to broadcast for each other, so they will never communicate, right? It would seem that one side or the other would have to renumber their entire subnet, but there is a trick. Using a semi-complicated NAT and DNS setup, the hosts could actually communicate. This is another case of blanket "NAT is evil" statements actually having little reflection on reality. This issue does come up frequently when two companies merge and various branch offices need to communicate.

So why in the world would someone want to use one external IP and map it to one internal IP, as opposed to just translating the port? Policy. It's even likely that both sides will use real bona fide Internet IP addresses. Everyone understands that NAT (the naive definition) will keep track of state; it's the only way to make translations happen. What they may not realize is that stateful filtering is a powerful security mechanism.

Stateful filtering means that the router will keep track of a TCP connection. Remember from our previous installment on TCP and its followup that a TCP connection consists of four parts: the remote and local IP address, and the connected ports. Stateful filters verify that every packet into the network is part of an already established, pre-verified connection.

Imagine a b2b transaction that ships very sensitive data across the Internet, even between continents. It's not feasible to lay fiber for this purpose, so the Internet has to be used. What to do? How would you secure this transaction, or set of transactions? It can be done with IPSEC, but also utilizing NAT at the same time. Each side will have a 1:1 (real) NAT router configured to only allow specific connections from specific hosts. This guarantees that from either network, only authorized hosts will be making a connection. This also guarantees that hosts on both sides have been minimally exposed, and very unlikely compromised, since nobody else can get into that network.

Once the session starts, packets are carefully inspected in and out of each NAT router. If something nefarious happens, and someone in-between is able to inject a forged packet into the stream, at least one side will notice. One of the NAT routers will be able to detect that a sequence number anomaly has occurred, and can immediately terminate all communication. When the TCP session completes with a FIN, the state is wiped clean.

In much the same way, home users take advantage of PAT to keep their less-than-secure machines from being completely taken over on a daily basis. When a connection attempt from the outside hits the external interface of a PAT device, it cannot be forwarded unless state already exists. State setup can only be done from the inside, when an egress attempt is made. If this version of NAT didn't exist on such a wide scale, the Internet would be a completely different place. Nobody would ever successfully install and patch a Windows computer prior to a compromise without some the minimal protection provided by PAT.

Clearly NAT is useful in these cases. So why do people say that NAT is evil? They are likely referring to PAT, the bastard child of NAT. It's called "overloaded" for a reason.

IPv6 introduces the ability to have way more IP addresses than we really need. Does that mean that IPv6 will eliminate NAT? No. It also won't eliminate the usage of NAT everyone's familiar with: PAT. We all need somewhere to stow Windows boxes away from the myriad of uninitiated connection attempts that come from the Internet.

Add to del.icio.us | DiggThis