As a tunneling protocol, PPTP encapsulates network protocol datagrams within an IP envelope. After the packet is encapsulated, any router or machine that encounters it from that point on will treat it as an IP packet. The benefit of IP encapsulation is that it allows many different protocols to be routed across an IP-only medium, such as the Internet.
The first thing to understand about PPTP is that it revolves around Microsoft RAS for Windows NT. RAS allows a network administrator to set up a Windows NT server with a modem bank as a dial-in point for remote users. Authentication for the RAS users takes place on the NT server, and a network session is set up using the PPP protocol. Through the PPP connection, all of the protocols allowed by RAS can be transported: TCP/IP, NetBEUI, and IPX/SPX. To the RAS users it appears as though they’re directly connected to the corporate LAN; they notice no difference between RAS through direct dial-in and RAS over the Internet.
PPTP was designed to allow users to connect to a RAS server from any point on the Internet and still have the same authentication, encryption, and corporate LAN access they’d have from dialing directly into it. Instead of dialing into a modem connected to the RAS server, the end users dial into their ISPs and use PPTP to set up a “call” to the server over the Internet. PPTP and RAS use authentication and encryption methods to create a virtual private network.
There are two common scenarios for this type of VPN: in the first, a remote user is dialing into an ISP with a PPTP-enabled remote access switch that connects to the RAS server; in the second, the user is connecting to an ISP that doesn’t offer PPTP, and must initiate the PPTP connection on their client machine.
Dialing into an ISP that supports PPTP requires three things:
The network with which you want to establish a VPN must have a PPTP- enabled Window NT 4.0 RAS server. By “PPTP-enabled” we mean that the PPTP protocol is installed and there are VPN dial-up ports set up in RAS. The server must also be accessible from the Internet.
Your ISP must use a remote access switch that supports PPTP, such as the Ascend MAX 4000 series or a U.S. Robotics Total Control Enterprise Network Hub. (Together, these two products make up a significant portion of the ISP dial-up hardware market.)
Your ISP has to actually offer the PPTP service to users, and must enable it for your account.
To offer a typical scenario, a central corporate office in Denver has set up a Windows NT 4.0 server running PPTP and RAS. A sales manager named Sara N. is at a conference in Atlanta, and wants to dial into the corporate network to check her email and copy a presentation from her desktop machine. Her remote system is a Windows 95 laptop computer with a 28.8Kbps modem. She’s obviously out of the local dialing area of her office, but has an account through a national ISP that supports PPTP through their U.S. Robotics remote access switches. The ISP was told the IP address of the RAS server at Sara N.’s corporate office, and has added it to her user profile. The IP address is 2.1.1.60.
When the sales manager dials into her PPTP-enabled ISP, the following events occur:
Sara N. initiates a call into her ISP’s POP using Microsoft’s Dial-Up Networking. She logs in with her username, “saran.” Doing so starts a PPTP session between the ISP’s remote access switch and the corporate office’s NT server, whose IP address is specified in Sara N.’s user profile as 2.1.1.60.
Sara N.’s PPP session is tunneled through the PPTP stream, and the NT RAS server authenticates her username and password and starts her PPP session. Essentially, this all takes place just as if she were dialing into the RAS server via a directly connected modem.
The PPTP session can then tunnel the protocols that dial-up users are allowed to use. In Sara N.’s case, TCP/IP is one of those protocols, and the NT RAS server assigns her machine the internal corporate IP address of 2.1.1.129.
Looking at Figure 4-1, you can follow these events and see where the client’s original Point-to-Point Protocol (PPP) session is encapsulated by the PPTP tunnel. This figure is a simplified version of what the actual topology looks like—routers at the ISP and corporate LAN, for instance, have been removed.
Once the PPTP is completed and the sales manager is authenticated, she has access to the corporate network as if she were on the LAN. She can then check her email and access files on her desktop machine using file sharing.
In order for an ISP to support PPTP, they must be using one of the remote access switches we mentioned at the beginning of this chapter. Not every ISP uses those brands of remote access switches, and some don’t use these devices at all. Instead they might use modems connected to a multiport serial card in a Unix system, or some other terminal server device. Others might have the appropriate hardware, but choose not to implement PPTP because they don’t want to be forced to do technical support for tunneled connections. Whatever the reason, there’s a chance that your ISP may not offer PPTP; however, that doesn’t mean that you can’t use it.
This scenario requires two things: first, you again need to have a Windows NT 4.0 RAS server with PPTP installed on your network, and it must be accessible from the Internet; second, your Windows NT Workstation, Windows 95, or Windows 98 client machine must have the PPTP protocol and Dial-Up Networking installed.
We’ll use Sara N. for this example as well. This time, however, she’s dialing into an ISP that doesn’t support PPTP. In addition, she’s running Windows NT 4.0 Workstation on her laptop computer. The sequence of events for a tunneling session with a non-PPTP-enabled provider is as follows:
Sara dials into her ISP using a dial-up networking profile for her account and establishes a standard PPP connection.
After the PPP connection has been made, Sara uses Dial-Up Networking again to “dial” into the PPTP RAS server at the corporate office. In this dial-up profile, however, she puts the IP address of the RAS server, 2.1.1.60, in the phone number field, and selects the dial device to be a VPN port set up through Dial-Up Networking (we’ll explain in Chapter 5 how to set this up).
A PPTP connection is made through Sara’s PPP connection over the Internet and to the RAS server. The RAS server then logs her into the corporate network using the username and password she supplied. The RAS server assigns her the internal IP address of 2.1.1.129, and she is then granted access to the corporate network.
Figure 4-2 shows how the second PPTP call is encapsulated through the initial PPP connection to the ISP.
Again, once the PPTP connection is made, Sara N. will have access to the corporate LAN just as if she were connected to it via a network card or dial-up RAS connection.
In Figure 4-3 we have a representation of a corporate office network with a T1 connection to the Internet. The router that connects to the Internet is also a packet-filtration firewall. User Sara N. wants to check her corporate email, and is dialing into her ISP, which is using a PPTP-enabled remote access switch. After she connects to the switch, it starts a PPTP call to the RAS server specified in her user profile. In this figure, a lightly shaded line extends the PPTP session back to the client, rather than just to the remote access switch. Sara uses this line when she has to dial into an ISP that doesn’t support PPTP, and initiates the PPTP session on her workstation with a second RAS call.
On the corporate router and firewall, the TCP/IP port on which PPTP creates a socket (1723) must be open to both inbound and outbound traffic. If the rest of the network is protected by a firewall that disallows inbound and outbound Internet traffic, then a single point of entry to the LAN is established, which is protected by the user-based authentication.
The PPTP encapsulation technique is based on another Internet standard called the Generic Routing Encapsulation (GRE) protocol, which can be used to tunnel protocols over the Internet. (If you’re interested, see RFCs 1701 and 1702.) The PPTP version, known as GREv2, adds extensions for specific features such as Call ID and connection speed.
A PPTP packet is made up of a delivery header, an IP header, a GREv2 header, and the payload packet. The delivery header is the framing protocol for whatever medium the packet is traveling over, whether it’s Ethernet, frame relay, or PPP. The IP header contains information essential to the IP datagram, such as the packet length and the source and destination addresses. The GREv2 header contains information on the type of packet encapsulated, as well as PPTP-specific data that pertains to the connection between the client and server. Finally, the payload packet is the encapsulated datagram itself. In the case of PPP, this datagram is the original PPP session data that is sent between the client and server, and within it can be IP, IPX, or NetBEUI packets. Figure 4-4 illustrates the layers of PPTP encapsulation.
The encapsulation process for a user dialing into an ISP that supports PPTP is as follows:
The user dials into the ISP’s remote access switch using PPP. Between the client and the remote access switch flow PPP packets that are surrounded by the PPP protocol-specific frames being delivered.
At the switch, the media-specific frames are stripped away, and the call triggers the remote access switch to open up a PPTP tunneling session over the Internet between itself and the PPTP-enabled NT RAS server specified in the user’s profile. The remote access switch encapsulates the PPP payload packet within a GREv2 header, then an IP header. Finally, the packet gets a delivery header before going out of the switch. Throughout the packet’s journey, the delivery header may change depending on the type of media through which the packet is being sent. For instance, it may go from Ethernet, to frame relay, to Ethernet again, to PPP over ISDN, and to Ethernet yet again before finally reaching its destination at the RAS server.
The RAS server treats the incoming PPTP connection as an incoming call, just as if it were coming in over a modem. It strips off the delivery header, the IP header, and the GREv2 header from the payload packet. It then handles the PPP connection as it normally would if the user were coming in over a modem connection. The RAS server validates the PPP client using whatever authentication method is required on the RAS server: Microsoft encrypted authentication, encrypted authentication, or any authentication type (including clear text).
Before packets from the client reach the LAN, PPP framing is removed from the enclosed IP, NetBEUI, or IPX datagrams. Figure 4-5 is a diagram of those protocol layers that are active during each portion of the connection for dialing into ISPs that support PPTP.
In a situation where the RAS user is dialing into an ISP that doesn’t support PPTP, much of the process is the same. The only change would be in step 2. Instead of the remote access switch starting the PPTP session with the RAS server, the client makes a PPTP connection to the RAS server using Dial-Up Networking (as we said earlier). The PPTP packets are therefore sent through the standard PPP connection the client is making with the ISP’s remote access switch. At that point in the connection, the client’s PPP datagram is encapsulated by PPTP which is, in turn, encapsulated again by PPP. At the remote access switch, the first layer of PPP is stripped off, and the delivery header, IP header, GREv2 header, and payload packet remain.
Although this outlines how a PPTP call is initially placed, communication between the client and server proceed in the same order of encapsulation. The main difference is that authentication no longer needs to take place.
Like most security systems, PPTP has two components: authentication to prevent improper connections, and encryption for data sent once the connection is made.
PPTP uses Windows NT RAS authentication. The choices for the different authentication types the RAS server can accept are located in the RAS properties under “Encryption Settings.” This setting lets you specify the level of authentication that the RAS server will perform against the client’s login attempt. This section discusses the options you have: standard encrypted authentication, Microsoft- enhanced encrypted authentication, and allowing any type of authentication. Your choice will determine how secure your VPN will be.
Encrypted authentication in RAS is actually the Internet authentication standard known as CHAP (Challenge Handshake Authentication Protocol). CHAP is described in RFC 1994 as an extension to PPP in which clear-text passwords are not passed between the client and server. Instead, both the client and server have an agreed-upon password, called a “secret,” that is never sent over the link unencrypted. Here’s how CHAP authentication occurs:
The server “challenges” the client to identify itself when the client tries to connect.
The client sends the secret through a one-way hashing algorithm, RSA’s MD5. The algorithm uses mathematical formulas and random factors to come up with a hash value. “One-way” means that the hash value cannot be reversed into the original elements, and the use of random elements means that someone sniffing the connection will be less likely to see the same value twice. The hash value is sent across the connection to the server.
The server compares the value the server sent to its own calculation of the hash value. If the two values match, the connection is authenticated. If not, the connection is terminated.
Another benefit of CHAP is that this authentication process can take place several times during the course of a connection. This limits the probability of being bumped off and having an impostor “hijack” your connection.
In the case of PPTP, the secret is the password the user uses to log into the NT domain, which is also known by the RAS server (either directly or through NT domain services).
Microsoft encrypted authentication is also known as MS-CHAP. MS-CHAP performs RSA’s MD4 hash, as well as the DES hashing technique. Windows 95/98 and Windows NT RAS clients use the MD4 hash, which doesn’t require clear-text passwords on the client or server. DES allows for backward compatibility with older RAS clients such as Windows for Workgroups 3.11 and RAS 1.1a. Otherwise, MS-CHAP operates the same way as CHAP. The main drawback of MS-CHAP is that not every platform has a PPP client that supports it. If your remote users are all on Windows systems, however, it’s the best protocol to use. In addition, you must use it to get the added benefit of data stream encryption over PPTP. We’ll explain why in the section on data encryption.
Accepting any authentication, including clear text, means that the RAS server will accept MS-CHAP, CHAP, or the Password Authentication Protocol (PAP). PAP has long been a common way to authenticate a PPP connection. In fact, most ISPs use PAP authentication for their PPP dial-up connections. Its main drawback is that it sends the password over the connection in clear text, meaning that someone monitoring the connection between the client and server may be able to see the login exchange, then log in later as that person. PAP is an unsuitable authentication method for a VPN, since secure authentication over a public network is a VPN’s primary goal. It’s therefore suggested that you require CHAP or MS-CHAP authentication on your PPTP server. If your remote users are on varied platforms, you may find that not every client on every platform supports CHAP or MS-CHAP authentication. If you can’t find a CHAP implementation at all for a particular operating system, you may be forced to accept clear text passwords.
In the RAS properties for Windows NT, you’ll find a checkbox to require data encryption for the RAS connection. This option will make all data going across the connection stream unreadable to an interceptor. The box can be checked only if the option to require Microsoft encrypted authentication is also selected, meaning that you can use it only if you’re also using MS-CHAP. The reason for this is that the value generated by the MD4 hash is used by the RAS client and server to derive a session key for encryption. The encryption algorithm used is RSA’s RC4, with a 40-bit session key.
As we said in Chapter 2, U.S. export laws prevent the distribution of ciphers that can use session keys of greater than 40 bits. On the other hand, keys of 40 bits are often considered too vulnerable for transmitting secure data over the Internet. In order to meet the demand for better encryption methods, Microsoft has included a 128-bit “strong” encryption module in a U.S.-only version of their Service Pack 3 for Windows NT 4.0.
Get Virtual Private Networks, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
