Point-to-Point Tunneling Protocol
The Point-to-Point Tunneling Protocol (PPTP) encapsulates Point-to-Point Protocol (PPP) frames into IP datagrams for transmission over an IP-based internetwork, such as the Internet or a private intranet. PPTP is documented in RFC 2637.
The PPTP uses a TCP connection known as the PPTP control connection to create, maintain, and terminate the tunnel and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames as tunneled data. The payloads of the encapsulated PPP frames can be encrypted or compressed or both.
PPTP assumes the availability of an IP internetwork between a PPTP client (a VPN client using the PPTP tunneling protocol) and a PPTP server (a VPN server using the PPTP tunneling protocol). The PPTP client might already be attached to an IP internetwork that can reach the PPTP server, or the PPTP client might have to dial into a network access server (NAS) to establish IP connectivity as in the case of dial-up Internet users.
Authentication that occurs during the creation of a PPTP-based VPN connection uses the same authentication mechanisms as PPP connections, such as Extensible Authentication Protocol (EAP), Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), CHAP, Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP). PPTP inherits encryption or compression, or both, of PPP payloads from PPP. For Windows 2000, either EAP-Transport Level Security (EAP-TLS) or MS-CHAP must be used in order for the PPP payloads to be encrypted using Microsoft Point-to-Point Encryption (MPPE).
MPPE provides only link encryption, not end-to-end encryption. End-to-end encryption is data encryption between the client application and the server hosting the resource or service being accessed by the client application. If end-to-end encryption is required, IPSec can be used to encrypt IP traffic from end-to-end after the PPTP tunnel is established.
For Internet-based PPTP servers, the PPTP server is a PPTP-enabled VPN server with one interface on the Internet and a second interface on the intranet.
Tunnel Maintenance with the PPTP Control Connection
The PPTP control connection is between the IP address of the PPTP client using a dynamically allocated TCP port and the IP address of the PPTP server using the reserved TCP port 1723. The PPTP control connection carries the PPTP call control and management messages that are used to maintain the PPTP tunnel. This includes the transmission of periodic PPTP Echo-Request and PPTP Echo-Reply messages to detect a connectivity failure between the PPTP client and PPTP server. PPTP control connection packets consist of an IP header, a TCP header, and a PPTP control message as illustrated in Figure 9.8. The PPTP control connection packet in Figure 9.8 also includes a data-link layer header and trailer.
.gif "Cc958045.INBE08(en-us,TechNet.10).gif")
Figure 9.8 PPTP Control Connection Packet
Table 9.5 lists the primary PPTP control messages that are sent over the PPTP control connection. For all of the PPTP control messages, the specific PPTP tunnel is identified by the TCP connection.
Table 9.5 PPTP Call Control and Connection Management Messages
Message Type |
Purpose |
|---|---|
Start-Control-Connection-Request |
Sent by the PPTP client to establish the control connection. Each PPTP tunnel requires a control connection to be established before any other PPTP messages can be issued. |
Start-Control-Connection-Reply |
Sent by the PPTP server to reply to the Start-Control-Connection-Request message. |
Outgoing-Call-Request |
Sent by the PPTP client to create a PPTP tunnel. Included in the Outgoing-Call-Request message is a Call ID that is used in the GRE header to identify the tunneled traffic of a specific tunnel. |
Outgoing-Call-Reply |
Sent by the PPTP server in response to the Outgoing-Call-Request message. |
Echo-Request |
Sent by either the PPTP client or PPTP server as a keep-alive mechanism. If the Echo-Request is not answered, the PPTP tunnel is eventually terminated. |
Echo-Reply |
The reply to an Echo-Request. |
WAN-Error-Notify |
Sent by the PPTP server to all VPN clients to indicate error conditions on the PPP interface of the PPTP server. |
Set-Link-Info |
Sent by the PPTP client or PPTP server to set PPP-negotiated options. |
Call-Clear-Request |
Sent by the PPTP client indicating that a tunnel is to be terminated. |
Call-Disconnect-Notify |
Sent by the PPTP server in response to a Call-Clear-Request or for other reasons to indicate that a tunnel is to be terminated. If the PPTP server terminates the tunnel, a Call-Disconnect-Notify is sent. |
Stop-Control-Connection-Request |
Sent by the PPTP client or the PPTP server to inform the other that the control connection is being terminated. |
Stop-Control-Connection-Reply |
Used to reply to the Stop-Control-Connection-Request message. |
For information about the exact structure of PPTP control connection messages, see RFC 2637.
PPTP Data Tunneling
PPTP data tunneling is performed through multiple levels of encapsulation.
Figure 9.9 shows the resulting structure of PPTP tunneled data.
.gif "Cc958045.INBE09(en-us,TechNet.10).gif")
Figure 9.9 PPTP Tunneled Data
Encapsulation of PPP Frame
The initial PPP payload is encrypted and encapsulated with a PPP header to create a PPP frame. The PPP frame is then encapsulated with a modified GRE header. GRE is documented in RFC 1701 and RFC 1702 and was designed to provide a simple, lightweight, general purpose mechanism for encapsulating data sent over IP internetworks. GRE is a client protocol of IP using IP protocol 47.
For PPTP, the GRE header is modified in the following ways:
An acknowledgement bit is used to indicate that a 32-bit acknowledgement field is present and significant.
The Key field is replaced with a 16-bit Payload Length field and a 16-bit Call ID field. The Call ID field is set by the PPTP client during the creation of the PPTP tunnel.
A 32-bit Acknowledgement field is added.
Within the GRE header, the Protocol Type is set to 0x880B, the EtherType value for a PPP frame.
.gif "note-icon")
Note
GRE is sometimes used by ISPs to forward routing information within an ISP's network. To prevent the routing information from being forwarded to Internet backbone routers, ISPs filter out GRE traffic on the interfaces connected to the Internet backbone. As a result of this filtering, PPTP tunnels can be created using PPTP control messages, but PPTP tunneled data is not forwarded. If you suspect that this is a problem, contact your ISP.
Encapsulation of GRE Packet
The resulting GRE and PPP-encapsulated payload is then encapsulated with an IP header containing the appropriate source and destination IP addresses for the PPTP client and PPTP server.
Data-Link Layer Encapsulation
To be sent on a local area network (LAN) or WAN link, the IP datagram is finally encapsulated with a header and trailer for the data-link layer technology of the outgoing physical interface. For example, when IP datagrams are sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link, such as an analog phone line or ISDN, the IP datagram is encapsulated with a PPP header and trailer.
Processing of the PPTP Tunneled Data
Upon receipt of the PPTP tunneled data, the PPTP client or PPTP server:
Processes and removes the data-link header and trailer.
Processes and removes the IP header.
Processes and removes the GRE and PPP headers.
Decrypts or decompresses, or both, the PPP payload (if needed).
Processes the payload for receipt or forwarding.
PPTP Packets and Windows 2000 Networking Architecture
Figure 9.10 illustrates the path that tunneled data takes through the Windows 2000 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline this process:
An IP datagram, IPX datagram, or NetBEUI frame is submitted by its appropriate protocol to the virtual interface that represents the VPN connection using Network Driver Interface Specification (NDIS).
NDIS submits the packet to NDISWAN, which encrypts or compresses the data, or both, and provides a PPP header consisting of only the PPP Protocol ID field. No Flags or Frame Check Sequence (FCS) fields are added. This assumes that address and control field compression were negotiated during the Link Control Protocol (LCP) phase of the PPP connection process. For more information about PPP and LCP, see "Remote Access Server" in this book.
NDISWAN submits the data to the PPTP protocol driver, which encapsulates the PPP frame with a GRE header. In the GRE header, the Call ID field is set to the appropriate value to identify the tunnel.
The PPTP protocol driver then submits the resulting packet to the TCP/IP protocol driver.
The TCP/IP protocol driver encapsulates the PPTP tunneled data with an IP header and submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.
NDIS submits the packet to NDISWAN, which provides PPP headers and trailers.
NDISWAN submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware (for example, the asynchronous port for a modem connection).
.gif "Cc958045.INBE10(en-us,TechNet.10).gif")
Figure 9.10 PPTP Packet Development
Note
It is possible to negotiate an encrypted PPP connection for the dial-up connection with the ISP. This is unnecessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted. The additional level of encryption is not needed and can impact performance.
Windows 2000 Network Load Balancing allows you to build a cluster of PPTP servers to enhance the availability of PPTP servers for VPN connections. To create a load-balanced cluster of PPTP servers:
Configure each member of the cluster as a Windows 2000 PPTP server. For more information about configuring a Windows 2000 Server computer as PPTP a server, see Windows 2000 Server Help.
Configure the collection of PPTP server computers as a Network Load Balancing cluster. For more information about configuring Network Load Balancing, see Windows 2000 Advanced Server Help. When configuring Network Load Balancing on each PPTP server, enable Network Load Balancing on the interface that is receiving PPTP connection requests.
In configuring Network Load Balancing on each PPTP server, both a cluster IP address and a dedicated IP address are configured as multiple IP addresses on the interface that is receiving PPTP connection requests. To prevent problems creating PPTP connections with Windows 95, Windows NT 4.0, and Windows 98 PPTP clients, remove the dedicated IP address from the interface that is receiving PPTP connection requests using the properties of the TCP/IP protocol in Network and Dial-up Connections for each PPTP server in the cluster.
Removing the dedicated IP address will prevent individual servers from being remotely administered using the dedicated IP address. To allow remote administration of individual PPTP servers in the cluster, ensure that you have an additional LAN interface on each server in the cluster that is connected to a different network segment as the interface receiving PPTP connection requests. For Internet-connected PPTP servers, there is usually an additional interface connected to the intranet that is connected to a different network segment. After removing the dedicated IP address from the Internet interface, you can remotely administer the individual PPTP server from the intranet, but not from the Internet.
Note
Windows 95, Windows NT 4.0, and Windows 98 PPTP clients may not be able to connect to the PPTP cluster unless the dedicated IP address is removed because these clients send their PPTP connection requests to the cluster IP address. An individual PPTP server may reply to the PPTP connection request from the dedicated IP address rather than the cluster IP address. If so, the PPTP client notices the change in IP address between the request and the reply, assumes the behavior is a violation of the security of the PPTP connection, and drops the connection.