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.
  
  

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.

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.
  
  

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).

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 address 1
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 address 1	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.

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.

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.

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.

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.

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:

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.

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.
  
  

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.

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.