Building NAT-Friendly Applications

by Blake Thompson


This explanation and sample application show how applications can solve communication issues between clients that are behind NAT-enabled routers.

A common method for home and small business users to share an Internet connection among more than one computer is to utilize Network Address Translation (NAT). Many users are unaware that they are using this technology, since routers often implement it automatically. Using NAT, several “private” IP addresses can be assigned on a personal network, while one “public” IP address is assigned to the router or computer that hosts the Internet connection.

This system, which is described in more detail below, works very well for normal Internet activities such as Web surfing or e-mail. When a user wants to perform other activities, such as playing a networked game with their friends, however, the system breaks down. Developers can build their applications to make the experience transparent to the end-user, thus making their application accessible to more users.

This article gives a brief overview of what NAT is and how it works. It also analyzes a method in depth to make an application work well behind a NAT system. Source code for an example application is provided.

The following definitions are instrumental to this discussion:

  • NAT (Network Address Translation): A system that usually resides between two networks, such as a home network and Internet Service Provider, which provides remapping of private IP addresses to public IP addresses.
  • Router: Commonly a piece of hardware or software that directs traffic between separate networks.
  • Packet: A string of data for transmission over a network that includes information about how to get that data to its destination.


The concepts herein work with standard implementations of NAT. The included source code is Windows*-based, but the concepts can easily be used in any environment.

Overview of How NAT Works

Every computer connected to the Internet must be addressed individually. To satisfy this requirement, the Internet's founding architects created IP (Internet Protocol) addressing. An IP address is a 32-bit number that uniquely identifies each computer on the Internet. An authority such as an Internet Service Provider usually assigns specific IP addresses to end users.

Using 32 bits results in 4,294,967,296 unique addresses that are available for use. The true number is actually less than this, because many numbers are reserved for special uses. Furthermore, segments or groups of IP addresses are reserved for large corporations, governments, and other organizations. This limitation poses a problem, given the huge and ever-growing number of Internet-connected devices; there simply are not enough addresses for every device to have a unique one. The solution to this problem is NAT.

NAT sits between the end user’s computer and the Internet, usually in the form of a service on a router. One unique number is assigned to the NAT service/router and is considered public. 'Publi c', in this sense, means that other computers on the Internet can see the address, and it is a unique and legitimate number assigned by an authorized party. The router also connects to one or more computers that utilize private IP addresses. These addresses are 'private', because computers on the Internet cannot access them directly, and they usually use a number range that the Internet's designers set aside and marked as 'private'.

Figure 1. Typical NAT setup with example IP addresses.

The benefit of this scheme is that many computers can access the network through the NAT device while only utilizing one public IP address.

NAT in Detail

So how does this bit of magic work? To understand it, we need to go slightly deeper into how a typical transaction happens on the Internet. First, it is important to know that computers on the Internet usually send data to each other in the form of packets. Each packet contains both payload data and the IP address of its destination. Additionally, the packet contains a port number that tells the receiving computer which application running on that computer is to receive the data.

To start a transaction, first the end user’s computer, or 'client', creates a packet to send to a server on the Internet. The client application inputs the destination IP address and port number in the address section of the packet. It also adds its own IP address and port number to the packet, to indicate where the packet came from – the 'source address'. This packet is not viable for transmission over the Internet, however, if it contains a private source address that other computers on the Internet could not address directly.

At this point, the client forwards the packet to its gateway, which in our case is the router with the NAT service. NAT intercepts the packet and modifies the packet’s source address. It inputs its own IP address and a new port number, generated by the NAT service. NAT keeps the original source address and adds it to an in-memory table (the NAT table), along with the new source-address information. This table is dynamic, and records are continually added as users access other computers on the Internet. The entries in this table usually have a time limit for how long the router should retain them.

The following is an example of a NAT table:

Private IP Address
(Source IP)
(Source Port)
Public IP Address Port 5000 17315 45 208.18 7.222.123 17316 520 17318


At this point, the packet is properly addressed, since it contains a public IP address. The router then sends the packet over the Internet to the destination server as usual. The server creates a response packet and sends the packet back to the source address that was in the original packet (the address of the NAT router).

NAT receives the packet and consults the NAT table to find a record that matches the destination address contained in the response packet. If it finds one, it modifies the destination address to the proper IP address and port number of the client computer. Finally, it sends the packet to the client, which can then process the packet. The client is unaware that anything happened to the packet while in transit and believes that it is communicating directly with the server, rather than a NAT intermediary. Figure 2 summarizes this process:

Figure 2. Public/Private IP Address Manipulation by NAT.

The following table shows the packets that NAT creates at the various steps in Figure 2:

Description Packet Contents
Destination IP Destination Port Source IP Source Port Data
Packet from step 1 4060 10.0.03 3500 Game Data
Packet from step 2 4060 16553 Game Data
Response packet from step 4 16553 4060 Game Data
Response packet from step 5 10.0.03 3500 4060 Game Data


The Problem with NAT

The described scenario works well, except for one fatal flaw. What happens if the user wants to run a server application, such as a Web server? The computer on the Internet, referred to as the requestor, cannot even address the client computer directly, since the client has a private IP address. Since many computers all over the world may utilize this address, the routers that pass the packet through the Internet cannot route the requestor’s packet correctly to its proper destination. Using the router’s public IP address is a possible means of overcoming this limitation, but that method has other problems. Consider the following scenario.

The requestor creates a packet with the public IP address and port number. It then sends that packet to the router. The NAT service intercepts the packet and consults its NAT table. Since no corresponding address exists, it ignores the packet and drops it. The client computer never receives the packet, and the requestor never receives a response.

The client user can solve this dilemma by creating a static entry in the NAT table. The user manually enters this entry into the router’s NAT table through some sort of interface that creates a binding of the public IP address and port number to the private IP address and port number of the client. Thus, any incoming packet on that port number will go to the client computer. This mechanism is tedious and complex, and many network security configurations will not allow end users to do it. Moreover, only one static mapping per port number is possible, so only one computer could act as a server for that port.

As a further example, consider the following scenario of a computer game played over the Internet.

Bob wants to play a computer game with his friend Joe. Bob’s home computer is connected directly to the Internet with a public IP address of Joe’s home computer shares a network connection with other computers at his home through a NAT router. His public IP address is Figure 3 summarizes this topology:

Figure 3. Internet connection between two gamers, only one of whom has a NAT router.

Bob starts his game and is prompted for his friend's IP address. Bob enters Joe’s public IP address, which Joe sent to him earlier via e-mail. Joe could have gotten this number from a router administration utility or by some other means. The game creates the packet below using a port number that is configured by the game:

Destination IP Destination Port Source IP Source Port Data 4060 4060 Game Data


The game then sends the packet to Joe’s router. The NAT service on the router inspects the packet and consults its NAT table, shown below:


Private IP Address Port Public IP Address Port 5000 17315 45 17316


Since no entry exists for the destination address and port number in the public section of the table, the router drops the packet, and the two players are unable to connect to one another. In this scenario, if Joe were to initiate the game, it would work; consider the following walk-through.

Joe enters Bob’s IP address, which is public, into the game. The game creates the following packet:


Destination IP Destination Port Source IP Source Port Data 4060 4060 Game Data


This time, NAT intercepts the packet and replaces the source IP and port number with its own:

Destination IP Destination Port Source IP Source Port Data 4060 17450 Game Data


The NAT also updates its NAT table appropriately:


Private IP Address Port Public IP Address Port 5000 17315 45 17316 4060 17450


The router then forwards the packet to Bob. Bob’s computer receives the packet and responds to the source address with a packet like that shown below:

Destination IP Destination Port Source IP Source Port Data 17450 4060 Game Data


NAT intercepts the response, and the router consults the NAT table. Since an entry exists for the Destination IP and port number, the address translation happens again, this time in reverse. Finally, Joe's router forwards the packet to Joe’s computer, which processes it appropriately. This series of steps continues as they play their game.

The fact that Joe can initiate connectivity but Bob cannot is the kind of problem that makes end users think programs are “buggy” and “broken”. If both Joe and Bob had NAT-enabled routers, it would not work in either direction. This type of issue creates customer dissatisfaction, unnecessary support phone calls, and even reduced sales.

A Way Around the Problem

Solutions for the problem do exist in an upcoming revision of the IP addressing scheme, but these will take time to come into effect. In the meantime, the many applications that still face this problem can use the workaround suggested here. This method requires that a third party act as an intermediary to negotiate the connection. This mechanism is very common, as many games may have features where the users access a central server for a list of other players with whom they can chat and initiate games.

The key is having a well-known port number on the server with which the applications communicate. The server then sends all involved parties the IP addresses and port numbers of other clients who want to play the game.

For example, consider the case of two players who are both behind NAT, and how they connect to each other. Again, Bob and Joe want to start a game. Both players now have NAT-enabled routers for their Internet connections. Bob starts his game, and instead of prompting him for an IP address of his friend, the game connects to our central game server at IP address 164.134.22. 5, port 5000:

Figure 4. Internet connection between two gamers, both of whom have a NAT router, via an intermediary server.

We can see the result of this setup in Bob’s NAT table:

Private IP Address Port Public IP Address Port 5000 16555


The server receives the packet and then puts Bob’s IP address and port number in a table it maintains of all clients:

Client IP Port 16555


Joe starts the game, following the same steps, and his NAT table is updated appropriately:

Private IP Address Port Public IP Address Port 5000 14232


The server's client table is also updated:

Client IP Port 16555 14232


The server can now act as an intermediary, helping Joe and Bob find one another and select each other to start a game. Bob chooses to host the game, and Joe joins it. The server then sends the host’s (Bob’s) IP address and port number to all players in the game (in this case just to Joe). Joe’s game then initiates communication with Bob’s game, using this IP address and port number. The game then continues as normal.

The secret is that both computers sent a packet to the server that identifies what global IP address and port the NAT server has assigned to them. Now that the server knows the new IP address and port information for all clie nts, it can forward the data to the other clients who utilized it to create a connection directly to other clients. This all happens transparently to Joe and Bob, who are able to play their game without trying to reconfigure their NAT or call for help from the game publisher.

Example Application

The included sample application has two components: the server component and the client component. Both can be run on the same computer for demonstration purposes, if needed, or they can be used by putting the server on a separate computer that is outside of a NAT-isolated network. Run the client on a couple of machines behind two other NAT-isolated networks. A rudimentary chat client allows players to chat with each other, and one player can host a game that the other can join. The game does not really do anything but show how the communication happens between the clients without opening any ports on the NAT router.

The included source for both components is for example purposes only.


The benefits of this method are obvious. At the cost of a central server and a little extra coding, making games more aware of NAT problems helps to reduce frustration and support calls from end users. Additionally, users do not have to concern themselves with the technical issues associated with opening ports in their routers, which can create security issues and limit the number of internal computers that can utilize those ports.

Additional Resources

The following documents provide valuable context to the discussion in this article:


Intel provides an array of value-added products and information to software developers:

  • Intel® Software Partner Home provides software vendors with Intel's latest technologies, helping member companies to improve product lines and grow market share.
  • The Intel® Developer Zone offers free articles and training to help software developers maximize code performance and minimize time and effort.
  • Intel Software Development Products include Compilers, Performance Analyzers, Performance Libraries and Threading Tools.
  • IT@Intel, through a series of white papers, case studies, and other mater ials, describes the lessons it has learned in identifying, evaluating, and deploying new technologies.

NAT Server code sample

NAT Client code sample