The Cable Guy - October 2004

  • Article

Problems with Using Network Address Translators

TechNet's The Cable Guy

By The Cable Guy

Network address translators (NATs) allow computers on private networks to access Internet resources without being directly accessible from the Internet. NATs allow re-use of the IPv4 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) on private networks, relieving the pressure of having to use public IPv4 addresses for every node that wants to access Internet resources. Although this is clearly an advantage of using NATs, this capability does not come without a price.

The original Internet was designed for a globally unique address space. All interfaces that connect to the Internet have a unique address that is based on the subnet to which the interface was attached. Regardless of how subnets are grouped together on private networks directly attached to the Internet, the interface is always reachable via its globally unique address.

Using NATs and the private address space is a violation of a globally unique address space. For each NATed network, the private address space is reused. This means that multiple interfaces connected to different networks can have the same address. Although these privately addressed networks are not visible from the Internet, they might be visible to each other and combining multiple private networks into one network can create address clashes (multiple subnets with the same address prefix or ambiguous routing table entries).

For example, Company A uses the 10.0.0.0/8 private address space for its internal network. Company B also uses the 10.0.0.0/8 private address space. When Company A and Company B merge, the chances are high that they will have address clashes. The merged company must renumber part of the combined network, an expensive and time-consuming process. Although using Dynamic Host Configuration Protocol (DHCP) for most host-based IP nodes helps, statically configured nodes such as servers must be manually reconfigured and the routing infrastructure must be redesigned.

NAT Operation

The basic operation of a NAT, as described in Windows 2000 Network Address Translator (NAT) (the March 2001 Cable Guy article), is the following:

  • For outgoing packets, the NAT changes the private source address to a public source address and the source Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port number to a NAT-specified value. For incoming packets, the NAT changes the destination public address to the original private address and the destination TCP or UDP port number to its original value.

A translation table on the NAT facilitates the mapping between public and private addresses and TCP/UDP port numbers. The NAT drops all incoming traffic not destined to an address assigned to the NAT that does not match an entry in the translation table.

When a computer behind a NAT—connected to a subnet that is separated from the Internet by the NAT—initiates communication with a node on the Internet, the NAT automatically creates the appropriate translation table entry to allow the forwarding of the response traffic to the initiating computer. An example is an Internet client browsing the Web. Domain Name System (DNS) and Hypertext Transfer Protocol (HTTP) traffic initiated by the client computer automatically creates translation table entries, effectively allowing the client computer to access Internet resources without having a direct, reachable connection to the Internet. Therefore, NATed client computers can typically access server computers that are directly reachable on the Internet without encountering problems.

To make server computers behind a NAT reachable from the Internet, you must configure the NAT with static translation table entries. See Configuring Access to Services Behind a Network Address Translator (NAT) (the May 2003 Cable Guy article) for an example.

NATs and Security

Because NATs discard all traffic that does not match a translation table entry, they are regarded as a security device. However, NATs are not a substitute for a firewall. Typically, there are two sets of TCP and UDP ports open on the NAT:

  • The set of ports corresponding to translated traffic, as specified by the translation table. This includes dynamic ports opened by clients behind the NAT and static ports configured for servers behind the NAT.
  • The set of ports corresponding to applications and services running on the NAT.

The static ports for servers behind the NAT and the ports for applications and services running on the NAT make the NAT vulnerable to attack. The dynamic ports are not as vulnerable because it is difficult for an attacker to predict when they will be open. If the NAT is a computer, rather than a dedicated device such as an Internet gateway device, then the computer is vulnerable to attack.

Therefore, the recommendation is that a NAT should use be used in combination with a firewall and that your private network clients should also use host-based firewalls to prevent the spread of malicious software on the private network.

Problems with Using a Server Behind a NAT

As previously described in this article, NATed client computers that are accessing Internet-connected server computers typically do not encounter problems. However, problems can occur when servers are located behind a NAT in the following situations:

  • Multiparty applications
  • Peer-to-peer applications
  • IPSec NAT-T

Multiparty Applications

Multiparty applications are those in which multiple computers agree to communicate together for a specific purpose via a central server. Examples include a collaborative computing application or a multiparty network game. When the central server and some of the clients are behind the NAT, the use of private addresses can cause configuration problems.

For example, a collaborative computing server is located behind a NAT and there are some clients that are behind the same NAT as the server and some clients that are located on the Internet. Because of the use of the private address space behind the NAT and because the server is behind the NAT, you must configure the following:

  • Static translation table entries that map the public address of the NAT and the port numbers of the server application to the private address of the server and the port numbers of the server application.
  • In order for Internet-connected clients to access the server by using its DNS name, you must add entries to the Internet DNS so that the server name (for example: collabsrv.example.com) can be resolved to the NAT's public address.
  • In order for private network-connected clients to access the server by using its DNS name, you must add entries to the private network DNS so that the server name can be resolved to the server's private address.

The DNS configuration is not required if you use the actual public or private address of the server when initiating the connection from the client computers. However, using IPv4 addresses to make connections to servers is awkward for end users and you must ensure that you tell the Internet clients to use the public address and tell the clients behind the NAT to use the private address.

Even when this entire configuration is in place, the clients behind the NAT and the Internet-connected clients do not agree as to the IPv4 address of the server. If the collaborative computing application must use a common IPv4 address for the server for configuration, synchronization, or security purposes, communication problems can still occur.

Peer-to-Peer Applications

An additional problem with NATs is their effect on peer-to-peer applications. In the peer-to-peer communication model, peers can act as either the client or the server and communicate by sending packets directly to each other. If a peer is behind a NAT, there are two addresses associated with it, the private address and the public address. Let's examine a simple configuration in which NATs can cause problems for peer-to-peer applications. The following figure shows a private network with a NAT at its edge.

cg100402

For a peer-to-peer application running on all peers, Peer 1 can initiate a session with Peer 2 (directly reachable on its subnet) and with Peer 3. However, Peer 1 cannot inform Peer 3 of the public address of Peer 2 because Peer 1 does not know it. Also, Peer 3 cannot initiate a session with either Peer 1 or Peer 2 without manually configuring the NAT with a static translation table entry to translate the inbound connection request packets to Peer 1 or Peer 2's private address and port. Even with the static translation table entry, Peer 3 cannot initiate a session with both Peer 1 and Peer 2 because both hosts use the same public IPv4 address and application port number.

To make matters worse, it is a more common situation to have Internet peers behind two different NATs. For example, in the previous figure, Peer 3 is also located behind a NAT. To ensure that the peer-to-peer application can work in any NATed configuration, it must be modified to be NAT-aware, resulting in additional complexity for the application.

IPSec NAT-T

Internet Protocol security (IPSec) NAT traversal (NAT-T) allows IPSec peers that are behind NATs to detect the presence of NATs, negotiate IPSec security associations (SAs), and send Encapsulating Security Payload (ESP)-protected data, despite the fact that the addresses in the IPSec-protected IPv4 packets change. For detailed information about how IPSec NAT-T works, see IPSec NAT Traversal Overview, the August 2002 Cable Guy article.

IPSec NAT-T is supported by Microsoft Windows Server 2003, Windows XP Service Pack 2 (SP2), and by Windows XP Service Pack 1 and Windows 2000 with a free Web download. However, due to the behavior of IPSec and NATs, Windows XP SP2 by default no longer supports establishing IPSec NAT-T SAs to servers that are located behind NATs to avoid a perceived security risk. The following figure shows an example configuration.

cg100403

To ensure that Server 1 is reachable behind the NAT for IPSec traffic, you must configure the NAT with static translation entries that map Internet Key Exchange (IKE) (using UDP port 500) and IPSec NAT-T (using UDP port 4500) traffic to Server 1.

In this configuration, the following situation can occur:

  1. Client 1, located on the Internet, uses IPSec NAT-T to establish bidirectional SAs with Server 1. The NAT forwards the IKE and IPSec NAT-T traffic between Server 1 and Client 1 because of the manually configured static translation table entries.

  2. Client 2 uses IPSec NAT-T to establish bidirectional SAs with Client 1. When Client 2 initiates communication with Client 1, the NAT creates a set of dynamic translation table entries, allowing the exchange of IKE and IPSec NAT-T traffic between Client 2 and Client 1.

  3. If the NAT removes the dynamic translation table entries created by Client 2 and a condition occurs that causes Client 1 to reestablish the SAs with Client 2, the following can occur:

    Client 1 sends IKE traffic to the public IP address of the NAT and to UDP port 500. Since this traffic matches the static translation table entry for IKE traffic to Server 1, the NAT forwards the IKE traffic to Server 1, rather than Client 2. Because Client 1 is reestablishing the SAs, it begins IPSec Main Mode negotiation and could end up establishing SAs with Server 1, rather than Client 2. The perceived security risk is that Client 1 can establish bidirectional SAs with an unintended peer.

Although this is an uncommon situation, the default behavior of computers running Windows XP with SP2 is to avoid establishing any IPSec NAT-T-based SAs to servers that are located behind a NAT, ensuring that this situation never occurs.

To change the IPSec NAT-T behavior for a computer running Windows XP with SP2, you must create and set the AssumeUDPEncapsulationContextOnSendRule registry value. However, you should consult with your network administrator or security staff before doing so.

To add and configure the AssumeUDPEncapsulationContextOnSendRule registry value, do the following:

  1. From the Windows XP desktop, click Start, click Run, type regedit.exe, and then click OK.
  2. In the console tree of the Registry Editor, open the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC
  3. On the Edit menu, click Add Value, and then add the following value: Value Name: AssumeUDPEncapsulationContextOnSendRule Data Type: REG_DWORD Data Value: 0, 1, or 2
    • 0 = SAs cannot be established with servers that are located behind NATs (default)
    • 1 = SAs can be established with servers that are located behind NATs, provided the client has a public address
    • 2 = SAs can be established when both client and servers are located behind NATs (this is the behavior for Windows XP with Service Pack 1 and Windows XP with no service packs installed)

Note The AssumeUDPEncapsulationContextOnSendRule name is case sensitive.

You must restart Windows XP with SP2 for this setting to take effect.

Setting AssumeUDPEncapsulationContextOnSendRule to 1 or 2 allows a computer running Windows XP with SP2 to connect to a server that is located behind a NAT, including a virtual private network (VPN) server running Windows Server 2003.

Summary

NATs are a makeshift measure to extend the life of the IPv4 public address space, and are not a solution to the IPv4 public address space problem. NATs work best for reusing the private address space for client computers. Most server computers still need unambiguous public addresses. Peers in peer-to-peer communication can be placed behind a NAT, but for general use when there are multiple peers behind a single NAT or when peers are separated by more than one NAT, the peer-to-peer application must be modified for NAT awareness. A server can be placed behind a NAT; however, the NAT must be configured manually with a static translation table entry to translate the inbound connection request packets to the server's private address and port. In the case of IPSec NAT-T, this static translation table entry can cause some unintended results in specific configurations.

For More Information

For more information about NATs and Windows, consult the following resources:

For a list and additional information on all The Cable Guy columns, click here.