Virtual Private Networking

VPNs and Network Address Translators

Reprinted with permission from the Windows 2000 Resource Kits

In This Chapter

VPNs and Network Address Translators

A network address translator (NAT) is an IP router with the ability to translate the IP address and TCP/UDP port numbers of packets as they are forwarded. Consider the small business wanting to connect multiple computers to the Internet. It normally has to obtain a public address for each computer on the small business network. With a NAT, however, the small business does not need multiple public addresses. It can use private addresses (as documented in RFC 1597) on the small business network segment and use the NAT to map the private addresses to one or more public IP addresses as allocated by an ISP. NAT functionality is documented in RFC 1631.

For example, if a small business is using the 10.0.0.0/8 network for its private network, and has been granted the public IP address of w.x.y.z by the ISP, the NAT statically or dynamically maps all private IP addresses used on network 10.0.0.0/8 to the IP address of w.x.y.z.

For outgoing packets, the source IP address and TCP/UDP port numbers are mapped to w.x.y.z and a possibly changed TCP/UDP port number. For incoming packets, the destination IP address and TCP/UDP port numbers are mapped to the private IP address and original TCP/UDP port number.

By default, a NAT translates IP addresses and TCP/UDP ports. If the IP address and port information is only in the IP and TCP/UDP headers, the application protocol can be translated transparently, such as with HyperText Transfer Protocol (HTTP) traffic on the World Wide Web.

However, some applications and protocols store IP address or TCP/UDP port information within their own headers. FTP, for example, stores the dotted decimal representation of IP addresses in the FTP header for the FTP PORT command. If the NAT does not properly translate the IP address within the FTP header, connectivity problems can occur. In addition, some protocols do not use TCP or UDP headers but use fields in other headers to identify data streams.

When the NAT component must additionally translate and adjust the payload beyond the IP, TCP, and UDP headers, a NAT editor is required. A NAT editor properly modifies otherwise non-translatable payloads so that they can be forwarded across a NAT.

Address and Port Mapping for VPN Traffic

In order for PPTP and L2TP over IPSec tunnels to work over a NAT, the NAT must be able to map multiple data streams to and from a single IP address.

PPTP Traffic

PPTP traffic consists of a TCP connection for tunnel maintenance and GRE encapsulation for tunneled data. The TCP connection is NAT-translatable because the source TCP port numbers can be transparently translated. However, the GRE-encapsulated data is not NAT-translatable without an editor.

With tunneled data, the tunnel is identified by the source IP address and the Call ID field in the GRE header. When there are multiple PPTP clients on the private side of a NAT tunneling to the same PPTP server, all the tunneled traffic has the same source IP address. Also, because the PPTP clients are unaware that they are being translated, they might pick the same Call ID when establishing the PPTP tunnel. Therefore, it is possible for tunneled data from multiple PPTP clients on the private side of the NAT to have the same source IP address and same Call ID when translated.

To prevent this problem, a NAT editor for PPTP must monitor the PPTP tunnel creation and create separate mappings between a private IP address and Call ID as used by the PPTP client to a public IP address and unique Call ID received by the PPTP server on the Internet.

The NAT routing protocol of the Routing and Remote Access service, contains a PPTP editor that translates the GRE Call ID in order to distinguish between multiple PPTP tunnels on the private side of the NAT.

L2TP over IPSec Traffic

L2TP over IPSec traffic is not translatable by a NAT because the UDP port number is encrypted, and its value is protected with a cryptographic checksum. L2TP over IPSec is not translatable even with an editor for the following additional reasons:

Inability to distinguish multiple IPSec ESP data streams

The ESP header contains a field called the Security Parameters Index (SPI). The SPI is used in conjunction with the destination IP address in the plaintext IP header and IPSec security protocol (ESP or Authenticating Header [AH]) to identify an IPSec security association (SA).

For outbound traffic from the NAT, the destination IP address is not changed. For inbound traffic to the NAT, the destination IP address must be mapped to a private IP address. Just as in the case of multiple PPTP clients on the private side of a NAT, the destination IP address of inbound traffic for multiple IPSec ESP data streams is the same address. To distinguish one IPSec ESP data stream from another, the destination IP address and SPI can be mapped to a private destination IP address and SPI. However, because the ESP Auth trailer contains a cryptographic checksum that verifies the ESP header and its payload, the SPI cannot be changed without invalidating the cryptographic checksum.

Inability to change TCP and UDP checksums

In L2TP over IPSec packets, UDP and TCP headers contain a checksum that includes the source and destination IP address of the plaintext IP header. The addresses in the plaintext IP header cannot be changed without invalidating the checksum in the TCP and UDP headers. The TCP and UDP checksums cannot be updated because they are within the encrypted portion of the ESP payload.


© 1985-2000 Microsoft Corporation. All rights reserved.