Introduction to PPTP

PPTP Components

Installing PPTP on NT Server 4.0

Setting up a Typical NT 4.0 Client

Security and PPTP

Monitoring PPTP

Definitions

Point-to-Point Tunneling Protocol (PPTP)

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 Internet Service Provider (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 multi-protocol communications over the Internet.

Specifically, PPTP enables implementation of secure, multi-protocol Virtual Private Networks (VPNs) through public data networks such as the Internet. Through PPTP, it is 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.

PPTP solves many problems for the network administrator who needs to accommodate remote users, and wishes to avoid building and maintaining a relatively costly Wide Area Network through private lines. Since PPTP "tunnels", or encapsulates IP, IPX, or NetBEUI protocols inside IP packets, users can run applications that are dependent upon certain network protocols. The "tunnel" also allows the NT 4.0 target server to perform all of the security checks and validations, and enables administrators and clients to encrypt data, making it much safer to send information over non-secure networks. If the ISP equipment supports PPTP, no additional software or hardware is required on the client end; only a standard PPP connection is necessary. If the ISP does not support PPTP, a Microsoft NT 4.0 (either Server or Workstation) client can still utilize PPTP and create the secure connection, first by dialing the ISP and establishing a PPP connection, then by dialing once again through a virtual PPTP port set up on the client side.

Microsoft and US Robotics demonstrated PPTP at Networld in March 1996. PPTP was first released in NT 4.0 Beta 2 in April 1996, and will be released for Win95 by early 1997. In late June 1996, Microsoft and Cisco, one of the top router manufacturers, submitted an application to the Internet Engineering Task Force PPP Extensions working group to propose a combination of Microsoft’s PPTP implementation to date with Cisco’s Layer 2 Forwarding (L2F). L2F is a VPN protocol that Cisco was developing at the time Microsoft PPTP was announced. This collaborative application is particularly good news, as it means that there will be just one industry-wide IETF specification for a Virtual Private Networking protocol, and that it will consist of the best elements of L2F and Microsoft PPTP. For users, it means PPTP in NT 4.0 can be used "as is" with a PPTP-enabled client and server. Projected adoption of the PPTP protocol by IETF will allow ISPs to confidently expand their services and offer one standard tunneling protocol to customers.

As of early July 1996, vendors were still working together to test interoperability between PPP clients, PPTP-enabled NT Server 4.0, and multiple manufacturers’ ISP equipment retrofitted with Microsoft’s first specification for PPTP. 3Com, Ascend, ECL Telematics, and U.S. Robotics have all committed to implementing PPTP technology via software upgrades to their remote access servers. Internet Service Providers such as UUNET have also committed to testing the new protocol on their existing infrastructure. It would be a good idea to check with local Internet Service Providers and obtain the latest status on their PPTP testing.

For further information and development assistance with PPTP, refer to Microsoft’s specification document, titled "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). Since the code is available, developers can produce PPTP drivers for platforms other than NT 4.0 or Win95.

The Virtual Private Network (VPN)

PPTP supports the development of secure, multi-protocol Virtual Private Networks (VPNs) over the Internet. One way to think of VPNs 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 they can be set up, managed, and disconnected at will by either party. Dialing a neighbor’s phone number makes use of the massive switching fabric of the phone company, a much cheaper alternative to stringing up 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 in this chapter titled "Security and PPTP" for further information on this topic.

To the average network administrator, who is 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 Internet Service Provider’s nation-wide locations, without sacrificing the company’s security or ability 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, would only be 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 where nation-wide links are necessary, will create a substantial savings for the typical IS department.

Standard PPTP Sessions

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. There two scenarios possible with NT 4.0 PPTP at this time, one a PPP client with a PPTP-enabled FEP, and 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 Front End Processor at the ISP Point-of-Presence (POP).

1. As shown in Figure 1, a PPP client sets up a session to an ISP’s PPTP-enabled Front End Processor (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 Virtual Private Network 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 that the client requires only PPP to operate. Since 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.

   
   Figure 1

2. Figure 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. PPP packets are then tunneled through the new virtual connection, and 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. However, only PPTP-enabled clients, such as NT Workstation 4.0 or NT Server 4.0, can utilize this configuration (Windows 95 is scheduled to add PPTP by early next year). As in the first example, NT handles all validation and can require that the data be encrypted in both directions.

   
   Figure 2

Since PPTP is evolving, and ISP equipment manufacturers are still testing their implementations of the protocol, it is reasonable to assume that early use of PPTP will match the second scenario. Accordingly, those sections of this chapter describing installation concentrate upon the second scenario, the PPP/PPTP-enabled client configuration. Once your ISP enables PPTP, clients will only require PPP to make the PPTP connection.

Briefly summarized, the benefits of PPTP are as follows:

The PPTP protocol can be installed on an NT Workstation 4.0 or NT Server 4.0 platform today, and is scheduled to be available for Windows 95 by early next year. 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.

For all of 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 is likely that delays caused by a 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.

Type of Packets

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 which 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.

Definition of Tunneling

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 an internet. Point-to-Point Tunneling Protocol utilizes only IP, IPX, or NetBeui datagrams, buried inside an IP packet. Figure 3 shows a typical PPTP packet, encapsulated using the Internet Generic Routing Encapsulation protocol, version 2 (GRE v2).

GRE Version 2 is a proposed enhancement to the standard outlined in RFCs 1701 and 1702, adding specific octets for PPTP-specific functions such as protocol and Call IDs. From the administrator’s point of view, it is interesting to note that the proposed protocol does allow acknowledgments to be carried along with the data, which saves both time and buffer space. Also, the Payload Packet (the datagram) is essentially the original PPP packet sent by the client, missing only framing elements that are specific to the media. That information is provided by the Media Header.

Where Tunneling Occurs

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 4 shows how the PPP datagram is incorporated into the PPTP session. The target application server is only reached once the RAS server has validated the PPP client utilizing NT domain security.

A Typical Sequence of Events During a PPTP Session

The sequence described here, and diagrammed in Figure 5, is identical for both the first and second scenarios, with one exception: all PPTP specific commands, such as Start Session, would be 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 Internet Service Provider.

For the second step in Figure 5, connecting to the VPN while the PPP session is still active, the remote user "dials" again 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, would alert the FEP to start the PPTP session. Should the user be using PPTP on the client, the user would dial again through the dial-up networking box. But this time the remote user specifies an IP address instead of a phone number, and a Virtual Private Network port instead of a dial-out device such as a modem. Later in this chapter, the installation instructions for the client cover this in more detail.

The second step alerts the FEP or the PPTP-enabled client to begin step three, where a Start Session request is sent to the target NT 4.0 Server. Once the FEP or the 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 will occur through this tunneled session.

Figure 5 shows a typical sequence of events, starting at the top, between the PPP client, the FEP, and the NT Server. In this case, since 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. Since 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 diagram 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 notifying 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 is a good idea to add RAS. Since administering PPTP connections is identical to administering a typical RAS connection, if you have not reviewed the chapter on Remote Access Services yet, it would be a good idea to do so now.

Here are step-by-step procedures for adding PPTP to an installed copy of Windows NT 4.0 Server:

1. Double click on the My Computer icon on the desktop.
2. Double click on the Control Panel icon in the My Computer window
3. Double click on the Network icon inside the Control Panel
4. In the Network Dialog box, click on the Protocols tab. You will see the dialog box in Figure 6.

   
   Figure 6

5. Click on the Add button on the lower left of the Protocols dialog box.
6. Click on the scroll button in the Select Network Protocols dialog box, and choose to add Point-to-Point Tunneling Protocol from the list, as shown in Figure 7.

   
   Figure 7

7. You will be presented with a key question: how many Virtual Private Networks do you want to enable for access to this server, and through this server, to the rest of the network? Figure 8 shows the Virtual Private Network dialog box. Click on the scroll box, and for this example, pick "4" to create a maximum number of four remote PPTP concurrent client connections to this RAS server. Click on OK when finished.

   
   Figure 8

8. To complete the addition of PPTP, click on OK. The dialog box will close and if you do not have your NT 4.0 CD available, it will ask you to insert the CD ROM disk. Once you specify the proper path to the NT installation files, such as e:/I386, the installation will load all necessary PPTP files. Clicking on Close will bring up the dialog box shown in Figure 9. Click on OK to continue.

   
   Figure 9

   Note: You have now completed the first part of the installation, adding PPTP as a remote protocol. The remaining steps of the installation configure Remote Access Services for PPTP.

9. Click on OK. This will initiate configuration of the Remote Access Services, to which you will be adding the new PPTP Virtual Private Network ports. NT 4.0 will automatically load the RAS configuration dialog box for you, shown in Figure 10, which in this case lists a modem that is already set up in RAS:

   
   Figure 10

10. To add the new VPN ports to RAS, click on the Add button on the lower left. You will see the dialog box in Figure 11. Each port must be added individually. Double-clicking on the first port returns you to the device listings in Figure 10. Repeat the Add, double-clicking on the next VPN port, until all the VPN ports are listed in the Remote Access Setup dialog box. Note that since four Virtual Private Networks were chosen earlier in the installation, in this example four RAS PPTP ports can be added to Remote Access Services.

    
    Figure 11

11. At this point, by default the ports are configured for dial-in only. You can change this by clicking on the Configure button in the Remote Access Setup dialog box. Choose Dial Out for one of the ports if you plan to dial out to PPTP-enabled servers in the future. For more information on setting up a client, see the next section titled "Setting Up an NT 4.0 Client".
12. In addition, you can also define which tunneled protocols you will allow through the Virtual Private Networks. Highlight each port, then click on the Network button on the right hand 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 have administered a RAS server previously, you will recognize that these options are identical to those for a physical dial-in port, such as a direct modem connection.
13. Once you have completed the options in step 12, click on OK, then Continue. Finally, click on Close. The protocols will be bound to the new RAS VPNs you just created. The Server will inform you it needs to be restarted in order for the changes to take effect. Click on Yes to restart.
14. 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 login and password to test the new VPN connectivity. Finally, add or delete users you wish to include, preferably (for security reasons) from your domain accounts, and ensure that Dial-In is checked off as an option for each account.

You are 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 Internet Service Provider. Once you are successfully connecting to the Internet, you can take the next step and attempt to make the PPTP connection. Various ISPs will 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.

The section below provides an overview of how an NT Workstation 4.0 client might be set up, and the sequence of steps a client would take to make the PPTP connection.

These instructions apply when your ISP has not added PPTP capability to the dial-in equipment. The following procedures for NT Workstation 4.0 or NT Server 4.0 also install the PPTP protocol, but this time you create one VPN port for dial-out. In addition, you will need either an ISDN device or an analog modem, and an ISP that supports PPP connections.

1. First make sure that Remote Access Services have been installed. Click on My Computer, then Control Panel, then the Network icon. When you click on the Services tab you should see Remote Access Services listed. By clicking on Properties you can confirm that the modem is recognized by RAS. If Remote Access Services have not been installed, click the Add button and perform the installation of that service. During the installation, make sure that your modem is enabled for Dial Out. Also, under the Networks button, confirm that IP is enabled. Refer to the chapter on Remote Access Services for further details on installation of RAS and your dial-out device.
2. Next you need to install PPTP. In the previous section, steps 1 through 13 outline that process. At step 7, where you enter the number of VPNs, you can enter 1. When you reach step 11, configure the VPN port for Dial-out Only. Otherwise, the configuration is identical.
3. Once RAS is properly installed, click on Start, Programs, Accessories, then Dial-Up Networking. You will see the dialog box in Figure 12.

   
   Figure 12

4. If this is the first time you have run that program, you will be asked to add the first entry to the phone book. If you have not already set up an account for your ISP, click on New. Type in the name of your ISP, choose Next, then choose ‘I am calling the Internet’ for the type of connection, as shown in Figure 13. This configures the entry automatically to utilize PPP. After clicking on Next again, you are asked to provide the dial-in number for your ISP, at which point you click on Finish to complete the account setup. If you have more than one modem connected to your system, confirm that the default Dial-Out Device chosen is the modem you wish to use.

   
   Figure 13

5. Click your right mouse button on More and click on the Edit Modem Entry on the drop-down menu. Check that PPP TCP/IP options are set up according to instructions provided by your ISP. For instance, be sure to enter the proper DNS Server IP numbers provided by your ISP.
6. Upon confirming all edits, return to the Dial-Up Networking dialog box, and click on New to add another entry. For the sake of this example we will name the entry "Corporate Server Connection". This time you will be designating the IP address of the target NT 4.0 Server in the Phone Number Entry, as well as directing the dial-out device to the Virtual Private Network port, typically named RASPPTPM#, where # is the number of the port. Your dial-up account entry should resemble the one in Figure 14. When you finish adding the new entry, return to the initial Dial-Up Networking dialog box.

   
   Figure 14

7. Click on Dial to dial your ISP number and establish the PPP connection. Type in any necessary logins 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 are ready to go on to the next step.
8. Without closing the currently active PPP connection, highlight your Corporate Server Connection entry, and click on Dial to initiate the PPTP connection.
9. If you obtain a second login box provided by the distant NT 4.0 Server, you have succeeded in traveling the second leg, and can operate through the PPTP connection. Logon as you would on the normal network, with a valid User ID and Password.

To streamline the two-step dialing process mentioned above, you can create a single autodial account that would initiate the PPP connection first, then automatically dial 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 previous to the second PPTP request to dial into a RAS Server. The steps below outline one method.

1. Open Dial-Up Networking after choosing Start, Programs, and Accessories from the tool bar menus.
2. Choose the Phonebook entry for your target server, the one which has the IP address entered instead of the phone number. Choose More, then Edit entry.
3. Click on the Scripts tab. Choose the Before Dialing button on the lower right of the dialog box.
4. At this point, if you have not already added the script for your ISP PPP connection, you can click on Edit Scripts to view and edit the switch.inf file using the notepad application. 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, i.e. [PPP Connection to ISP] at the beginning of the new section. When you are finished, save the file, return to the dialog box, and hit the Refresh button on the lower right to re-load the revised switch.inf file. Now, as Figure 15 shows, you can click on Run this script, and choose your new entry from the scroll down list.

   
   Figure 15

5. Click on 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 checked off during the initial logon by the user, it directs the system to automatically initiate Dial-Up Networking. The use 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.

As discussed earlier in this chapter, tunneling allows 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 Virtual Private Networks. Accounts are checked against the Windows NT user database; entry is not granted unless user names and respective passwords match. In this manner, even though remote users may 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 that have domain accounts, or that have accounts that have been granted specific access to the network through a trusted domain. Good management of user accounts will severely limit 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. Once 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 is 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:

1. On the Remote Access Server(s) that serve as entry points into the network, allow only PPTP sessions to obtain validation and consequently controlled access to the rest of the LAN. Through PPTP, the administrator will be certain that normal NT validations are taking place before access is granted.
2. Allow only encrypted data to be received or sent. This is configured on both servers and clients.

In both cases, the requirements can be forced upon remote users, simply by setting the options at the centrally located RAS Server. Remote Users will be informed if they are not properly set up for validation.

The first recommendation, allowing only PPTP sessions, can be applied through the Control Panel, then Network, then clicking on the Protocols tab. Highlight TCP/IP, click on the Properties button on the lower right, then choose Advanced on the right side of the resulting dialog box. At this point you can check off Enable PPTP Filtering, shown in Figure 16. Confirm your choice, and close all dialog boxes. You will 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 on My Computer on the desktop, open the Control Panel, click on Network, then the Services tab, and after highlighting Remote Access Services, click on the Properties button. At this point you can click once on a port, and choose the Network button on the right hand side. The resulting dialog box in Figure 17 has a section titled Encryption Settings, where you can check off Require Microsoft encrypted authentication, and Require data encryption.

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. After pressing the Start button, choose Programs, Accessories, then Dial-Up Networking. Choose the dial-in account for the target server. Then click on More, and choose Edit entry and modem properties from the drop-down menu. Click on the tab headed Security. You will see the dialog box in Figure 18. Here you can check off Accept only Microsoft encrypted authentication, as well as Require data encryption, to encrypt all data.

Monitoring PPTP

For the network administrator of the PPTP enabled RAS Server, monitoring PPTP Virtual Private Network sessions is identical to monitoring a 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 on Start, Programs, Administrative Tools, and finally on RAS Administration. Refer to the section on RAS Administration for further details on monitoring a RAS port’s status and activities.

This information came from http://www.zeev.com/Inter/nrpptp.htm

Return to previous menu