Virtual Private Networking
Virtual Private Networking |
|
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 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 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:
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.
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.