Some of the main topics in this chapter are
The Point-to-Point Tunneling Protocol (PPTP) specification was developed by the PPTP forum, a collaboration between Microsoft Corporation and a group of several leading manufacturers of ISP equipment, including Ascend Communications, 3Com/Primary Access, ECI-Telematics, and US Robotics. PPTP can be regarded as an extension of Point-to-Point Protocol (PPP). PPTP adds a new level of enhanced security and multiprotocol communications over the Internet.
Specifically, PPTP enables implementation of secure, multiprotocol Virtual Private Networks (VPNs) through public data networks such as the Internet. Through PPTP, it's possible for remote users to access their corporate networks and applications by dialing into the local ISP's Point of Presence (POP), instead of dialing directly into the company network. PPTP connects directly to the target server by creating a virtual network for each remote client, one that the NT Server 4.0 administrator can monitor and manage like any other Remote Access port.
For further information and development assistance with PPTP, refer to Microsoft's specification document, Point-to-Point Tunneling Protocol (PPTP) Technical Specification, dated February 22, 1996. Sample code of PPTP is available on the Windows NT 4.0 Driver Development Kit (DDK). Because the code is available, developers can produce PPTP drivers for platforms other than NT 4.0 or Win95.
PPTP supports the development of secure, multiprotocol Virtual Private Networks (VPNs) over the Internet. One way to think of a VPN is as a virtual wide area network (WAN). A virtual WAN is not physical but forms on demand through a software call that sets up a point-to-point session between a PPTP client or Front End Processor (FEP) and an NT 4.0 RAS PPTP-enabled Server.
In this sense, PPTP connections are like private, controlled phone calls (rather than party lines) into the target servers, in that either party can set up, manage, and disconnect them at will. Dialing a neighbor's phone number makes use of the massive switching fabric of the phone company, a much cheaper alternative to stringing your own lines and investing in your own switch. "Dialing" the IP address of the PPTP-enabled server makes use of the Internet's physical base of routers, ATM switches, and digital and analog lines, without sacrificing security. Just as PPP standardized dial-in protocol for Internet access from client to Internet Point of Presence (POP) equipment, PPTP extends the standard to create a tunneled connection from the client (or the FEP) all the way to any PPTP-enabled server located on the Internet.
Obviously, security is a great concern on the Internet today, and PPTP addresses this concern by encapsulating NT's own security algorithms and methods. By incorporating security measures built into NT and PPP and forcing RAS Servers on the Internet to only accept PPTP clients who utilize data encryption, network administrators will be able to actually tighten security and manage remote users much more efficiently. Refer to the section "Security and PPTP" for further information on this topic.
To the average network administrator who's currently obliged to build and maintain local Remote Access Servers, modem banks, dedicated analog phone lines, and perhaps even toll-free numbers for the company's traveling users and telecommuters, VPNs offer a release from many of these obligations. With PPTP, FEP equipment such as modem banks remain centralized at the ISP's nationwide locations, without sacrificing the company's security or capability to control remote connections. Local NT 4.0 servers perform NT domain security authentication before the user gains access to the company network. If required, each remote connection is administered, logged, or monitored on an individual basis. With very slight adjustments by both client and administrator, the functionality is the same as with a direct call into the company network. The only difference is that the network session takes place over the Internet, rather than over the company's private dial-up network.
In this scenario, classic private dial-up networks, the most common model for remote access at present, are only necessary when dedicated bandwidth must be available or when the local ISP does not support PPTP. Eliminating the costly setup and maintenance of a private company-owned dial-up network, particularly in situations in which nationwide links are necessary, creates substantial savings for the typical IS department.
As the section on tunneling in this chapter explains, technically PPP packets travel end-to-end, through the PPTP channel. But from the point of the user, the tunneling is practically transparent. Two scenarios are possible with NT 4.0 PPTP at this time, one a PPP client with a PPTP-enabled FEP, the second a PPP/PPTP client with an FEP that accepts the client's PPP connection. The main difference lies in where PPTP is enabled on the client side--in the workstation or in the FEP at the ISP's Point-of-Presence (POP).
As shown in Figure 16.1, a PPP client sets up a session to an ISP's PPTP-enabled FEP, typically an Internet router or bridge to which the remote user has dial-up access via an analog modem or ISDN. When the client requests connection to the RAS Server, the FEP establishes the VPN by starting a PPTP session and tunneling all information from the PPP client through the PPTP channel. The NT Server handles all validation and manages data encryption. Note that the PPTP session is transparent to the user, and the client requires only PPP to operate. Because multiple platforms such as UNIX, Mac, and OS/2 support PPP dial-up, the RAS Server can accept secure PPTP connections from a wide range of operating systems with this configuration.
Future upgrades promise to add the capability to use PPTP for LAN to LAN connectivity through the Internet, incorporate Cisco L2F enhancements, and an optional module to utilize 128-bit keys instead of 40-bit keys for encryption.
A PPP client sets up a session to a front end processor.
Figure 16.2 shows a client that has PPTP protocol installed. This client dials up the ISP and establishes a PPP Session. The same client then dials a second time, concurrent to the PPP session, setting up the PPTP channel and contacting the remote NT Server 4.0 RAS Server. The client is now a virtual node on the corporate LAN, one that just happens to be located across the Internet. Note that in this case the FEP does not have to be PPTP proficient. Only PPTP-enabled clients, such as NT Workstation 4.0 or NT Server 4.0, however, can utilize this configuration (Windows 95 is now available from Microsoft's Web site: http://www.microsoft.com/ntserver/info/pptpdownload.htm). As in the first example, NT handles all validation and can require that the data be encrypted in both directions.
PPP packets are tunneled through the virtual network.
Because PPTP is evolving, and ISP equipment manufacturers are still testing their implementations of the protocol, it's reasonable to assume that early use of PPTP will match the second scenario. Accordingly, sections of this chapter describing installation concentrate upon the second scenario, the PPP/PPTP-enabled client configuration. After your ISP enables PPTP, clients will only require PPP to make the PPTP connection.
PPTP has several benefits, as outlined in the following list:
Existing ISP equipment requires only software upgrades as manufacturers update their hardware to meet PPTP specifications. In the meantime, if the client is PPTP-enabled, existing ISP equipment can still support the PPTP session.
Once the local ISP offers PPTP connectivity, PPP clients need no additional software to make use of PPTP. Dial-in procedures will not change substantially, so users don't need to learn new software to take advantage of tunneling through the Internet.
For all these benefits, PPTP is well worth implementing if administrators are looking for a low-cost alternative to building a Private Network for WAN and remote dial-in applications. It should be noted, however, that there will be a slight drop in performance compared to dialing directly into the RAS Server, currently the best alternative. But the overhead involved in slipping an IPX, NetBEUI, or TCP/IP native protocol inside a TCP/IP "envelope" has proven to be minimal. It's likely that delays caused by peaks in the volume of traffic on the Internet will be more noticeable for the typical user than the delays associated with tunneling a protocol through PPTP.
In Microsoft's PPTP specification, there are two basic types of packets in the PPTP protocol: data and control packets. The first resides in a data portion of the packet, which can vary in length. The second is found in the fixed-length packet header. Data packets contain the normal user data and application commands. Control packets send periodic inquiries on status and manage signals between the PPTP-enabled client or FEP and the destination server, along with embedded management information that contains basic device management and configuration information. Data packets are encapsulated inside an IP envelope, in a method known as tunneling, as described in the next section. Control packets, on the other hand, communicate through a TCP connection, one per pairing of an NT Server 4.0 and a PPTP client or FEP.
Tunneling is a technique in which a datagram is contained within the envelope of another higher level protocol, in this case IP, during transfer across the Internet. PPTP utilizes only IP, IPX, or NetBEUI datagrams, buried inside an IP packet. Figure 16.3 shows a typical PPTP packet, encapsulated by using the Internet Generic Routing Encapsulation protocol, version 2 (GRE v2).
Typically, PPTP creates a tunnel from the client's PPP session, which begins with a connection into the client-side FEP (usually the ISP's dial-in router) and connects through the Internet to the PPTP-enabled destination NT Server 4.0. Note that in this configuration (the first scenario described earlier), PPTP operates only between the client-side FEP and the NT 4.0 Server. With the PPTP-enabled client represented in the second scenario, the tunneling is identical, except tunneling begins at the client and passes through the FEP to the RAS Server. From then on, corporate network validations and all protocol-specific applications operate as if the user had dialed directly into a RAS server, utilizing PPP. Figure 16.4 shows how the PPP datagram is incorporated into the PPTP session.
This diagram shows you a typical PPTP packet.
The target application server is only reached after the RAS server has validated the PPP client, utilizing NT domain security.
The typical sequence of events during a PPTP session, as shown in Figure 16.5, is identical for both the first and second scenarios, with one exception: All PPTP-specific commands, such as Start Session, are initiated at the client instead of the FEP in the second scenario. In either case, PPTP is actually the second of two steps in a client's PPTP session. The first step is obtaining a PPP connection to the Internet via an ISP.
For the second step in Figure 16.5, connecting to the VPN while the PPP session is still active, the remote user "dials" again by using another entry. The method of dialing differs in the two scenarios. Should the FEP have PPTP installed, a simple connection, made just as if the user were asking for a normal server connection on the LAN, alerts the FEP to start the PPTP session. Should the user be using PPTP on the client, the user dials again through the dial-up networking box. But this time, the remote user specifies an IP address instead of a phone number and a VPN port instead of a dial-out device such as a modem. A section later in this chapter, "Installing PPTP on NT Server 4.0," covers client installation instructions in greater detail.
This diagram shows the sequence of events for a PPTP session.
The second step alerts the FEP or the PPTP-enabled client to begin the third step, where a Start Session request is sent to the target NT 4.0 Server. After the FEP or PPTP-enabled client receives a reply, the PPTP channel is initiated, and the client can begin tunneling even encrypted data directly to the NT 4.0 Server. NT validation or rejection of the client occurs through this tunneled session.
Figure 16.5 shows a typical sequence of events, starting at the top, between the PPP client, FEP, and NT Server. In this case, because the FEP has PPTP installed, it establishes and manages the PPTP session. If the PPP client had added PPTP to its installed protocols, all PPTP communications listed would originate and terminate at the PPTP-enabled client. Because all communications would be tunneled inside IP packets, the FEP would act only as an entry point to the Internet via a PPP link.
PPTP, as the figure shows, provides all the tools to manage a point-to-point connection, including queries on the status of both PPTP peers, in-band management calls, allocation of channels during outbound calls, requests and notifications of inbound calls, complete flow control, and notification to the NT Server that a VPN port is disconnected, even if a session is abruptly interrupted.
PPTP is added to NT Server 4.0 like any standard network protocol, with one difference: It ties directly into NT Remote Access Services and requires configuration of RAS during the installation. Prior to installing PPTP, it's a good idea to add RAS. Because administering PPTP connections is identical to administering a typical RAS connection, if you have not reviewed Chapter 15, "Using Remote Access Service (RAS)," it would be a good idea to do so now.
Here's the procedure for adding PPTP to an installed copy of Windows NT 4.0 Server:
You install PPTP via the Protocols tab in the Network dialog box.
3. Figure 16.7 shows the PPTP Configuration dialog box. Click the scroll box, and for this example, select 4 to create a maximum number of four remote PPTP concurrent client connections to this RAS server. Click OK.
The PPTP Configuration dialog box shows the number of VPNs.
5. Click OK. This initiates configuration of RAS, to which you'll be adding the new PPTP VPN ports. NT 4.0 automatically loads the RAS configuration dialog box for you, which in this case lists a modem that's already set up in RAS.
6. To add the new VPN ports to RAS, click the Add button on the lower left. You see the Add RAS Device dialog box. Double-clicking the first port returns you to the device listings in Figure 16.8. Repeat the Add, double-clicking the next VPN port, until all the VPN ports are listed in the Remote Access Setup dialog box. In this example, four VPNs were chosen earlier in the installation, so four RAS PPTP ports can be added to RAS.
Each port must be added individually.
8. In addition, you can define which tunneled protocols you'll allow through the VPNs. Highlight each port, and click the Network button on the right side of the dialog box.
Note that you can enable or disable IP, IPX, or NetBEUI sessions for each port. If enabled, you can control whether IP, IPX, or NetBEUI clients will have access to either the Entire network, or This computer only. If you've administered a RAS server previously, you'll recognize that these options are identical to those for a physical dial-in port, such as a direct modem connection.
9. Finally, click Close. The protocols are bound to the new RAS VPNs you just created. The server informs you it needs to be restarted for the changes to take effect. Click Yes to restart.
10. Review the section on RAS administration for further details on how to allow domain users access and sign-on via the VPN ports. Confirm that you have a legitimate user logon ID and password to test the new VPN connectivity. Finally, add or delete users, preferably (for security reasons) from your domain accounts, and ensure that Dial-In is selected as an option for each account.
You're now prepared to test your new PPTP installation. To do this, you need to set up a client and establish a PPP connection with a local ISP. After you're successfully connecting to the Internet, take the next step and attempt to make the PPTP connection. Various ISPs have slightly different variations on how to make the initial PPP connection; refer to their documentation and support options for further information. Also, various PPP clients have different methods for installation of PPP. Again, refer to the documentation specific to your client.
These instructions apply when your ISP has not added PPTP capability to the dial-in equipment. The following procedure for NT Workstation 4.0 or NT Server 4.0 also installs the PPTP protocol, but this time you create one VPN port for dial-out. You need either an ISDN device or an analog modem, and an ISP that supports PPP connections.
2. You need to install PPTP. In the previous section, steps 1 through 10 outline that process. At Step 3, where you enter the number of VPNs, enter 1. When you reach Step 7, configure the VPN port for Dial Out Only. Otherwise, the configuration is identical.
3. After RAS is properly installed, open the Dial-Up Networking folder. You see the Dial-Up Networking dialog box shown in Figure 16.9.
If this is the first time you've run the program, you're asked to add the first entry to the phone book.
5. Right-click More and choose Edit Modem Entry. Check that PPP TCP/IP options are set up according to the instructions provided by your ISP. For instance, be sure to enter the proper DNS Server IP numbers provided by your ISP.
6. After confirming all edits, return to the Dial-Up Networking dialog box, and click New to add another entry. For the sake of this example, name the entry Corporate Server Connection. This time you're designating the IP address of the target NT 4.0 Server in the Phone Number text box, as well as directing the dial-out device to the VPN port, typically named RASPPTPM#, where # is the number of the port. Your dial-up account entry should resemble the one in Figure 16.10. When you finish adding the new entry, return to the initial Dial-Up Networking dialog box.
7. Click Dial to dial your ISP number and establish the PPP connection. Type any necessary logon IDs and passwords (again, refer to your ISP's setup instructions) to complete the PPP connection. You can check on Internet connectivity by running Web browsers, FTP, or pinging the ISP's DNS servers. If these are successful in accessing Internet hosts, you're ready for the next step.
8. Without closing the currently active PPP connection, highlight your Corporate Server Connection entry, and click Dial to initiate the PPTP connection.
9. If you obtain a second logon box provided by the distant NT 4.0 Server, you've succeeded in traveling the second leg and can operate through the PPTP connection. Log on as you would on the normal network, with a valid user ID and password.
Your entry should look similar to this completed Dial-Up entry.
To streamline the two-step dialing process mentioned previously, you can create a single autodial account that initiates the PPP connection first and then automatically dials the IP address of the target PPTP RAS Server. Typically, this is done by creating a script for the first PPP connection and running it prior to the second PPTP request to dial into a RAS Server. These steps outline one method:
2. Choose the Phonebook entry for your target server, the one that has the IP address entered instead of the phone number. Choose More, Edit entry.
3. Select the Scripts tab. Choose the Before Dialing button.
4. If you haven't already added the script for your ISP PPP connection,
you can click Edit Scripts to view and edit the switch.inf file by using Notepad.
Here you can read about the syntax of switch.inf scripts and view some examples of
such scripts. This is also where you add the necessary script entries for your own
ISP PPP connection (check with your ISP, who will often be able to provide this script
to you). You title the section between brackets (that is, [PPP Connection to ISP])
at the beginning of the new section.
When you're finished, save the file, return to the dialog box, and click the Refresh
button to reload the revised switch.inf file. Now, as Figure 16.11 shows, you can
click Run this script and select your new entry from the list.
5. Click OK, confirm all choices, and return to the main Dial-Up Networking dialog box. At this point, you can test your new autodial configuration.
In addition, if the remote user is a telecommuter who uses the computer strictly to gain access to the corporate network through the Internet, you can specify to dial up the remote network automatically upon logon. Whenever Logon using Dial-Up Networking is selected during the initial logon by the user, it directs the system to automatically initiate Dial-Up Networking. The user can choose the autodial account created earlier and complete a connection to the target LAN. Logging off disconnects the PPTP and PPP sessions. This further simplifies use of remote dial-in applications.
You only need to use a script if your ISP requires it.
As discussed earlier in this chapter, tunneling enables administrators to implement the same domain security found on NT LANs. This includes authentication and encryption technologies.
For authentication, NT RAS performs all validation of remote users dialing in through VPNs. Accounts are checked against the Windows NT user database; entry is not granted unless usernames and respective passwords match. In this manner, even though remote users might be accessing a private corporate network through the very public Internet, the administrator is assured that only users he or she specifies will be allowed on the corporate LAN. Security is centralized, limited to users who have domain accounts or who have accounts that have been granted specific access to the network through a trusted domain. Good management of user accounts severely limits the possibilities for attacks by hackers through the RAS server.
Keys for encryption of data are extracted from user credentials and, consequently, are not transferred through the Internet, where they might be intercepted. After NT verifies the user, the authentication key, in an MD4 hashed form, is applied to all encrypted data. Currently, 40-bit RC-4 encryption is the standard for NT. Microsoft is scheduled to release a 128-bit encryption option, which raises the stakes for cracking the code so high that the U.S. government has forbidden export of this technology.
It's also worth noting that this form of encryption takes place at the kernel level of Remote Access Services, and is, thus, relatively efficient compared to previous encryption and decryption routines suitable for Internet use, such as Secure Sockets Layer (SSL).
With PPTP, the network administrator can reduce the risks of unwanted intrusions even further by implementing two options in the server and client configurations:
In both cases, the requirements can be forced upon remote users, simply by setting the options at the centrally located RAS Server. Remote Users are informed if they aren't properly set up for validation.
The first recommendation, allowing only PPTP sessions, can be applied through Control Panel, Network, Protocols tab. Highlight TCP/IP, click the Properties button, and choose Advanced in the resulting dialog box. At this point, you can select Enable PPTP Filtering. Confirm your choice, and close all dialog boxes. You need to restart to implement the new setting.
Another method used to tighten security is to set up the server to accept only encrypted information from clients. Connection is refused if the client attempts access without encrypted authentication or data. To enable this option, click My Computer on the desktop, open Control Panel, click Network and then the Services tab, and after highlighting Remote Access Services, click the Properties button. At this point, you can click a port and click the Network button. The resulting dialog box in Figure 16.12 has an Encryption Settings area where you can select Require Microsoft encrypted authentication and Require data encryption.
This dialog box shows the Encryption Settings area of the Network Configuration dialog box.
On the client side, turning on data encryption is done in the Dial-Up Networking application by editing the account utilized for dialing into the server. Choose Start, Programs, Accessories, Dial-Up Networking. Choose the dial-in account for the target server. Then click More, Edit entry and modem properties from the drop-down menu. Select the Security tab (see Figure 16.13), from which you can select Accept only Microsoft Encrypted Authentication, as well as Require Data Encryption, to encrypt all data.
The Security tab of the Edit Phonebook Entry dialog box enables you to configure encryption settings for the client.
For the network administrator of the PPTP-enabled RAS Server, monitoring PPTP VPN sessions is identical to monitoring an RAS connection. You can view information on which VPN ports are active, statistics on how long the connection has been up, what rate is sustained, and basic data transfer information, all within the RAS Administration program. To start the RAS Administration program, click Start, Programs, Administrative Tools, RAS Administration.
© Copyright, Macmillan Computer Publishing. All rights reserved.