I've always thought of Network Address Translation (NAT) as something of a double-edged sword. On one hand, NAT has been the Internet's saving grace. There simply aren't enough IPv4 addresses available to support all of the computers and other IP-enabled devices in the world. NAT has proved to be the most effective solution for allowing multiple PCs to share a single public IP address.
NAT accomplishes this by assigning the public address to an NAT router. This router acts as a proxy server that acts as a gateway between a private network and the Internet. The computers on the private network all use private IP addresses. These IP addresses are valid for communications between devices on the private network but are not externally accessible. If a device with a private IP address needs to communicate with the outside world, the request is transmitted to the address that is configured as the device's default gateway. Typically, the default
The NAT router receives the request and forwards it to the Internet on the device's behalf. Because the NAT router is the only device on the network with a public IP address, all outbound traffic bears the router's IP address, regardless of which device actually made the request. This really helps with security because none of the network's internal IP addresses are revealed to the outside world, but it also causes some problems.
The problem is that unsolicited communications typically do not work very well in an environment that uses NAT. When I refer to unsolicited communications, I'm not talking about hacking attempts or spam but about legitimate traffic that was not specifically requested by a host on the internal network.
There are countless situations in which this is a problem, but to keep things simple, let's pretend that you wanted to host a Web server on your network. Typically, a Web server's IP address is registered with a DNS server so that those browsing the Internet can find it. Once a Web browser knows a site's address, it attempts to communicate with the site using HTTP traffic over TCP port 80.
That all sounds simple enough, but remember that all of the machines on the network have private addresses. Even if you were to register your Web server's IP address with a DNS server, nobody would be able to access your website because the address is not valid outside your private network.
Although it isn't practical for busy websites, one solution is to use port forwarding. The idea behind port forwarding is that you register your router's public address as the website's address. You can then configure your router so that any HTTP traffic coming in on TCP port 80 will be forwarded to your designated Web server's private address. This allows the unsolicited traffic to reach the Web server. When the Web server responds to the request, the packets are sent back through the NAT router, and the response appears to have been generated by the router itself. To the outside world, it appears as though your NAT router is the Web server.
Keep in mind that I don't recommend hosting a Web server in this way, because doing so tends to cause a lot of performance issues. The technique will work in a pinch, though. The point that I was trying to make is that it is possible to get unsolicited traffic through an NAT router.
In the past, NAT traversal was almost a non-issue. Most large corporations simply lease public IP addresses for any servers that they want to make externally accessible. A lot of smaller companies do use NAT, but these companies typically outsource Web server hosting. If such a company does need to configure NAT traversal, though, it usually has an IT person on staff who knows how to make it happen.
NAT traversal hasn't traditionally been a big issue for home users, either. Until a year or two ago, it was primarily the techies who had multiple computers networked in their homes, and they typically knew how to configure NAT traversal if it was needed.
Today, though, home networks are very common, and many small and medium-sized businesses also use NAT based networks. Most of these types of organizations would never place a website behind a NAT router, but there are a number of communication and collaboration-related applications that require external traffic to reach a host located behind the router. Such applications tend not to work in a NAT environment, though, unless the user knows how to configure NAT traversal for the particular application.
One of the more recent solutions to this problem has been the integration of application layer gateways into NAT routers. This basically means that the router is designed to recognize specific applications and can be configured to automatically perform the necessary traversals should a user run the application.
While this sounds like a good solution, it really isn't. New applications and new versions of existing applications are released all the time. As such, it is impossible for a router always to be up to date with the latest application-level gateway code for every application.
A better solution that is starting to be better known is the use of Universal Plug and Play (UPnP). UPnP is different from the Plug and Play (PnP) technology that is currently used for configuring device drivers in a Windows environment. UPnP is a new networking technology that is primarily geared to home users, but can also benefit many small and medium-sized businesses.
The basic idea is that UPnP uses existing protocols and technologies in a way that makes networking connectivity a lot simpler for non-technical users. UPnP supports automatic discovery of devices and requires no manual configuration. When a UPnP-enabled device connects to a UPnP-aware router, the device automatically obtains an IP address and announces its name to the rest of the network. UPnP-compliant devices are also designed to announce their capabilities to other devices upon request.
This built-in intelligence makes NAT traversal possible without the user having to configure port forwarding. UPnP is able to dynamically allocate port mappings on an as-needed basis. The best part is that UPnP is a networking technology, not a Microsoft proprietary technology. This means that although Windows supports it, UPnP is implemented at the hardware level, not at the operating system or application level.
As consumers become more connected, NAT traversal will become a much bigger issue for them. Things like peer-to-peer networking, multi-player games, and real-time communications tend not to work in an NAT environment without the NAT router being configured to support them. UPnP should make using such applications much easier and much more practical for consumers.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
This was first published in September 2007