Windows NT 4.0: Virtual Private Networking

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft® Windows® NT 4.0 includes support for virtual private networking technology, which leverages the IP connectivity of the Internet to connect remote clients and remote offices. As a network professional, you should understand the important uses of virtual private networking for your organization and the underlying technologies that make it work: the Point-to-Point Tunneling Protocol (PPTP), virtual private networks and security, virtual private networks and routing and translation, virtual private networks and firewalls, and the troubleshooting of virtual private network connections. You should already be familiar with TCP/IP, IP routing, and the Windows NT 4.0 remote access server.

In This Documents

Virtual Private Networking Overview
Point-to-Point Tunneling Protocol
VPN Security
Addressing and Routing for VPNs
VPNs and Firewalls
VPNs and Network Address Translators
Pass-Through VPN Scenario
Troubleshooting VPNs

Related Topics

• For more information about TCP/IP, see "Introduction to TCP/IP" .

• For more information about unicast IP routing, see "Unicast IP Routing".

• For more information about the Windows NT 4.0 remote access server, see "Remote Access Server".

Virtual Private Networking Overview

A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. A VPN enables you to send data between two computers across a shared or public internetwork in a manner that emulates the properties of a point-to-point private link. The act of configuring and creating a virtual private network is known as virtual private networking.

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information allowing it to traverse the shared or public internetwork to reach its endpoint. To emulate a private link, the data being sent is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is known as a virtual private network (VPN) connection.

Figure 1 illustrates the logical concept of a VPN.

Figure 1: Virtual Private Network (VPN)

VPN connections allow users working at home or on the road to obtain a remote access connection to an organization server using the infrastructure provided by a public internetwork such as the Internet. From the user's perspective, the VPN is a point-to-point connection between the computer, the VPN client, and an organization server, the VPN server. The exact infrastructure of the shared or public network is irrelevant because it appears logically as if the data is sent over a dedicated private link.

VPN connections also allow organizations to have routed connections with geographically separate offices or with other organizations over a public internetwork such as the Internet while maintaining secure communications. A routed VPN connection across the Internet logically operates as a dedicated WAN link.

With both the remote access connection and with the routed connection, VPN connections allow an organization to trade in long distance dial-up or leased lines for local dial-up or leased lines to an Internet service provider (ISP).

Elements of a VPN Connection

A Windows NT 4.0 VPN connection includes the following components as illustrated in Figure 2.

VPN server. A computer that accepts VPN connections from VPN clients. A VPN server can provide a remote access VPN connection or a router-to-router VPN connection. For more information, see "VPN Connections" later in this chapter.

VPN client. A computer that initiates a VPN connection to a VPN server. A VPN client can be an individual computer that obtains a remote access VPN connection or a router that obtains a router-to-router VPN connection. Microsoft® Windows NT® version 4.0, Microsoft® Windows® 95, and Microsoft® Windows® 98–based computers can create remote access VPN connections to a Windows NT 4.0–based VPN server. Windows NT Server 4.0–based computers running the Routing and Remote Access Service (RRAS) can create router-to-router VPN connections to a Windows NT 4.0–based VPN server. VPN clients can also be any non-Microsoft Point-to-Point Tunneling Protocol (PPTP) client.

Tunnel. The portion of the connection in which your data is encapsulated.

VPN connection. The portion of the connection in which your data is encrypted. For secure VPN connections, the data is encrypted and encapsulated along the same portion of the connection.

Note: It is possible to create a tunnel and send the data through the tunnel without encryption. This is not a VPN connection because the private data is sent across a shared or public network in an unencrypted and easily readable form.

Tunneling protocols. Used to manage tunnels and encapsulate private data. (Data that is tunneled must also be encrypted to be a VPN connection.) Windows NT 4.0 includes the PPTP tunneling protocol. For detailed information about these protocols, see "Point-to-Point Tunneling Protocol" later in this chapter.

Tunneled data. Data that is usually sent across a private point-to-point link.

Transit internetwork. The shared or public internetwork crossed by the encapsulated data. For Windows NT 4.0, the transit internetwork is always an IP internetwork. The transit internetwork can be the Internet or a private IP-based intranet.

Figure 2: Components of a VPN Connection

VPN Connections

Creating the VPN is very similar to establishing a point-to-point connection using dial-up networking and demand-dial routing procedures. There are two types of VPN connections: the remote access VPN connection and the router-to-router VPN connection.

Remote Access VPN Connection

A remote access VPN connection is made by a remote access client, a single user computer, and connects to a private network. The VPN server provides access to the resources of the VPN server or to the entire network to which the VPN server is attached. The packets sent from the remote client across the VPN connection originate at the remote access client computer.

The remote access client (the VPN client) authenticates itself to the remote access server (the VPN server) and, for mutual authentication, the server authenticates itself to the client.

Router-to-Router VPN Connection

A router-to-router VPN connection is made by a router and connects two portions of a private network. The VPN server provides a routed connection to the network to which the VPN server is attached. On a router-to-router VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.

The calling router (the VPN client) authenticates itself to the answering router (the VPN server), and, for mutual authentication, the answering router authenticates itself to the calling router.

VPN Properties

VPN connections using PPTP have the following properties:

• Encapsulation

• Authentication

• Data encryption

• Address and name server allocation

Encapsulation

VPN technology provides a way of encapsulating the private data with a header that allows it to traverse the transit internetwork.

Authentication

For the VPN connection to be established, the VPN server authenticates the VPN client attempting the connection and verifies that the VPN client has the appropriate permissions. If mutual authentication is being used, the VPN client also authenticates the VPN server, providing protection against masquerading VPN servers.

Data Encryption

To ensure confidentiality of the data as it traverses the shared or public transit internetwork, it is encrypted by the sender and decrypted by the receiver. The encryption and decryption processes depend on both the sender and the receiver having knowledge of a common encryption key.

Intercepted packets sent along the VPN connection in the transit internetwork are unintelligible to anyone who does not have the common encryption key. The length of the encryption key is an important security parameter. Computational techniques can be used to determine the encryption key. Such techniques require more computing power and computational time as the encryption keys get larger. Therefore, it is important to use the largest possible key size.

In addition, the more information that is encrypted with the same key, the easier it is to decipher the encrypted data. With some encryption technologies, you are given the option to configure how often the encryption keys are changed during a connection.

For more information about how encryption keys are managed for the VPN technologies in Windows NT 4.0, see "VPN Security" later in this chapter.

Address and Name Server Allocation

When a VPN server is configured, it creates a virtual interface that represents the interface on which all VPN connections are made. When a VPN client establishes a VPN connection, a virtual interface is created on the VPN client that represents the interface connected to the VPN server. The virtual interface on VPN client is connected to the virtual interface on the VPN server creating the point-to-point VPN connection.

The virtual interfaces of the VPN client and the VPN server must be assigned IP addresses. The assignment of these addresses is done by the VPN server. By default, the VPN server obtains IP addresses for itself and VPN clients using the Dynamic Host Configuration Protocol (DHCP). You can also configure a static pool of IP addresses.

Name server allocation, the allocation of domain name system (DNS) and Windows Internet Name Service (WINS) servers, also occurs during the VPN connection establishment process. The VPN client obtains the IP addresses of the DNS and WINS servers from the VPN server for the intranet to which the VPN server is attached.

Internet and Intranet-Based VPN Connections

VPN connections can be used whenever a secure point-to-point connection is needed to connect users or networks. Typical VPN connections are either Internet-based or intranet-based.

Internet-Based VPN Connections

Using an Internet-based VPN connection, you can avoid long-distance and 1-800 telephone charges while taking advantage of the global availability of the Internet.

Remote Access over the Internet

Rather than a remote access client having to make a long distance or 1-800 call to a corporate or outsourced network access server (NAS), the client can call a local ISP. By using the established physical connection to the local ISP, the remote access client initiates a VPN connection across the Internet to the organization's VPN server. Once the VPN connection is created, the remote access client can access the resources of the private intranet.

Figure 3 illustrates remote access over the Internet.

Figure 3: A VPN Connection Connecting a Remote Client to a Private Intranet

Connecting Networks over the Internet

When networks are connected over the Internet (illustrated in Figure 4), a router forwards packets to another router across a VPN connection. To the routers, the VPN operates as a data-link layer link.

Figure 4: A VPN Connecting Two Remote Sites Across the Internet

Connecting Networks Using Dedicated WAN Links Rather than using an expensive long-distance dedicated WAN link between offices, the office routers are connected to the Internet using local dedicated WAN links to a local ISP. A router-to-router VPN connection is then initiated by either router across the Internet. Once connected, routers can forward directed or routing protocol traffic to each other using the VPN connection.

Connecting Networks Using Dial-Up WAN Links Rather than having a branch office router make a long distance or 1-800 call to a corporate or outsourced NAS, the branch office router calls a local ISP. Using the established connection to the local ISP, a router-to-router VPN connection is initiated by the branch office router to the corporate hub router across the Internet. The corporate hub router acting as a VPN server must be connected to a local ISP using a dedicated WAN link.

For more information about configuring VPN connections using a dial-up connection to a local ISP, see "Addressing and Routing for VPNs" later in this chapter.

It is possible to have both offices connected to the Internet using a dial-up WAN link. However, this is only feasible if the ISP supports demand-dialing routing to customers; the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs.

Intranet-Based VPN Connections

The intranet-based VPN connection takes advantage of IP connectivity in an organization intranet.

Remote Access over an Intranet

In some organization intranets, the data of a department, such as a human resources department, is so sensitive that the department's network segment is physically disconnected from the rest of the organization's intranet. While this protects the department's data, it creates information accessibility problems for those users not physically connected to the separate network segment.

VPN connections allow the sensitive department's network segment to be physically connected to the organization intranet but separated by a VPN server. The VPN server does not provide a direct routed connection between the corporate intranet and the separate network segment. Users on the corporate intranet with the appropriate permissions can establish a remote access VPN connection with the VPN server and can gain access to the protected resources of the sensitive department's network. Additionally, all communication across the VPN connection is encrypted for data confidentiality. For those users who do not have permissions to establish a VPN connection, the separate network segment is hidden from view.

Figure 5 illustrates remote access over an intranet.

Figure 5: A VPN Connection Allowing Remote Access to a Secured Network over an Intranet

Connecting Networks over an Intranet

You can also connect two networks over an intranet using a router-to-router VPN connection. This type of VPN connection might be necessary, for example, for two departments in separate locations, whose data is highly sensitive, to communicate with each other. For instance, the finance department might need to communicate with the human resources department to exchange payroll information.

The finance department and the human resources department are connected to the common intranet with computers that can act as VPN clients or VPN servers. Once the VPN connection is established, users on computers on either network can exchange sensitive data across the corporate intranet.

Figure 6 illustrates networks connected over an intranet.

Figure 6: A VPN Connection Connecting Two Networks over an Intranet

Managing Virtual Private Networking

Virtual private networking must be managed just like any other network resource, and VPN security issues, particularly with Internet VPN connections, must be addressed carefully. Consider the following questions:

• Where is the user account data to be stored?

• How are addresses assigned to VPN clients?

• Who is allowed to create VPN connections?

• How does the VPN server verify the identity of the user attempting the VPN connection?

• How does the VPN server record the VPN activity?

• How can the VPN server be managed using industry-standard network management protocols and infrastructure?

Managing Users

Because it is administratively unsupportable to have separate user accounts on separate servers for the same user and try to keep them all simultaneously current, most administrators set up a master account database at the primary domain controller (PDC) or on a Remote Authentication Dial-in User Service (RADIUS) server. This allows the VPN server to send the authentication credentials to a central authenticating device. The same user account is used for both dial-in remote access and VPN-based remote access.

Managing Addresses and Name Servers

The VPN server must have IP addresses available in order to allocate them to the VPN server's virtual interface and to VPN clients during the IP Control Protocol (IPCP) negotiation phase of the connection establishment process. The IP address allocated to the VPN client is assigned to the virtual interface of the VPN client.

For Windows NT 4.0–based VPN servers, the IP addresses allocated to VPN clients are obtained through DHCP by default. You can also configure a static IP address pool.

The VPN server must also be configured with DNS and WINS server addresses to allocate to the VPN client during IPCP negotiation.

Managing Access

Managing access for remote access VPN connections for Windows NT 4.0 is done through the configuration of the dial-in properties on user accounts. To manage remote access on an individual per-user basis, enable the Grant dialin permission to user setting on the Dialin properties of those user accounts that are allowed to create remote access connections and modify the properties of the Remote Access Service or the Routing and Remote Access Service for the needed connection parameters.

Managing Authentication

The Windows NT 4.0 Remote Access Service uses Windows NT authentication. The Windows NT 4.0 Routing and Remote Access Service (RRAS) can be configured to use either Windows NT or RADIUS as an authentication provider.

Windows NT 4.0 Authentication

If Windows NT 4.0 is selected as the authentication provider, then the user credentials sent by users attempting remote access connections are authenticated using normal Windows NT 4.0 authentication mechanisms.

RADIUS Authentication

If RADIUS is selected and configured as the authentication provider on the VPN server, user credentials and parameters of the connection request are sent as a series of RADIUS request messages to a RADIUS server.

The RADIUS server receives a user-connection request from the VPN server and authenticates the user using its authentication database. A RADIUS server can also maintain a central storage database of other relevant user properties. In addition to a yes or no response to an authentication request, RADIUS can inform the VPN server of other applicable connection parameters for this user—such as maximum session time, static IP address assignment, and so on.

RADIUS can respond to authentication requests based on its own database, or it can be a front end to another database server such as a generic Open Database Connectivity (ODBC) server or a Windows NT 4.0 PDC. The latter could be located on the same computer as the RADIUS server, or elsewhere. In addition, a RADIUS server can act as a proxy client to a remote RADIUS server.

The RADIUS protocol is described in RFC 2138 and RFC 2139. For more information about the RADIUS protocol and the Windows NT 4.0–based RADIUS server known as Internet Authentication Services, see "Internet Authentication Services" in this book.

Managing Accounting

The Windows NT 4.0 Routing and Remote Access Service (RRAS) can be configured to use RADIUS as an accounting provider. RADIUS accounting messages are sent to the RADIUS server for accumulation and later analysis.

Most RADIUS servers can be configured to place authentication request records into an accounting file. There are also a set of messages (from the remote access server to the RADIUS server) that request accounting records at the start of a call, the end of a call, and at predetermined intervals during a call. A number of third parties have written billing and audit packages that read these RADIUS accounting records and produce various useful reports.

Network Management

The computer acting as the VPN server can participate in a Simple Network Management Protocol (SNMP) environment as an SNMP agent if the Windows NT 4.0 SNMP Service is installed. The VPN server records management information in various object identifiers of the Internet Management Information Base (MIB) II, which is installed with the Windows NT 4.0 SNMP service. Objects in the Internet MIB II are documented in RFC 1213.

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.

Note: PPTP is documented in "Point-to-Point Tunneling Protocol," an Internet draft titled "pptp-draft-ietf-ppext-pptp-x.txt" where x denotes the current version of the draft. This Internet draft was submitted to the Internet Engineering Task Force (IETF) by the companies of the PPTP Forum, which include Microsoft Corporation, Ascend Communications, 3Com, ECI Telematics, and US Robotics (now 3Com). Internet draft documents are works in progress. See https://www.ietf.org for copies of Internet drafts.

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 tunnel client using the PPTP tunneling protocol) and a PPTP server (a tunnel 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 NT 4.0, 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.

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 7. The PPTP control connection packet in Figure 8 also includes a data-link layer header and trailer.

Figure 7: PPTP Control Connection Packet

Table 1 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 1 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. Note: The PPTP Echo-Request and Echo-Reply messages are not related to the ICMP Echo Request and Echo Reply messages.
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 the exact structure of PPTP control connection messages, see the PPTP Internet draft.

PPTP Data Tunneling

PPTP data tunneling is performed through multiple levels of encapsulation.

Figure 8 shows the resulting structure of PPTP tunneled data.

Figure 8: 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 to encapsulate 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.

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 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:

1. Processes and removes the data-link header and trailer.

2. Processes and removes the IP header.

3. Processes and removes the GRE and PPP headers.

4. Decrypts or decompresses, or both, the PPP payload (if needed).

5. Processes the payload for receipt or forwarding.

PPTP Packets and Windows NT 4.0 Networking Architecture

Figure 9 illustrates the path that tunneled data takes through the Windows NT 4.0 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline this process:

1. An IP datagram, IPX datagram, or NetBEUI frame is submitted by its appropriate protocol to the virtual interface that represents the VPN connection using NDIS.

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

3. 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 is set to the appropriate value to identify the tunnel.

4. The PPTP protocol driver then submits the resulting packet to the TCP/IP protocol driver.

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

6. NDIS submits the packet to NDISWAN, which provides PPP headers and trailers.

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

Figure 9: 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.

VPN Security

Security is a vital part of a VPN. Described in the following sections are the security facilities of PPTP VPN connections.

PPTP Connections

PPTP offers user authentication and encryption.

User Authentication with PPP

The user attempting the PPTP connection is authenticated using PPP-based user authentication protocols such as EAP, MS-CHAP, CHAP, SPAP, and PAP. For PPTP connections, EAP-TLS using smart cards or MS-CHAP version 2 is highly recommended as they provide mutual authentication and are the most secure methods of exchanging credentials.

Encryption with MPPE

PPTP inherits MPPE encryption, which uses the RSA RC4 stream cipher. MPPE is only available when either the EAP-TLS or MS-CHAP (version 1 or version 2) authentication protocols are used.

MPPE can use either 40-bit or 128-bit encryption keys. The 40-bit key is designed for international use and adheres to United States encryption export laws. The 128-bit key is designed for North American use. By default, the highest key strength supported by the VPN client and VPN server is negotiated during the connection establishment process. If the VPN server requires a higher key strength than is supported by the VPN client, the connection attempt is rejected.

MPPE was originally designed for encryption across a point-to-point link where packets arrive in the same order in which they were sent with little packet loss. For this environment, the decryption of each packet depends on the decryption of the previous packet.

However, for VPNs, IP datagrams sent across the Internet can arrive in a different order from the one in which they were sent, and a higher proportion of packets can be lost. Therefore, MPPE for VPN connections changes the encryption key for each packet. The decryption of each packet is independent of the previous packet. MPPE includes a sequence number in the MPPE header. If packets are lost or arrive out of order, the encryption keys are changed relative to the sequence number.

PPTP Packet Filtering

A PPTP-based VPN server typically has two physical interfaces: one interface on the shared or public network like the Internet, and another on the private intranet. It also has a virtual interface connecting to all VPN clients. For the VPN server to forward traffic between VPN clients, IP forwarding must be enabled on all interfaces. However, enabling forwarding between the two physical interfaces causes the VPN server to route all IP traffic from the shared or public network to the intranet. To protect the intranet from all traffic not sent by a VPN client, PPTP packet filtering must be configured so that the VPN server only performs routing between VPN clients and the intranet and not between potentially malicious users on the shared or public network and the intranet.

PPTP packet filtering can be configured on either the VPN server or on an intermediate firewall. For more information, see "VPNs and Firewalls" later in this chapter.

Addressing and Routing for VPNs

To understand how VPNs work, you must understand how addressing and routing is affected by the creation of remote access VPNs and router-to-router VPNs. A VPN connection creates a virtual interface that must be assigned a proper IP address, and routes must be changed or added to ensure that the proper traffic is sent across the secure VPN connection instead of the shared or public transit internetwork.

Remote Access VPN Connections

For remote access VPN connections, a computer creates a remote access connection to a VPN server. During the connection process the VPN server allocates an IP address for the remote access VPN client and changes the default route on the remote client so that default route traffic is sent over the virtual interface.

IP Addresses and the Dial-up VPN Client

For dial-up VPN clients who connect to the Internet before creating a VPN connection with a VPN server on the Internet, two IP addresses are allocated:

• When creating the PPP connection, IPCP negotiation with the ISP NAS allocates a public IP address.

• When creating the VPN connection, IPCP negotiation with the VPN server allocates an intranet IP address. The IP address allocated by the VPN server can be a public IP address or private IP address, depending on whether your organization is implementing public or private addressing on its intranet.

In either case, the IP address allocated to the VPN client must be reachable by hosts on the intranet and vice versa. The VPN server must have appropriate entries in its routing table to reach all the hosts on the intranet and the routers of the intranet must have the appropriate entries in their routing tables to reach the VPN clients.

The tunneled data sent through the VPN is addressed from the VPN client's VPN server-allocated address to an intranet address. The outer IP header is addressed between the ISP-allocated IP address of the VPN client and the public address of the VPN server. Because the routers on the Internet only process the outer IP header, the Internet routers forward the tunneled data to the VPN server's public IP address.

An example of dial-up client addressing is shown in Figure 10 where the organization uses private addresses on the intranet, and the tunneled data is an IP datagram.

Figure 10: Public and Private Addresses in PPTP Tunneled Data

Default Routes and Dial-up Clients

When a typical dial-up client dials the ISP, it receives a public IP address from the ISP NAS. A default gateway address is not allocated as part of the IPCP negotiation process. Therefore, in order to reach all Internet addresses, the dial-up client adds a default route to its routing table using the dial-up interface connected to the ISP. As a result, the client can forward the IP datagrams to the ISP NAS from where they are routed to its Internet location.

For dial-up clients with no other TCP/IP interfaces, this is the desired behavior. However, this behavior can cause confusion for dial-up clients that have an existing LAN-based connection to an intranet. In this scenario, a default route already exists pointing to the local intranet router. When the dial-up client creates a connection with their ISP, the original default route remains in the routing table but is changed to have a higher metric. A new default route is added with lower metric using the ISP connection.

As a result, the intranet locations that are not on the dial-up client's directly attached network are not reachable for the duration of the connection to the ISP. If the new default route is not created, all intranet locations are reachable, but Internet locations are not.

A Windows NT 4.0–based dial-up client creates the default route by default. To disable the default route from being created, clear the Use default gateway on remote network check box on the PPP TCP/IP Settings dialog box from the Server tab on a dial-up networking phonebook entry.

To achieve connectivity to both intranet and Internet locations while the ISP connection is active, leave the Use default gateway on remote network option selected and add the routes of the intranet to the routing table of the dial-up client. The intranet routes can be added through static persistent routes. When connected to the ISP, all intranet locations are reachable using the intranet routes and all Internet locations are reachable using the default route.

Default Routes and VPNs over the Internet

When the dial-up client calls the ISP, it adds a default route using the connection to the ISP as shown in Figure 11. At this point, it can reach all Internet addresses through the router at the ISP NAS.

Figure 11: Default Route Created When Dialing the ISP

Once the VPN client creates the VPN connection, another default route and a host route to the IP address of the tunnel server are added, as illustrated in Figure 12. The previous default route is saved but now has a higher metric. Adding the new default route means that all Internet locations except the IP address of the tunnel server are not reachable for the duration of the VPN connection.

Figure 12: Default Route Created When Initiating the VPN

Just as in the case of a dial-up client connecting to the Internet, when a dial-up VPN client using voluntary tunneling creates a VPN connection to a private intranet across the Internet, one of the following occurs:

• Internet locations are reachable and intranet locations are not reachable when the VPN connection is not active.

• Intranet locations are reachable and Internet locations are not reachable when the VPN connection is active.

For most Internet-connected VPN clients, this behavior does not represent a problem because they are typically engaged in either intranet or Internet communication, not both.

For VPN clients who want concurrent access to intranet and Internet resources when the VPN is connected, the solution depends on the nature of the IP addressing in the intranet. In all cases, configure the VPN connection object so that it does not add a default gateway. When the VPN connection is created, the default route remains pointed to the ISP NAS, allowing access to all Internet addresses.

Based on the type of intranet addressing you use, enable concurrent access to intranet and Internet resources as follows:

Public Address Add static persistent routes for the public network IDs of the intranet using the IP address of the VPN server's virtual interface as the gateway IP address.

Private Addresses Add static persistent routes for the private network IDs of the intranet using the IP address of the VPN server's virtual interface as the gateway IP address.

Overlapping or Illegal Addresses If the intranet is using overlapping or illegal addresses (IP network IDs that are not private and have not been registered by InterNIC or obtained from an ISP), those IP addresses might be duplicated by public addresses on the Internet. If static persistent routes are added on the VPN client for the overlapping network IDs of the intranet, the locations on the Internet for the overlapping addresses are not reachable.

In each of these cases, static persistent routes for the network IDs of the intranet need to be added to the VPN client. Once the persistent routes are added, they are saved in the registry. With Microsoft® Windows NT® version 4.0 Service Pack 3 and later and with Windows NT 4.0, the persistent routes are not actually added to the IP routing table (and are not visible with the route print command at the Windows NT 4.0 command prompt) until the IP address of the gateway is reachable. The IP address of the gateway becomes reachable when the VPN connection is made.

For each route, type the following route utility syntax at a Windows NT 4.0 command prompt:

ROUTE ADD <Intranet Network ID> MASK <NetMask> <IP address of VPN
server's virtual interface> -p

The gateway IP address in the route commands for each intranet route is the IP address assigned to the VPN server's virtual interface, not the IP address of the VPN server's Internet interface.

You can determine the IP address of the VPN server's virtual interface from the ipconfig command run at a Windows NT 4.0 command prompt. If you use DHCP to obtain IP addresses for dial-up networking and VPN clients, the IP address of the VPN server's virtual interface is the first IP address obtained when requesting DHCP addresses. If you have configured a static IP address pool, the IP address of the VPN server's virtual interface is the first IP address in the static IP address pool. You can also determine the IP address of the VPN server's virtual interface by observing the details of an active VPN connection from the VPN client.

Caution: For all of these cases, you must add the routes very carefully to ensure that the private traffic to the intranet is forwarded using the VPN connection and not the PPP connection to the ISP. If the wrong routes are added, the traffic that you intend to forward across the VPN in an encrypted form is instead sent unencrypted across the Internet. For example, if your intranet is using the public network ID 207.46.130.0/24 (subnet mask 255.255.255.0), and you mistakenly add a persistent static route for 207.46.131.0/24, all traffic to the intranet network 207.46.130.0/24 is forwarded across the Internet in plaintext, rather than being encrypted and sent across the VPN connection.

Router-to-Router VPN Connections

For router-to-router VPNs using the Routing and Remote Access Service (RRAS), the routing interface used to forward packets is a demand-dial interface configured as follows:

• On the General tab, type the host name or IP address of the VPN server.

• On the Protocols tab, select the protocols to be routed.

• On the Security tab, select Accept only Microsoft encrypted authentication and Require data encryption.

• For the credentials for the demand-dial interface, type the user name, password, and domain name used to verify the VPN client.

The creation of demand-dial interfaces is automated with the Demand Dial Interface Wizard.

The names of the demand-dial interfaces and the calling router credentials must be properly matched to ensure a router-to-router VPN connection.

Temporary vs. Persistent Router-to-Router VPNs

Router-to-router VPN connections can be either temporary or persistent.

Temporary router-to-router VPN connections are made when there are packets to be routed across the VPN demand-dial interface and terminated after a specified amount of idle time. Idle time is configured on the VPN client (the calling router). The default idle time for demand-dial interfaces on the VPN client is unlimited. Use temporary router-to-router VPN connections for branch offices who use dial-up connections to their local ISPs.

Persistent router-to-router VPN connections are made when the router is started and remain connected regardless of the traffic being sent. If the VPN connection is terminated, it is automatically attempted again. Use persistent router-to-router VPN connections to connect offices that have permanent connections to the Internet. Idle disconnect time is configured on the Dialing tab on the properties of a demand-dial connection.

VPNs Using Dial-Up ISP Connections

When both the VPN server and the VPN client are directly connected to the Internet using a permanent WAN link such as T1 or Frame Relay, the VPN connection can be persistent and available 24 hours a day. However, when a permanent WAN link is not possible or practical, you can configure an on-demand router-to-router VPN connection using a dial-up ISP.

An on-demand router-to-router VPN connection using a dial-up ISP connection consists of two demand-dial interfaces:

• A demand-dial interface to dial-in to a local ISP.

• A demand-dial interface for the router-to-router VPN connection.

An on-demand router-to-router VPN connection is automatically established when traffic to be forwarded across the VPN connection is received by the branch office router. For example, when receiving a packet to be routed to the corporate office, the branch office router first uses a dial-up link to connect to a local ISP. Once the Internet connection is made, the branch office router, the VPN client, creates a router-to-router VPN connection with the corporate office router, the VPN server.

To configure an on-demand VPN connection at the branch office router

1. Create a demand-dial interface for the Internet connection configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password used to gain Internet access.

2. Create a demand-dial interface for the router-to-router VPN connection with the corporate office router configured for a PPTP device, the IP address or host name of the corporate office VPN server's interface on the Internet, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand-dial interface on the corporate office VPN server.

3. Create a static host route for the IP address of the VPN server's Internet interface that uses the demand-dial interface used to dial the local ISP.

4. Create a static route (or routes) for the IP network IDs of the corporate intranet that uses the VPN demand-dial interface.

To configure the corporate office router

1. Create a demand-dial interface for the VPN connection with the branch office configured for a PPTP device. The demand-dial interface must have the same name as the user name in the authentication credential that is used by the branch office router to create the VPN connection.

2. Create a static route or routes for the IP network IDs of the branch office that uses the VPN demand-dial interface.

The router-to-router VPN connection is automatically initiated by the branch office router through the following process:

1. Packets sent to a corporate hub network location from a user in the branch office are forwarded by the user to the branch office router.

2. The branch office router checks its routing table and finds a route to the corporate intranet network ID, which uses the VPN demand-dial interface.

3. The branch office router checks the state of the VPN demand-dial interface and finds it is in a disconnected state.

4. The branch office router retrieves the configuration of the VPN demand-dial interface.

5. Based on the VPN demand-dial interface configuration, the branch office router attempts to initialize a router-to-router VPN connection at the IP address of the VPN server on the Internet.

6. To establish a PPTP-based VPN, a TCP connection must be established with the VPN server. The VPN establishment packet is created.

7. To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route using the ISP demand-dial interface.

8. The branch office router checks the state of the ISP demand-dial interface and finds it is in a disconnected state.

9. The branch office router retrieves the configuration of the ISP demand-dial interface.

10. Based on the ISP demand-dial interface configuration, the branch office router uses its modem or ISDN adapter to dial and establish a connection with its local ISP.

11. Once the ISP connection is made, the VPN establishment packet is sent by the branch office router to the corporate office router.

12. A VPN is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router.

13. The corporate office router checks its demand-dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state.

14. The branch office router forwards the packet across the VPN and the VPN server forwards the packet to the appropriate intranet location.

Static vs. Dynamic Routing

Once the demand-dial interfaces are created and the choice has been made between temporary and persistent connections, you must choose one of the following methods for adding routing information to the routing table:

1. For temporary connections, you can manually add the appropriate static routes to reach network IDs in the other offices. Manual configuration of static routes is appropriate for small implementations with a small number of routes.

2. For temporary connections, you can use auto-static updates to periodically update the static routes that are available across the router-to-router VPN connection. Auto-static routes works well for larger implementations with a large amount of routing information.

3. For persistent connections, run the appropriate routing protocols over the router-to-router VPN connection treating the VPN connection as a point-to-point link.

Note: Unlike demand-dial routing using direct physical connections, you cannot use a default IP route configured for the VPN demand-dial interface to summarize all the intranet routes available across the VPN. Because the router is connected to the Internet, you must use the default route to summarize all the routes of the Internet and configure it to use the Internet interface.

VPNs and Firewalls

A firewall employs packet filtering to allow or disallow the flow of very specific types of network traffic. IP packet filtering provides a way for you to define precisely what IP traffic is allowed to cross the firewall. IP packet filtering is important when you connect private intranets to public networks like the Internet.

VPN Server and Firewall Configurations

There are two approaches to using a firewall with a VPN server:

• The VPN server is attached to the Internet and the firewall is between the VPN server and the intranet.

• The firewall is attached to the Internet and the VPN server is between the firewall and the intranet.

VPN Server in Front of the Firewall

With the VPN server in front of the firewall attached to the Internet, as shown in Figure 13, you need to add packet filters to the Internet interface that only allow VPN traffic to and from the IP address of the VPN server's interface on the Internet.

For inbound traffic, once the tunneled data is decrypted by the VPN server, it is forwarded to the firewall, which employs its filters to allow the traffic to be forwarded to intranet resources. Because the only traffic that is crossing the VPN server is traffic generated by authenticated VPN clients, firewall filtering in this scenario can be used to prevent VPN users from accessing specific intranet resources.

Because the only Internet traffic allowed on the intranet must go through the VPN server, this approach also prevents the sharing of File Transfer Protocol (FTP) or Web intranet resources with non-VPN Internet users.

Figure 13: VPN Server on the Internet in Front of the Firewall

For the Internet interface on the VPN server, configure the following input and output filters using the Routing and RAS Admin administrative tool.

Packet Filters for PPTP

Configure the following input filters with the filter action set to drop all except listed below:

• Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP destination port of 1723 (0x06BB).

  This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

• Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47 (0x2F).

  This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

• Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP [established] source port of 1723 (0x06BB).

  This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is accepted only if the VPN server initiated the TCP connection.

Configure the following output filters with the filter action set to drop all except listed below:

• Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP Source Port of 1723 (0x06BB).

  This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

• Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47 (0x2F).

  This filter allows PPTP tunneled data from the VPN server to the VPN client.

• Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP [established] destination port of 1723 (0x06BB).

  This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is sent only if the VPN server initiated the TCP connection.

VPN Server Behind the Firewall

In a more common configuration, illustrated in Figure 14, the firewall is connected to the Internet and the VPN server is another intranet resource connected to a demilitarized zone (DMZ). The DMZ is an IP network segment that typically contains resources available to Internet users such as Web servers and FTP servers. The VPN server has an interface on the DMZ and an interface on the intranet.

In this approach, the firewall must be configured with input and output filters on its Internet interface to allow the passing of tunnel maintenance traffic and tunneled data to the VPN server. Additional filters can allow the passing of traffic to Web servers, FTP servers, and other types of servers on the DMZ.

Because the firewall does not have the encryption keys for each VPN connection, it can only filter on the plaintext headers of the tunneled data, meaning that all tunneled data passes through the firewall. However, this is not a security concern because the VPN connection requires an authentication process that prevents unauthorized access beyond the VPN server.

Figure 14: VPN Server Behind the Firewall on the Internet

For the Internet interface on the firewall, the following input and output filters need to be configured using the firewall's configuration software.

Packet Filters for PPTP

Configure the following input filters with the filter action set to drop all except listed below:

• Destination IP address of the VPN server's DMZ interface and TCP destination port of 1723 (0x06BB).

  This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

• Destination IP address of the VPN server's DMZ interface and IP Protocol ID of 47 (0x2F).

  This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

• Destination IP address of the VPN server's DMZ interface and TCP [established] source port of 1723 (0x06BB).

  This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is accepted only if the VPN server initiated the TCP connection.

Configure the following output filters with the filter action set to drop all except listed below.

• Source IP address of the VPN server's DMZ interface and TCP Source Port of 1723 (0x06BB).

  This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

• Source IP address of the VPN server's DMZ interface and IP Protocol ID of 47 (0x2F).

  This filter allows PPTP tunneled data from the VPN server to the VPN client.

• Source IP address of the VPN server's DMZ interface and TCP [established] destination port of 1723 (0x06BB).

  This filter is required only if the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. When you select TCP [established], traffic is sent only if the VPN server initiated the TCP connection.

Troubleshooting VPNs

To troubleshoot VPNs, you must troubleshoot IP connectivity, remote access connection establishment, and routing.

Common VPN Problems

VPN problems typically fall into the following categories:

• Connection attempt is rejected when it should be accepted.

• Unable to reach locations beyond the VPN server.

• Unable to establish a tunnel.

Use the following troubleshooting tips to isolate the configuration or infrastructure problem causing the stated VPN problem.

Connection Attempt is Rejected when it Should be Accepted

• Using the ping command, verify that the host name or IP address of the VPN server is reachable. If a host name is being used, verify that the host name is resolved to its correct IP address. If the ping is not successful, Internet Control Message Protocol (ICMP) packet filtering might be preventing the delivery of ICMP messages to or from the VPN server.

• Verify that the Remote Access Service or the Routing and Remote Access service is running on the VPN server.

• Verify that all of the PPTP ports on the VPN server are not already being used. If necessary, configure the properties on the Point-to-Point Tunneling Protocol in Control Panel-Network and change the number of PPTP ports to allow more concurrent connections.

• Verify that the VPN client and the VPN server are configured for common authentication settings.

• Verify that the VPN client and the VPN server are configured for common encryption settings.

• Verify that the LAN protocol(s) being used by the VPN clients is enabled for remote access.

• Verify that the VPN client's credentials consisting of user name, password, and domain name are correct and can be validated by the VPN server.

• Verify that the user account corresponding to the user credentials of the VPN client has been granted dialin permission.

• If the VPN server is configured to use DHCP to allocate IP addresses to remote access clients, verify that a DHCP server is available.

• If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool.

  If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address, and the connection attempt is rejected.

• Verify the configuration of the authentication provider.

  An RRAS-based VPN server can be configured to use either Windows NT 4.0 or RADIUS to authenticate the credentials of the remote access client.

• For remote access VPN connections, verify that the PPTP ports are configured to receive calls.

• For remote access VPNs, verify that the LAN protocols being used by the VPN clients are enabled for remote access.

Unable to Reach Locations Beyond the VPN Server

• For remote access VPNs, verify that the Entire network option is selected for LAN protocols being used by the VPN clients.

• Verify the IP address pool of the VPN server.

  If the VPN server is configured to use a static IP address pool, verify that the route to the range of addresses defined by the static IP address pool is reachable by the hosts and routers of the intranet. If not, an IP route consisting of the VPN server's static IP address pool, {IP Address, Subnet Mask}, must be added to the routers of the intranet. If the route is not added, remote access clients cannot receive traffic from resources on the intranet. A route for the network can be implemented through static routing entries or through a routing protocol such as RIP or OSPF.

  If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, a route to 169.254.0.0/16 (subnet mask 255.255.0.0) must be added to the routers of the intranet. When the VPN server is configured to use DHCP, and no DHCP server is found, the VPN server allocates addresses from the AutoNet address range of 169.254.0.0/16.

  If the static IP address pool is a range of IP addresses that is a subset of the range of IP addresses for the network to which the VPN server is attached, verify that the range of IP addresses in the static IP address pool are not assigned to other TCP/IP nodes either statically or through DHCP.

• For router-to-router VPNs, verify that the router-to-router VPN connection is not interpreted by the VPN server as a remote access connection.

  Verify that the calling router's connection appears as a Demand-dial type under Active Connections and Ports in the Routing and RAS Admin administrative tool. If not, verify that the user name in the calling router's credentials matches the name of a demand-dial interface on the VPN server.

Unable to Establish Tunnel

• Verify that packet filtering on a router interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic.

  On a Windows NT 4.0–based VPN server, IP packet filtering can be configured from the advanced TCP/IP properties and from the Routing and RAS Admin administrative tool. Check both places for filters that might be excluding VPN connection traffic.

  For more information about VPN connection traffic and packet filtering, see "VPNs and Firewalls" earlier in this chapter.

• Verify that the WinSock Proxy client is not currently running on the VPN client.

  When the WinSock Proxy client is active, WinSock API calls such as those used to create tunnels and send tunneled data are intercepted and forwarded to a configured proxy server.

  A proxy server–based computer allows an organization to access specific types of Internet resources (typically Web and FTP) without directly connecting that organization to the Internet . The organization can use InterNIC-allocated private IP network IDs (such as 10.0.0.0/8).

  Proxy servers are typically used so that private users in an organization can have access to public Internet resources as if they were directly attached to the Internet. VPN connections are typically used so that authorized public Internet users can gain access to private organization resources as if they were directly attached to the private network. A single computer can act as a proxy server (for private users) and a VPN server (for authorized Internet users) to facilitate both exchanges of information.

Troubleshooting Tools

The following tools, which enable you to gather additional information about the source of your VPN problem, are included with Windows NT 4.0.

Unreachability Reason

When a demand-dial interface fails to make a connection, the interface is left in an unreachable state. Right-click in the interface, and then select Unreachability reason to obtain more information about why the interface was unable to connect.

Network Monitor

Use Network Monitor, a packet capture and analysis tool, to view the traffic sent between a VPN server and VPN client during the VPN connection process and during data transfer. You cannot interpret the encrypted portions of VPN traffic with Network Monitor.

The proper interpretation of the remote access and VPN traffic with Network Monitor requires an in-depth understanding of PPP, PPTP, and other protocols. For more information about PPP, see "Remote Access Server". Network Monitor captures can be saved as files and sent to Microsoft Product Support Services for analysis.

PPP Log or PPP Tracing

The PPP log or PPP tracing records the sequence of programming functions called during a process, either to a console window or to a file. Enable the PPP log or PPP tracing for remote access components and try the connection again. After you are done viewing the traced information, reset the tracing settings back to their default values.

The tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft PSS engineers, or to network administrators who are very experienced with the routing and remote access server. The tracing information can be saved as files and sent to Microsoft PSS for analysis.

For more information about the PPP log and PPP tracing, see "Remote Access Server".