How NAT Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

In this section

• NAT Architecture

• NAT Network Structure

• Optional NAT Subsystems

• NAT Processes and Interactions

• Related Information

The network address translation (NAT) functionality provided by the Routing and Remote Access service enables computers on a private network to access computers on a public network, such as the Internet. In Windows Server 2003, the Routing and Remote Access NAT/Basic Firewall component is typically referred to as a routing protocol component. Strictly speaking, NAT is not a routing protocol; it does not send and receive traffic nor does it instigate changes to the routing table. However, the Routing and Remote Access service interfaces with the NAT/Basic Firewall component through the routing protocol interface, and, in this sense, NAT functions just like a routing protocol. Although NAT is not a true routing protocol, it is installed as if it were by using the Routing and Remote Access snap-in.

This document explains how Routing and Remote Access NAT works. It covers the components of Routing and Remote Access NAT architecture, a typical network behind a NAT-enabled router, optional NAT subsystems designed to simplify configuration for smaller networks, and NAT processes and interactions. The latter section explains how NAT works with TCP/IP, how address and port translation work, how dynamic and static mappings and IP reservations work, how NAT editors work, and includes a flowchart showing how inbound and outbound packets are processed.

For an introductory description of the problems Routing and Remote Access NAT is designed to solve and a quick sketch of typical NAT scenarios, see “What Is NAT?.” For information about tools used to install, configure, and manage Routing and Remote Access NAT, see “NAT Tools and Settings.”

NAT Architecture

Understanding the architecture of Routing and Remote Access NAT requires recognizing the relationship of the NAT routing protocol component to other routing components, to the NAT editors and proxies, to TCP/IP, and to the TCP/IP Address Resolution Protocol (ARP) module. The following figure illustrates Routing and Remote Access NAT architecture:

Routing and Remote Access NAT Architecture

The following table describes each component depicted in the figure.

Routing and Remote Access NAT Components

Component	Description
IP Router Manager	A component of the Routing and Remote Access service. The IP Router Manager uses input/output (I/O) controls to do the following: Add interfaces to and remove interfaces from NAT. Provide NAT with its configuration, which is stored as part of the IP global and per-interface information in the registry.
NAT	A routing protocol component that, when enabled on a server running the Routing and Remote Access service, translates IPv4 addresses and TCP or UDP port numbers of request packets originating from a client on a private network, forwards the translated packets to a destination computer on the Internet (or other public network), and then performs reverse translation for response packets sent by the destination computer back to the client. NAT can also translate packets for specifically allowed incoming traffic originating from a computer on the Internet to a client computer on the private network. For more information, see “NAT Network Structure” and “NAT Processes and Interactions” later in this document.
NAT Editors	Programs that perform translation for the data of certain network protocols that NAT on its own cannot translate. Routing and Remote Access NAT has the following built-in editors: Internet Control Message Protocol (ICMP), which supports the transmission of error messages across a NAT. Point-to-Point Tunneling Protocol (PPTP), which supports PPTP VPN traffic across a NAT. For more information, see “How NAT Editors Work” in “NAT Processes and Interactions” later in this document.
NAT Proxies	Programs that redirect packets to a module that builds a new packet modified so that the newly modified packet can cross a NAT. Routing and Remote Access NAT includes the File Transfer Protocol (FTP) proxy, which supports FTP traffic across a NAT, and the H.323 proxy, which supports NetMeeting calls across a NAT.
TCP/IP	The industry standard suite of protocols for transmitting data between computers over networks. Routing and Remote Access NAT is implemented as a routing protocol component that the TCP/IP protocol component in Windows calls when a data packet is sent or received. TCP/IP allows NAT to make modifications to a packet’s data (translating IP addresses and TCP or UDP port numbers) and to ensure that checksums within a modified packet are correct. For more information, see “How NAT Works with TCP/IP” and “How Address and Port Translation Work” in “NAT Processes and Interactions” later in this document.
ARP	The TCP/IP network layer protocol that uses broadcast traffic on the local network to resolve a logically assigned IPv4 address to its physical hardware or media access control (MAC) layer address. When mapping between public and private address pools when a pool of public addresses exists, NAT uses TCP/IP’s proxy ARP mechanism to respond to ARP queries for addresses in a public address pool. (Proxy ARP refers to the use of a particular machine, such as a NAT-enabled IP router, to respond to ARP requests for computers other than itself.)

NAT Network Structure

In a typical scenario, a Routing and Remote Access NAT-enabled router provides access to the Internet for a small- or medium-sized organization that uses private IPv4 addresses. To support this type of network, in addition to a server running the Routing and Remote Access service with the NAT/Basic Firewall component enabled, the typical network configuration includes, at minimum, client computers running a Web browser, such as Internet Explorer, and a firewall, such as the Basic Firewall option available with Routing and Remote Access NAT. The NAT-enabled router lets the clients on the private network access a computer on the Internet, such as a Web server running Internet Information Services (IIS).

Unless the network contains multiple routed segments, neither a DHCP nor a DNS server is required because NAT functionality in Windows Server 2003 includes the DHCP allocator and the DNS proxy capabilities, which provide automatic addressing and name resolution, respectively. For more information about the DHCP allocator and the DNS proxy, see “DHCP Allocator” and “DNS Proxy” in “Optional NAT Subsystems” later in this document.

If a DHCP server or a DNS server does exist on the network, Routing and Remote Access NAT is also designed to work with those servers. In addition, Routing and Remote Access NAT is designed to work in networks with or without the Active Directory directory service.

The following figure shows an example of a single-subnet private network that uses a Routing and Remote Access NAT-enabled router to provide access to the Internet. Computers on the private network have a private IPv4 address, except for the router, which has both a private and a public address. The Web server, like any computer on the Internet, has a public IPv4 address.

Client on a Private Network Behind a Routing and Remote Access NAT Accessing a Resource over the Internet

The following table describes each component shown in the preceding figure.

Components of a Private Network Behind a NAT-enabled Router

Component	Description
Client PCs	Each client has a private IPv4 address configured on its network adapter. Clients need only a Web browser and access to a NAT-enabled router to be able to access the Web server across the Internet.
Routing and Remote Access NAT-enabled router	The NAT-enabled router has a private IP v4 address configured on its private interface, and a public IPv4 address configured on its Internet interface (in this example, a dial-up modem). The router has the optional Basic Firewall, DHCP allocator, and DNS proxy NAT components enabled. For more information, see “Optional NAT Subsystems.” For a larger network, an administrator might also configure a more sophisticated firewall in addition to using Basic Firewall to protect the Internet interface of the NAT-enabled router and might use a DHCP server (required if the network has more than one segment) and a DNS server.
Web server	A Web server on the Internet provides resources needed by the client computers on the private network. Like all computers on the Internet, it has a public IPv4 address.

For information about why NAT was developed to mediate between private and public networks, see “What Is NAT?” in this collection.

Optional NAT Subsystems

One major type of organization that deploys Routing and Remote Access NAT is the small office or home office (SOHO) customer. Routing and Remote Access NAT has three optional sub-components — Basic Firewall, DHCP allocator, and DNS proxy — that are designed specifically to provide vital services while simplifying configuration for smaller-sized networks.

Basic Firewall

In Windows Server 2003, the Routing and Remote Access NAT routing protocol component is now integrated with Basic Firewall in order to provide protection to the NAT-enabled router’s Internet interface. Basic Firewall is a simple stateful packet filter that prevents unsolicited traffic originating from a public network, such as the Internet, from reaching a private network through the public interface of the NAT-enabled router. Although enabling the Basic Firewall feature is optional, enabling it is a recommended practice even if your network has other firewall software installed. Enabling Basic Firewall helps secure the NAT-enabled router and strengthens overall network security by protecting the private network from unwanted Internet traffic.

Basic Firewall, which combines stateful packet filtering of network traffic with a set of static packet filters, monitors traffic that travels through the interface for which Basic Firewall is enabled. For an interface configured for private network traffic and to provide NAT, each packet’s source and destination addresses are recorded in a table and all incoming traffic from the public network is compared to the entries in that table. Traffic from a public network can reach the private network only if the table contains an entry that shows that the communication exchange is allowed.

Windows Server 2003 provides two methods to configure the Basic Firewall that is now integrated with Routing and Remote Access NAT:

• If you use the Routing and Remote Access Server Setup Wizard to enable NAT, you can enable the Basic Firewall option during the same setup procedure.

• Alternatively, if the Routing and Remote Access service is already installed with NAT enabled, you can use the Routing and Remote Access snap-in to enable Basic Firewall at any time.

  Note

  • In addition to the Basic Firewall included in the Windows Server 2003 Routing and Remote Access service to protect the public interface of a NAT router, Windows XP, Windows XP SP1, and Windows Server 2003 include Internet Connection Firewall (ICF) to protect the public interface of any server or workstation that provides Internet access to computers on a private network. ICF, which provides a firewall technology similar to Basic Firewall, can be configured by using Network Connections.

For more information about installing and configuring Routing and Remote Access NAT and its optional components, see “NAT Tools and Settings” in this collection.

TCP or UDP Unicast Packets

If Routing and Remote Access NAT has Basic Firewall configured, an incoming TCP or UDP unicast packet is dropped unless it meets one of the following conditions:

• The packet belongs to a previously established mapping, or meets the UDP loose source port criteria (see “How Dynamic Mapping, Static Mapping, and IP Reservations Work” in “NAT Processes and Interactions” later in this document).

• The packet is a DHCP response packet, that is, UDP with source port 67 and destination port 68.

• The packet matches a static port mapping (see “How Dynamic Mapping, Static Mapping, and IP Reservations Work” in “NAT Processes and Interactions” later in this document).

• The packet matches a ticket (dynamic or editor-created). A ticket, in this context, is a statically defined port exemption that allows inbound packets that match this ticket.

• The packet matches a redirect. A redirect changes the destination address and port of packets that match the redirect to the address or port specified in the redirect. In Routing and Remote Access NAT, a redirect is used either by the NAT FTP editor to enable FTP traffic across a NAT, or it is used by NAT deployed in combination with the Microsoft Internet Security and Acceleration (ISA) Server to provide high-security Internet access.

Broadcast and Multicast Packets

If Routing and Remote Access NAT has Basic Firewall configured, the firewall always accepts broadcast and multicast packets and passes them to the NAT component. However, on a computer running the Windows Server 2003, Windows XP SP1, or later operating system, NAT is set by default to drop all inbound broadcast and multicast packets. To change this default behavior, an administrator can add the following registry key and set it to 1 to allow inbound non-unicast traffic, that is, to allow broadcast and multicast packets across Basic Firewall:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IpNat\Parameters\AllowInboundNonUnicastTraffic

By default, AllowInboundNonUnicastTraffic is set to 0, which blocks inbound non-unicast traffic.

Specially Defined Packets

If Routing and Remote Access NAT has Basic Firewall configured, the firewall always accepts specially defined packets for the following IP protocols, which are already protected by IPSec, and passes them to the NAT component:

• IP protocol 50 (or 0x32 in hexadecimal) for Internet Protocol security Encapsulating Security Payload (IPSec ESP), an IPSec protocol that provides confidentiality in addition to authentication, integrity, and replay.

• IP protocol 51 (or 0x33 in hexadecimal) for IPSec Authentication Header (IPSec AH), a header that provides authentication integrity, and anti-replay.

ICMP Traffic

The ICMP protocol, an extension to the Internet Protocol (IP), enables the generation of error messages, test packets, and informational messages related to IP. ICMP is described in RFC 792.

If Routing and Remote Access NAT has Basic Firewall configured, the following firewall behavior for ICMP traffic is defined:

• Inbound echo, timestamp, mask, and router request packets are dropped.

• Inbound echo, timestamp, mask, and router replies are dropped unless there exists a mapping automatically created by a corresponding outbound request.

• Inbound time exceeded, parameter problem, destination unreachable, and source quench are always forwarded.

• Outbound time exceeded, parameter problem, destination unreachable, and source quench are always dropped.

• Redirects are always dropped.

An administrator can configure the ICMP behavior to allow message types that are dropped by default (for example, to allow an echo request).

DHCP Allocator

In Windows Server 2003, the DHCP allocator feature of the Routing and Remote Access NAT routing protocol component provides a simplified form of automatic addressing. Windows Server 2003 (as well as Windows 2000 and Windows NT) supports automatic address acquisition by using the DHCP service. On starting up, a DHCP client obtains its addressing information from a DHCP server automatically, including its default gateway and DNS server. However, DHCP server configuration is complex and might be inappropriate for many SOHO networks. In response to this need, Windows, beginning with Windows 98, also supports Automatic Private IP Addressing (APIPA), in which client computers, when no DHCP server is available, automatically configure themselves with private addresses in the range 169.254.0.1 to 169.254.255.254 with a subnet mask of 255.255.0.0 (or 169.254.0.0/16 in Classless Inter-domain Routing [CDIR] notation). Computers using APIPA addresses can communicate only with other computers that are also using APIPA addresses within a single subnet but cannot connect to computers outside the subnet. This approach works, therefore, only for strictly local networks, but does not cover the case where a local network has a link to the Internet.

The DHCP allocator feature provided by Routing and Remote Access NAT provides a solution that is a combination of the two approaches just described. The DHCP allocator is disabled by default. If you enable it, the Routing and Remote Access NAT-enabled router will function as a simplified DHCP server, that is, it will automatically assign IPv4 addresses to local clients and advertise itself to its DHCP clients as both the default gateway and the DNS server to the Internet. Specifically, the DHCP allocator assigns the following to each client on the private network:

• An IPv4 address and subnet mask.

• The IPv4 address of a default gateway (the private address of the NAT-enabled router).

• The IPv4 address of a DNS server (the private address of the NAT-enabled router; the router will forward a name resolution request that it receives from a client on its private network to the Internet–based DNS server for which the router is configured).

You must configure computers on the private network as DHCP clients in order to automatically receive the IP configuration.

Because the DHCP allocator provided by Routing and Remote Access NAT maintains no database, it does not require additional configuration beyond enabling the DHCP allocator feature. In Routing and Remote Access NAT, the DHCP allocator randomly allocates addresses from the range of configured addresses. For each address generated for a new client, the DHCP allocator uses the TCP/IP ARP module to ascertain whether that address is in use by another client. If a client replies to the ARP message indicating that it is using that address, a new address is generated. Each address assignment has a lease time of 10 minutes to avoid duplicate addresses that might be used by unavailable computers.

Note

• Configuring the NAT DHCP allocator feature works well when all computers on the local network are connected to the same subnet. On the same subnet, computers share each other’s broadcasts and, therefore, can resolve each other’s names by using broadcast NetBIOS name queries. If the network has multiple subnets, you must use a DHCP server rather than the DHCP allocator capability of the NAT/Basic Firewall component.

The DHCP allocator allocates addresses only to clients on permanently connected interfaces (such as LAN media) that are configured as private. You can configure this feature at either of two points:

• If you use the Routing and Remote Access Server Setup Wizard to enable NAT and you choose a network interface with a static IPv4 address as the private interface, you are given the option toenable the DHCP allocator feature for addressing services and the DNS Proxy feature for name resolution services. (For more information about “DNS Proxy,” see “DNS Proxy,” described next.)

• Alternatively, if the Routing and Remote Access service is already installed with NAT enabled, you can use the Routing and Remote Access snap-in to enable the DHCP allocator at any time.

For more information about installing and configuring Routing and Remote Access NAT and its optional components, see “NAT Tools and Settings” in this collection.

DNS Proxy

In Windows Server 2003, the DNS proxy feature of the Routing and Remote Access NAT routing protocol component provides a simplified name resolution service. Windows Server 2003 (as well as Windows 2000 and Windows NT) supports the assignment of DNS server addresses to DHCP clients during DHCP address assignment. This scheme fails in the case of a SOHO where the DNS server resides either with an ISP or on a corporate network because the correct DNS server address cannot be known until after a connection is established. Moreover, the typical SOHO will not have a DHCP server configured.

To solve this problem, a Routing and Remote Access NAT-enabled router that has both the DHCP allocator (described earlier) and the DNS proxy features configured provides its own address as the DNS server address to DHCP clients on the local network. Then, when the connection to the Internet is established, the NAT-enabled router proxies DNS name resolution requests to the Internet DNS server address assigned to the Internet interface of the router. The DNS proxy makes the name resolution process transparent from the point of view of local computers. Like the DHCP allocator, the DNS proxy is disabled by default.

The following list explains how DNS proxy works:

1. The private computer sends a DNS name query request to the DNS proxy (source: private computer IP address, destination: DNS proxy private IP address).

2. DNS proxy saves the DNS name query request in memory and sends a new DNS name query request (source: DNS proxy public IP address, destination: Internet DNS server IP address).

3. The Internet DNS server resolves the name and sends a DNS name query response (source: Internet DNS server IP address, destination: DNS proxy public IP address).

4. DNS proxy matches the received DNS name query response with the saved DNS name query request and sends a new DNS name query response to the private computer (source: DNS proxy private IP address, destination: private computer IP address).

To the private computer, the DNS proxy is a DNS server. To the Internet DNS server, the DNS proxy is a DNS client.

Another possible scenario in a small private network in which no DHCP server exists is to enable the DNS proxy and disable the DHCP allocator. In this case, for each computer on the private network, a static IP address, subnet mask, and default gateway (the IP address of the NAT-enabled router) is configured by using the Network Connections folder to access the TCP/IP properties page for the network adapter on the private network. In addition, on the NAT-enabled router, the address of a DNS server on the Internet is configured as the DNS server for the router by using the TCP/IP properties page on the public interface of the NAT-enabled router. This configuration enables the NAT-enabled router to pass DNS name resolution requests to the Internet DNS server for which it is configured. For more information, see “Using Network Connections to Configure NAT Clients on the Private Network” in “NAT Tools and Settings.”

In a setting where the local network already has a DNS server configured, the DNS proxy can still be useful. In all likelihood, an existing DNS server is configured to forward Internet name resolution requests to a static Internet DNS server address. This static configuration will fail whenever the address of the Internet DNS server changes. With automatic name resolution provided by the DNS proxy feature, you can configure the existing DNS server to forward Internet DNS requests to the local address of the DNS proxy, and the DNS proxy will then handle the task of dynamically finding the Internet DNS server address when the Internet connection is established.

Using DNS proxy provides an adequate solution even if multiple routed segments exist. In that event, you must disable the DHCP allocator (if it is enabled), configure a full DHCP server, and then configure the DHCP server to give the NAT-enabled router’s local address on each subnet as the DNS server address for clients on that subnet. However, if multiple subnets are configured, the recommended option is to automatically install a full DNS server in default mode, which provides caching and name registration in addition to the name resolution.

NAT Processes and Interactions

This section covers the following topics:

• How NAT works with TCP/IP

• How address and port translation work

• How dynamic and static mappings and IP reservations work

• How NAT editors work

• How mapping and translation work together

How NAT Works with TCP/IP

Routing and Remote Access NAT is implemented as a routing protocol component that TCP/IP calls when a packet is sent or received. For the benefit of modules such as firewalls, the TCP/IP driver supports a pointer that sets the callout that TCP/IP invokes for incoming and outgoing data packets. The parameters of the TCP/IP callout include the IP header and data and the context for the incoming or outgoing interface. The function to which TCP/IP calls out indicates whether the data packet should be forwarded, dropped, or processed as local host traffic. TCP/IP also allows the function to provide a replacement for the data packet, to accommodate any modifications that the NAT driver might make to the packet.

When mapping between public and private addresses when a pool of public addresses exists, NAT uses TCP/IP’s Proxy ARP mechanism to respond to ARP queries for public addresses in the pool.

In the translation process, the NAT routing protocol component makes routing decisions in order to determine the interface over which to forward any given packet. To avoid consulting TCP/IP for each packet, a cache is implemented in the NAT. To keep the cache consistent with the TCP/IP forwarding database, the NAT registers for notification of route changes with TCP/IP.

How Address and Port Translation Work

The Routing and Remote Access NAT-enabled router, located, logically, at the edge point between the private and public networks, mediates between its private network and the resources on the Internet that its users want to access. To do so, the router uses both address and port translation, as described in this section.

The NAT driver modifies the source address and port in the header of TCP or UDP packets sent from a client on the private network to the public network, while also modifying the destination address and port in packets returned from the public network to the private network. Specifically, for an application for which the IPv4 address and port information is located in the IP and TCP or UDP headers (the type of application for which NAT was originally designed), the NAT-enabled router can translate the following:

• IPv4 address in the IP header

• Port number (either a TCP port number in the TCP header, or a UDP port number in the UDP header)

For example, traffic between a private network and the Internet — Hypertext Transfer Protocol (HTTP) traffic used to access Web servers — requires the translation of the IPv4 address in the IP header and, possibly, the TCP port in the TCP header. Some applications, however, embed address or port information inside the data portion of the packet or do not use TCP or UDP ports to identify the data stream. Translation for these applications is more complicated, and for such translation to take place, an appropriate NAT editor must exist. For more information about NAT editors, see “How NAT Editors Work” later in this section.

Outgoing and Incoming Packet Translation

When a computer user on the private network connects to a resource on the Internet (or other public network), the computer’s TCP/IP protocol creates an IP packet with values for the source address and port as well as for the destination address and port. This information is set in the IP header and in the TCP header (or UDP header), as shown in the center column of the following table. The source computer (or an intermediate router) forwards this packet to the NAT-enabled router. The router then translates the source address and port of the outgoing packet, as shown in the right column of the same table. Information modified by this translation is shown in the table in italic text:

Example of Translation of Address and Port of Outgoing Packet

Address and Port	Outgoing Packet Header When Client Initiates Request	Outgoing Packet Header after NAT Translates Source Address and Port
Source IPv4 Address	Private IPv4 address	ISP-allocated public IPv4 address1
Source Port	Source application TCP or UDP port	Remapped source application TCP or UDP port
Destination IPv4 Address	Internet resource IPv4 address	Internet resource IPv4 address
Destination Port	Internet resource TCP or UDP port	Internet resource TCP or UDP port

1 This example is a case in which the public address on the Internet interface of the NAT-enabled router is allocated by an organization’s ISP

The NAT-enabled router then sends the remapped IP packet over the Internet. When the Internet resource sends back a response to the NAT, the incoming packet contains the information shown in the center column of the next table, “Example of Translation of Address and Port of Incoming Packet.” After the NAT maps and translates the destination address and port, it contains the information as shown in the right column of that table. The NAT-enabled router forwards the translated packet to the intranet client that made the initial request. Information modified by this translation is shown in the following table in italic text.

Example of Translation of Address and Port of Incoming Packet

Address and Port	Incoming Packet Header When Internet Resource Sends Response	Incoming Packet Header After NAT Translates Destination Address and Port
Source IPv4 Address	Internet resource IPv4 address	Internet resource IPv4 address
Source Port	Internet resource TCP or UDP port	Internet resource TCP or UDP port
Destination IPv4 Address	ISP-allocated public IPv4 address1	Private IPv4 address
Destination Port	Remapped source application TCP or UDP port	Source application TCP or UDP port

1 This example is a case in which the public address on the Internet interface of the NAT-enabled router is one allocated by an organization’s ISP

For outgoing packets, the source IPv4 address and TCP or UDP port numbers are mapped to a public source IPv4 address and a possibly changed TCP or UDP port number. For incoming packets, the destination IPv4 address and TCP or UDP port numbers are mapped to the private IPv4 address and original TCP or UDP port number.

Network Address Port Translation

All computers on the private network behind the NAT-enabled IP router, including the router itself, have a unique private IPv4 address and a private port number. The router also has at least one globally unique (public) IPv4 address. Optionally, an administrator can configure the router with a pool of public addresses so that multiple clients can request public network resources at the same time. The router can handle traffic for multiple clients on its private network even when it does not have a sufficient number of addresses in its public address pool to accommodate all of the clients requesting access to the public network. It can accommodate additional clients by using Network Address Port Translation (NAPT) to modify port information in the TCP or UDP packets being transmitted. RFC 3022 describes NAPT.

NAPT extends address translation by using many-to-one mapping — multiple private addresses are mapped to a single public address on the Internet interface of the NAT-enabled router. This is helpful because the number of clients with private addresses is ordinarily far larger than the available number of public addresses on the NAT-enabled router, even if the router is configured with a relatively large number of addresses in a public address pool. When the public addresses in the pool have all been translated, NAT starts to perform port translation instead of address translation.

For TCP or UDP communications, the address and port translation functionality made available by NAPT permits a client on a private network to access multiple computers on the Internet, and it enables multiple private clients to access the same Internet computer at the same time. Because both TCP and UDP ports have 16 bits, NAPT allows up to 65,535 (216-1) communications to take place at the same time. One is subtracted from the total number because port 0 for both TCP and UPD is reserved.

Address and Port Translation Example

How NAPT works is best understood through an example. Consider the simple case of a private network with three computers — Client A, Client B, and Client C — that use the private network IPv4 range of 192.168.0.0 with a subnet mask of 255.255.255.0. The NAT-enabled router is configured with a public pool containing the following IPv4 addresses:

157.54.35.38

157.54.35.39

The user on Client A initiates a request to look at a Web page on the Internet, so Client A sends a TCP packet to the NAT-enabled router. The NAT driver translates the packet and adds an entry for it to the NAT Mapping Table. The following figure depicts the packet translation and the entry made into the mapping table for Client A:

Packet Translation and NAT Mapping Table Entry for Client A

Next, the user on Client B initiates another TCP session with a host on the public network. The following figure depicts the packet translation for Client B and the new entry for Client B, which is added to the mapping table that already contains the entry for Client B.

Packet Translation and NAT Mapping Table Entry for Client B

Finally, the user on Client C initiates traffic from the private to the public network and thus sends a packet to the NAT-enabled router. However, the public address pool configured on the NAT-enabled router contains only two addresses, which have already been used for Clients A and B. In this case, the NAT driver translates Client C’s private address:port pair to a unique public address:port pair by changing the public port number. That is, when the pool of public addresses, which is fewer in number than the number of clients on the private network, is exhausted, the NAT driver switches from address translation to port translation. The following figure depicts the packet translation for Client C and the new entry for Client C in the mapping table.

Packet Translation and NAT Mapping Table Entry for Client C

When the resource on the public network to which each client sent a request sends a response back to the client on the private network, the same process occurs in reverse: The NAT driver intercepts the response packet, looks up the packet’s destination address in the NAT Mapping Table, finds the corresponding address of a private network client, modifies the destination address and destination port in the response packets — this time translating the packet’s public destination address and port number back to the client’s private address and port number — recomputes the checksum (which it must do any time it replaces an address in a packet header), and then sends the response across the private network to the client.

How Dynamic and Static Mappings and IP Reservations Work

In addition to the dynamic mapping just introduced in “How Address and Port Translation Work,” Routing and Remote Access NAT technology provides for two additional types of entries in the NAT Mapping Table: static mapping and IP reservations. Each of the three mapping types is designed for a different purpose.

Dynamic Mapping

Whenever a NAT-enabled router receives an outgoing TCP or UDP packet from a local client that is initiating communications with a computer on the public network, the NAT driver creates an entry in the NAT Mapping Table, called a 5-tuple entry, that contains the following five pieces of information:

{protocol (TCP or UDP), private address, private port, public address, public port}

An alternative notation representing this 5-tuple entry is the following:

{protocol (TCP or UPD), source address, source port, destination address, destination port}

The private address and port pair are automatically (dynamically) mapped to the public address and port pair. This is the type of mapping illustrated earlier in “How Address and Port Translation Work.” This entry in the NAT Mapping Table enables the NAT-enabled router to direct a response packet from a computer on the public network back to the client on the private network that sent initial the request.

Because the number of mappings that can be established is limited by the number of available 16-bit TCP and UDP ports, the NAT driver must eventually delete the dynamic mappings that it creates in order to free up port numbers for use in new mappings. A dynamic mapping entry remains in the mapping table for the length of time that the administrator specifies on the Translation tab for the properties of the NAT/Basic Firewall component in the Routing and Remote Access snap-in. Routing and Remote Access NAT, by default, uses the RFC 1631 recommended timeouts of 24 hours for idle TCP mappings and 1 minute for idle UDP mappings.

Static Mapping

With dynamic mapping, in order for a TCP or UDP packet to pass through the NAT from the public network to the private network, a mapping must have been established previously by a packet sent from the private to the public network. However, if a client on the public network attempts to establish a TCP or UDP session with a computer on the private network (such as a Web server on the private network or a computer on the private network that provides a game application), no dynamic mapping will be found and the incoming packet will be discarded.

If an organization wants to allow such incoming traffic to a specific computer on the private network, Routing and Remote Access NAT allows an administrator to use the Services and Ports tab on the properties page of the public interface in the Routing and Remote Access snap-in to configure a static mapping for this traffic. Thus, the way that the NAT-enabled router forwards Internet traffic into its private network is either in response to traffic initiated by a user on the private network, which creates a dynamic mapping, or because an administrator has configured a static mapping to enable Internet users to access specific resources on the private network. (For an alternative to static mapping, see “IP Reservations” later in this section).

Static mappings have limited usefulness for connections between a private network and the Internet because of the large number of possible connections. Too many connections can make the NAT Mapping Table grow excessively and thus slow router performance.

A static mapping consists of a 5-tuple entry identical in content to a dynamic mapping entry:

{protocol (TCP or UDP), private address, private port, public address, public port}

Unlike a dynamic mapping, a static mapping explicitly matches a given TCP or UDP port number to both the private and the public address in the static entry in the mapping table. For example, to set up a Web server on a computer on a private network, an administrator could create a static mapping that maps [Public IPv4 Address, TCP Port 80] to [Private IPv4 Address, TCP Port 80]. Port 80 is, by convention, assigned to the World Wide Web (WWW) and used by Web servers for HTTP traffic. When a packet arrives for Public IPv4 Address and Port 80, the NAT-enabled router directs the packet to the Web server on the private network.

Any server running on a well-known port on the private network (such as HTTP or FTP servers) can have only one instance accessible to clients running on the public network.

Multiple interfaces can have translation enabled at the same time, as in the case of a home where a user connects both to the Internet and to a corporate network. Therefore, static mappings in Routing and Remote Access NAT can be configured on a per-interface basis.

A static mapping entry remains in the mapping table until an administrator deletes it.

UDP Source Port Allocation and Loose Source Matching

To better support various types of peer-to-peer applications, the NAT mapping behavior for UDP differs from that of TCP in the following two ways:

How NAT chooses the source port for outbound dynamic mappings.

When creating a new TCP mapping for an outbound packet, the NAT driver chooses a source port without regard for already existing mappings as long as such a choice does not result in a conflict. In contrast, when choosing a source port for a UDP mapping for an outbound packet, the NAT driver determines if a mapping exists that has the same private address and port. If such a mapping exists, the NAT driver will use the same public port for the new mapping. For example:

• If a client on the private network makes a TCP connection to two different computers on the public network from the same source port, the NAT driver will choose different source ports for those mappings.

• If a client on the private network sends UDP packets to two different computers on the public network from the same source port, the NAT driver will use the same source port for both mappings.

How NAT determines whether an inbound packet matches an existing dynamic or static mapping.

For TCP, an inbound packet must exactly match the 5-tuple for a mapping (that is, protocol, source address, source port, destination address, and destination port). For UDP, however, an inbound packet must match only the protocol, destination address, and destination port of a mapping — the source address and source port of the packet are effectively ignored. This “loose matching behavior” applies only if the private port is greater than 1024. Allowing this behavior for ports below 1024 would introduce a security risk because it might allow unfettered access to such sensitive TCP and UDP ports as 137 (NetBIOS Name service) and 445 (Microsoft Common Internet File System [CIFS]).

IP Reservation

If you want to allow a computer on the Internet to initiate a connection to a computer on the private network behind the NAT-enabled router, an alternative to using static mapping is to configure an IP reservation to handle this traffic. If you establish a public IPv4 address reservation to one of the private IPv4 addresses on the private network, all incoming traffic addressed to the specified public address is sent to the private address reserved for it. Thus, instead of putting a computer directly on the public network, the traffic is transmitted through the NAT-enabled router. For both static mapping and IP reservations, this is an advantage because, typically, the router is configured with a firewall and other filters.

For example, you might want to use an IP reservation to allow traffic to a Web server on the private network. You can allow such incoming traffic by first using the Address Pool tab on the properties page of the public interface in the Routing and Remote Access snap-in to configure an IP address pool (you cannot configure an IP reservation until after you configure at least one IP address pool). You can then configure the IP reservation itself by using the Reservations button on the Address Pool tab.

IP reservations are particularly useful when the number of public IP addresses on the NAT-enabled router is large — reservations provide an easy way to map public to private addresses. In addition, IP reservations are useful for IP protocols that pick port numbers randomly, which means that the administrator does not need to know the port numbers in advance. IP reservations can also be used for IP protocols that do not use ports because this process is independent of the protocol (whether TCP, UDP, or ICMP). For an example showing how IP reservations work, see “Static Mapping and IP Reservation Examples” later in this document.

For outgoing traffic from a computer on the private network for which an IP reservation exists, the NAT-enabled router does not use the public IP address reserved for that private computer. Outgoing traffic from a computer on the private network to any destination on the Internet, including traffic to a Web server for which an IP reservation exists, is handled by the NAT-enabled router by using standard address and port translation.

When a network administrator uses the Routing and Remote Access snap-in to create an IP reservation, a 2-tuple entry is entered in the NAT Mapping Table:

{private address, public address}

An IP reservation remains in the mapping table until an administrator deletes it.

Dynamic and Static Mappings More Restrictive than IP Reservations

The behavior of dynamic and static mapping entries and IP reservations is determined by the amount of information each stores:

• 5-tuple dynamic and static mappings are more restrictive than IP reservations because incoming or outgoing traffic must match all five pieces of information in the NAT Mapping Table entry before the packet will be forwarded; or, in the case of UDP for ports greater than 1024, an inbound packet must match three pieces of information — the protocol, destination address, and destination port.

• 2-tuple IP reservations are less restrictive than either dynamic or static mappings because incoming or outgoing traffic that has a destination IPv4 address that matches the public IPv4 address in the NAT Mapping Table entry will be forwarded.

Static Mapping and IP Reservation Examples

To continue the example presented earlier in “How Address and Port Translation Work,” which illustrates dynamic mapping, an administrator next decides to use Client B as a Web server and therefore uses the Routing and Remote Access snap-in to add a static mapping for Client B. This mapping means that all inbound TCP traffic directed to 157.54.35.38 and port 80 on the NAT-enabled router will match that address:port pair to Client B’s own address and port 80. Thus, the NAT Mapping Table shown in the earlier figure, “Packet Translation and NAT Mapping Table Entry for Client C,” changes to include a second entry for Client B (the new fourth row), as shown in the following table.

Static Mapping of Client B’s Private Address and Port to a Public Address and Port

Client	Private Address:Port	Protocol	Public Address:Port	Type
A	192.168.0.10:3576	TCP	157.54.35.38:5000	Dynamic address translation
B	192.168.0.11:2258	TCP	157.54.35.39:5000	Dynamic address translation
C	192.168.0.12:1944	TCP	157.54.35.39:5001	Dynamic port and address translation
B	192.168.0.11:80	TCP	157.54.35.38:80	Static address translation

If the administrator then uses the Routing and Remote Access snap-in to add an IP reservation to the NAT Mapping Table, reserving public IPv4 address 157.54.35.39 for Client A, any existing dynamic mappings to 157.54.35.39 are preempted by this change. That is, the earlier dynamic mappings to the public address 157.54.35.39 no longer exist. Only the IP reservation for 157.54.35.39 remains in the NAT Mapping Table, as shown in the following table.

IP Reservation of Client A’s Private Address to a Public Address

Client	Private Address:Port	Protocol	Public Address:Port	Type
A	192.168.0.10:3576	TCP	157.54.35.38:5000	Dynamic address translation
B	192.168.0.11:80	TCP	157.54.35.38:80	Static address translation
A	192.168.0.10:*	*	157.54.35.39.*	IP reservation address translation

With an IP reservation, as the asterisks in the last row of the preceding table indicate, it is irrelevant which protocol (TCP or UDP) is used or what the destination port number is on an inbound packet. All that matters is that the destination address is matched to the public IPv4 address in the reservation. Therefore, in the example in the preceding table, any traffic with a destination IPv4 address of 157.54.35.39 is forwarded to client A.

Summarizing Packet Translation

To summarize outbound and inbound packet translation:

• When a TCP or UDP packet outbound to the Internet from a client on the private network arrives at the private interface of the NAT-enabled router, the NAT driver looks in the NAT Mapping Table for an existing dynamic mapping. If none is found, the NAT driver creates a new mapping, updates the checksum, and sends the packet out to the Internet over a dial-up, broadband, or other connection.

• When a TCP or UDP packet inbound from the Internet arrives at the Internet interface of the NAT-enabled router, the NAT driver looks in the NAT Mapping Table for an existing dynamic or static mapping or for an IP reservation. If any of the three types of entries is found, the NAT driver translates the incoming packet and delivers it over the private interface of the NAT-enabled router to the client. Otherwise, the packet is discarded.

How NAT Editors Work

In Routing and Remote Access NAT, the NAT driver is designed to translate IPv4 address and TCP or UDP port information for traffic between a private and a public network. If the IPv4 address and port information is located only in the IP and TCP or UDP headers — as is the case, for example, for HTTP (World Wide Web) traffic — the NAT driver can translate the application protocol transparently. However, the NAT driver, on its own, cannot translate packets in the following two types of cases:

An IPv4 address, TCP port, or UDP port is stored in the payload.

Certain applications embed address or port information inside the data portion of the packet rather than in the IP and TCP or UDP headers. One such application is the File Transfer Protocol (FTP) — for the FTP port command, FTP stores the IPv4 address in the FTP header. In addition, FTP stores the IPv4 address in dotted decimal format, which means that the translated IPv4 address in the FTP header can be a different size, and, therefore, the TCP sequence numbers must be modified to ensure that no data is lost. Other examples of applications that the NAT driver cannot translate transparently include streaming applications, such as RealAudio and CUSeeMe, which use a TCP connection to dynamically select a UDP port over which data is then transmitted.

TCP or UDP is not being used to identify the data stream.

Data that is tunneled from one geographic site to another through the Internet by using the Point-to-Point Tunneling Protocol (PPTP) does not use a TCP or UDP header. Instead, PPTP data uses a Generic Routing Encapsulation (GRE) header, and the Call ID, which is stored in the GRE header, identifies the data stream. If the NAT driver does not correctly translate the Call ID within the GRE header, connectivity problems can occur.

NAT editors are application level gateways (ALGs) that have been developed to translate packets in these two cases. A NAT editor examines the packets sent by such applications and modifies the data portion of the packet as appropriate. Because such modifications might change the size of packets, a NAT editor must also adjust sequence numbers for TCP connections after any translation has changed the number of bytes in the TCP data stream.

The Windows Server 2003 Routing and Remote Access service installs two built-in NAT editors along with the NAT routing protocol component — Internet Control Message Protocol (ICMP) to support error messages, and Point-to-Point Tunneling Protocol (PPTP) to support PPTP VPN traffic. Both editors are always on. The NAT driver consults the editors whenever the payload of the packet being translated matches one of the installed editors. The editor modifies the payload and returns the result to the NAT driver.

Note

• In addition to the NAT editors, Routing and Remote Access NAT includes two NAT proxies, which redirect packets to a module that builds a new packet modified so that it can cross a NAT. The NAT proxies are the File Transfer Protocol (FTP) proxy, which supports FTP traffic across a NAT, and the H.323 proxy, which supports NetMeeting calls across a NAT. Unlike NAT editors, which are always on, NAT proxies are disabled by default. Both proxies can be turned on or off by using the appropriate Netsh command in the netsh routing ip nat context: you can enable the NAT proxies by using add ftp or add h323; you can disable the NAT proxies by using delete ftp or delete h323.

How Mapping and Translation Work Together

The two flowcharts in this section, “Processing for Outbound and Inbound NAT Traffic” and “Packet Translation Process,” outline the overall process that the Routing and Remote Access NAT-enabled router uses to manage outbound and inbound packets.

First, the router determines whether the packet is outbound or inbound. Depending on the outcome of that initial determination, the following occurs:

Outbound traffic

For traffic from the private network that is outbound to the Internet (or other public network), the NAT driver assesses whether or not an address/port mapping (whether a static or dynamic mapping, or an IP reservation) exists for the packet. If such a mapping exists, the NAT driver uses the existing mapping; if none exists, the NAT driver creates a new dynamic mapping. Whether a single IPv4 address or a pool of addresses is available determines how that mapping is made (see “How Address and Port Translation Work” earlier in this section). Next, the NAT driver checks for editors and invokes one if necessary (assuming that one exists). If no editor is needed, the NAT driver performs standard network address translation of the TCP or UDP header and the IP header (for an outbound packet, translating the source TCP or UDP port and the source IP address), and then refreshes the NAT Mapping Table. Finally, the NAT-enabled router uses its Internet interface to forward the outgoing packet to the resource computer on the Internet.

Inbound traffic

For a response or other specifically allowed incoming traffic from the Internet (or other public network) that is inbound to the private network, the NAT driver also assesses whether or not an address/port mapping (whether static or dynamic mapping, or an IP reservation) exists for the packet. If a mapping exists, the NAT driver uses the existing mapping; if no mapping exists, the incoming packet is discarded. Next, the NAT driver checks for editors and invokes one if necessary (assuming that one exists). If no editor is needed, the NAT driver performs standard network address translation of the TCP or UDP header and the IP header (for an inbound packet, translating the destination TCP or UDP port and the destination IP address), and then refreshes the NAT Mapping Table. Finally, the NAT-enabled router uses its private interface to forward the incoming packet to the appropriate computer on the private network.

Of the following two flowcharts, the second is a continuation of the first. In the first flowchart, “Processing for Outbound and Inbound NAT Traffic,” the two process boxes (one on the left and another on the right) labeled “Performs packet translation” both point to the second flowchart, “Packet Translation Process.”

Processing for Outbound and Inbound NAT Traffic

Packet Translation Process

Related Information

For more information about NAT, see the following RFCs in the IETF RFC Database:

• RFC 1631, “The IP Network Address Translator (NAT).”

• RFC 3022, “Traditional IP Network Address Translator (Traditional NAT).”

• RFC 1918, “Address Allocation for Private Internets.”

• RFC 2663, “IP Network Address Translator (NAT) Terminology and Considerations.”

The following resource contains additional information that is relevant to this section:

• “Network Address Translation (NAT)” in Internetworking with TCP/IP, Vol. 1: Principles, Protocols, and Architecture, Fourth Edition, by Douglas E. Comer, Prentice Hall, New Jersey, 2000.