Windows NT 4.0: Remote Access Server

Article
02/20/2014

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 has extensive support for remote access technology to connect remote clients to corporate networks or the Internet. This chapter clarifies how remote access works and details how to troubleshoot remote access problems.

This chapter is intended for network engineers and support professionals who are already familiar with TCP/IP, IP routing, IPX routing, and wide area network technology.

Related Topics

For more information about TCP/IP routing, see "Introduction to TCP/IP".
For more information about unicast IP routing, see "Unicast IP Routing".
For more information about IPX routing, see "IPX Routing".
For more information about virtual private networking, see "Virtual Private Networking".

Remote Access Overview

With Windows NT remote access, remote access clients connect to remote access servers and are transparently connected to the remote access server, known as point-to-point remote access connectivity, or transparently connected to the network to which the remote access server is attached, known as point-to-LAN remote access connectivity. This transparent connection allows remote access clients to dial-in from remote locations and access resources as if they were physically attached to the network.

Windows NT 4.0 remote access provides two different types of remote access connectivity:

Dial-up remote access

With dial-up remote access, a remote access client uses the telecommunications infrastructure to create a temporary physical circuit or a virtual circuit to a port on a remote access server. Once the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.
Virtual private network (VPN) remote access

With virtual private network remote access, a VPN client uses an IP internetwork to create a virtual point-to-point connection with a remote access server acting as the VPN server. Once the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.

Note: This chapter is primarily devoted to the discussion of dial-up remote access; however, many topics also apply to VPN remote access. For a complete understanding of VPNs, read this chapter first and then read the chapter covering "Virtual Private Networking".

Remote Access Versus Remote Control

The distinctions between remote access and remote control solutions are the following:

The remote access server is a software-based multi-protocol router; remote control solutions work by sharing screen, keyboard, and mouse over the remote link. In remote access, the applications are run on the remote access client computer.
In a remote control solution, users share a CPU or multiple CPUs on the server. In remote control, the applications are run on the server. The remote access server's CPU is dedicated to communications, not to running applications.

Elements of a Dial-Up Remote Access Connection

A dial-up remote access connection consists of a remote access client, a remote access server and a wide area network (WAN) infrastructure as illustrated in Figure 1.

Figure 1: Elements of a Dial-Up Remote Access Connection

Figure 1: Elements of a Dial-Up Remote Access Connection

Remote Access Client

Windows NT 4.0, Microsoft® Windows NT® 3.5 and later, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® for Workgroups, MS-DOS®, and Microsoft® LAN Manager remote access clients can all connect to a Windows NT 4.0 remote access server. Third-party Point-to-Point Protocol (PPP) remote access clients can also connect with a Windows NT 4.0 remote access server.

Remote Access Server

The Windows NT 4.0 remote access server accepts dial-up connections and forwards packets between remote access clients and the network to which the remote access server is attached.

Note: The term remote access server as it is used in this chapter refers to a Windows NT 4.0 Server computer running the Remote Access Service or the Routing and Remote Access Service (RRAS) and configured to provide remote access.

Dial-Up Equipment and WAN Infrastructure

The physical or logical connection between the remote access server and the remote access client is facilitated by dial-up equipment installed at the remote access client, the remote access server, and the telecommunications infrastructure. The nature of the dial-up equipment and telecommunications infrastructure varies depending on the type of connection being made.

PSTN

The Public Switched Telephone Network (PSTN) is the analog phone system designed to carry the minimal frequencies to distinguish human voices. An alalog phone line using the PSTN is also known as a Plain Old Telephone Service (POTS) line. Because the PSTN was not designed for data transmissions, there are limits to the maximum bit rate of a PSTN connection. Dial-up equipment consists of an analog modem for the remote access client and the remote access server. For large organizations, the remote access server is attached to a modem bank containing up to hundreds of modems. With analog modems at both the remote access server and the remote access client, the maximum bit rate supported by PSTN connections is 33,600 bits per second, or 33.6 kilobits per second (Kbps).

Figure 2 illustrates a PSTN connection.

Figure 2: Dial-Up Equipment and WAN Infrastructure for PSTN Connections

Digital Links and V.90

The maximum bit rate of the PSTN is a function of the range of frequencies being passed by PSTN switches and the signal-to-noise ratio of the connection. The modern-day analog phone system is only analog on the local loop, the set of wires that connects the customer to the central office (CO) PSTN switch. Once the analog signal reaches the PSTN switch, it is converted to a digital signal. The analog-to-digital conversion introduces noise on the connection known as quantization noise.

When a remote access server is connected to a CO using a digital switch based on T-Carrier or IDSN rather than an analog PSTN switch, there is no analog-to-digital conversion when the remote access server sends information to the remote access client. There is no quantization noise in the downstream path to the remote access client, and therefore, there is a higher signal-to-noise ratio and a higher maximum bit rate.

With this new technology, called V.90, remote access clients can send data at 33.6 Kbps and receive data at 56 Kbps. In North America, the maximum receive bit rate is 53 Kbps due to Federal Communications Commission (FCC) power rules.

To obtain V.90 speeds, the following must be true:

The remote access client must call using a V.90 modem.
The remote access server must be using a V.90 digital switch and be connected to the PSTN using a digital link, such as T-Carrier or ISDN.
There cannot be any analog-to-digital conversions in the path from the remote access server to the remote access client.

Figure 3 illustrates a V.90-based PSTN connection.

Figure 3: Dial-Up Equipment and WAN Infrastructure for V.90 Connections

ISDN

The Integrated Services Digital Network (ISDN) is a set of international specifications for a digital replacement of the PSTN providing a single digital network to handle voice, data, fax, and other services over existing local loop wiring. ISDN offers multiple channels; each channel operates at 64 Kbps and because the network is digital end-to-end, there are no analog to digital conversions.

Dial-up equipment consists of an ISDN adapter for the remote access client and the remote access server. Remote access clients typically use Basic Rate ISDN (BRI) with two 64 Kbps channels, and large organizations typically use Primary Rate ISDN (PRI) with 23 64 Kbps channels.

Figure 4 illustrates an ISDN connection.

Figure 4: Dial-Up Equipment and WAN Infrastructure for ISDN Connections

X.25

X.25 is an international standard for sending data across public packet switching networks. Windows NT 4.0 remote access supports X.25 in two ways:

The remote access client supports the use of X.25 smart cards, which can connect directly to the X.25 data network and use the X.25 protocol to establish connections and send and receive data. The remote access client also supports dialing into a packet assembler/disassembler (PAD) of an X.25 carrier using an analog modem.
The remote access server only supports the use of X.25 smart cards.

Note: X.25 smart cards are adapters that use the X.25 protocol and can directly connect to an X.25 public data network. X.25 smart cards are not related to smart cards used for authentication and secure communications.

Figure 5 illustrates a X.25 connection.

Figure 5: Dial-Up Equipment and WAN Infrastructure for X.25 Connections

Figure 5: Dial-Up Equipment and WAN Infrastructure for X.25 Connections

Remote Access Protocols

Remote access protocols control the connection establishment and transmission of data over wide area network (WAN) links. The operating system and LAN protocols used on remote access clients and servers dictate which remote access protocol your clients can use.

There are three types of remote access protocols supported by Windows NT 4.0 remote access:

Point-to-Point Protocol (PPP) is an industry-standard set of protocols providing the best security, multi-protocol support, and interoperability.
Serial Line Internet Protocol (SLIP) is used by older remote access servers.
Microsoft RAS protocol, also known as Asynchronous NetBEUI or AsyBEUI, is a remote access protocol used by legacy remote access clients running Microsoft operating systems, such as Microsoft® Windows NT® 3.1, Windows for Workgroups, MS-DOS, and LAN Manager.

Table 1 summarizes the remote access protocols and their use in Windows NT 4.0.

Table 1 Remote Access Protocols and Their Use in Windows NT 4.0

Remote Access Client	Remote Access Server
PPP
SLIP
AsyBEUI

LAN Protocols

LAN protocols are the protocols used by the remote access client to access resources on the network connected to the remote access server. Windows NT 4.0 remote access supports TCP/IP, IPX, and NetBEUI. For more information, see "Remote Access and LAN Protocols" later in this chapter.

Elements of Secure Remote Access

Because remote access is designed to transparently connect a remote access client to a network and its potentially sensitive data, security of remote access connections is an important consideration. Windows NT 4.0 remote access offers a wide range of security features including secure user authentication, mutual authentication, data encryption, callback, and caller ID.

Secure User Authentication

Secure user authentication is obtained through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 and version 2, Challenge Handshake Authentication Protocol (CHAP), or Shiva Handshake Authentication Protocol (SPAP) authentication protocols. The remote access server can be configured to require a secure authentication method. If the remote access client cannot perform the required secure authentication, the connection is denied.

Mutual Authentication

Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using the MS-CHAP version 2 authentication protocols. During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.

Data Encryption

Data encryption encrypts the data sent between the remote access client and the remote access server. Data encryption is possible over dial-up remote access links when using the PPP remote access protocol and the MS-CHAP authentication protocols. The remote access server can be configured to require data encryption. If the remote access client cannot perform the required encryption, the connection attempt is rejected.

Remote access data encryption only provides data encryption on the communications link between the remote access client and the remote access server.

Microsoft® Windows NT® 4.0, Windows 98, and Windows 95 remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). MPPE uses the RSA RC4 stream cipher and either 40-bit or 128-bit secret keys. MPPE keys are generated from the MS-CHAP user authentication process.

Callback

With callback, the remote access server calls the remote access client after the user credentials have been verified. Callback can be configured to call the remote access client back at a number specified by the user of the remote access client during the time of the call. This allows a traveling user to dial-in and have the remote access server call them back at their current location, saving phone charges. Callback can also be configured to always call the remote access client back at a specific location, which is the secure form of callback.

Managing Remote Access

Remote access has the following management issues:

Where is the user account data to be stored?
How are addresses assigned to remote access clients?
Who is allowed to create remote access connections?
How does the remote access server verify the identity of the user attempting the remote access connection?
How does the remote access server record the remote access activity?
How can the remote access server be managed using industry-standard network management protocols and infrastructure?

Managing Users

Because it is administratively unsupportable to have separate user accounts for the same user on separate servers and to 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 remote access server to send the authentication credentials to a central authenticating device.

Managing Addresses

For PPP connections, IP and IPX addressing information must be allocated to remote access clients during the connection establishment process. The Windows NT 4.0 remote access server must be configured to allocate IP addresses and IPX network and node addresses.

More information on address allocation for IP and IPX can be found later in this chapter.

Managing Access

Managing access for remote access 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 remote access server, then 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 remote access server and authenticates the client against its authentication database. A RADIUS server can also maintain a central storage database of other relevant user properties. In addition to the simple yes or no response to an authentication request, RADIUS can inform the remote access 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 upon 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 server could be located on the same machine as the RADIUS server, or could be centralized elsewhere. In addition, a RADIUS server can act as a proxy client to a remote RADIUS server.

The RADIUS protocol is described in RFCs 2138 and 2139.

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 remote access server can participate in a Simple Network Management Protocol (SNMP) environment as an SNMP agent by installing the Windows NT 4.0 SNMP Service. The remote access server records management information in various object identifiers of the Internet Management Information Base (MIB) II that is installed with the Windows NT 4.0 SNMP service. Objects in the Internet MIB II are documented in RFC 1213.

Remote Access Server Architecture

The architecture of the remote access server consists of the following elements, as illustrated in Figure 7.

The NDIS wrapper, Ndis.sys, providing the NDIS packet-level interface to protocols, such as TCP/IP, IPX, NetBEUI, and AppleTalk.
The NDISWAN driver, Ndiswan.sys, an intermediate NDIS driver that provides an IEEE 802.3 miniport interface to protocol drivers and a protocol interface to WAN miniport drivers. NDISWAN provides framing, compression, and encryption services for remote access connections.
WAN miniport drivers are NDIS miniport drivers that contain the necessary code to operate the dial-up equipment. In order to use an adapter supporting WAN media, such as ISDN or ATM with Windows NT 4.0 remote access, the adapter vendor must create a WAN miniport driver.
Remote access components are a series of libraries that provide the Remote Access Service (RAS) programming interface for applications, PPP protocols (link control, authentication, and network control protocols), support for other remote access protocols, such as ARAP, and so on. Remote access components can communicate directly with the NDISWAN driver or by accessing the Telephone API (TAPI).
TAPI components are a series of libraries that provide a call control programming interface for all TAPI-aware applications. TAPI components communicate directly with the NDISWAN driver to manage connections.

Figure 7: Remote Access Architecture in Windows NT 4.0

Connections are established by remote access clients that call the RAS programming interface, which in turn uses TAPI to pass call connection information to the dial-up equipment. Once the physical connection is made, TAPI is no longer used and additional remote access components negotiate the connection with link, authentication, and network control protocols by communicating directly with NDISWAN.

Once a remote access connection is established, protocol drivers can communicate over that connection using standard NDIS calls like NdisSend(). NdisSend() calls for dial-up connections are forwarded to NDISWAN, which then determines the appropriate device and port, performs compression and encryption, provides PPP framing, and then forwards the completed frame to the WAN miniport driver. The WAN miniport driver then forwards the frame to the dial-up adapter.

All inbound remote access client connections, initiated by remote access clients to the remote access server, are represented as a single adapter called the RAS server interface. For each outbound remote access client connection, initiated by the remote access server, a separate interface is created.

To accept calls, the remote access server instructs each WAN miniport driver to indicate when it goes into a line-up state. When the call is placed, the WAN miniport driver passes the line-up state indicator up through NDISWAN to the TAPI components. TAPI returns a call handle to NDISWAN to be used to refer to the physical connection, and then NDISWAN and the remote access components negotiate the rest of the remote access connection.

IP and IPX Router

Once the remote access connection is established, the remote access client can begin sending LAN protocol traffic to the remote access server or to locations beyond the remote access server. When the remote access client sends LAN protocol traffic that is not destined for the remote access server, the remote access server must forward the LAN traffic to its appropriate destination. To accomplish this, the remote access server must have forwarding capabilities enabled on its routable protocols and act as an IP and IPX router.

When the Remote Access Service or Routing and Remote Access Service is installed and enabled to provide point-to-LAN remote access connectivity, it enables forwarding between the installed LAN adapters and the RAS server interface.

Figure 8 illustrates the RAS server architecture as it appears when routing packets. (In an effort to simplify the illustration, only IP routing is shown.) However IPX routing works in the same fashion.

Figure 8: IP Routing on the Remote Access Server

Figure 8: IP Routing on the Remote Access Server

Packets from Remote Access Clients

The following process describes how IP packets sent by the remote access client are forwarded by the remote access server.

Depending on the dial-up technology, either the entire PPP frame is received by the WAN hardware and passed up as a single frame to the appropriate WAN miniport driver or individual bits of the PPP frame are passed up to the appropriate WAN miniport driver.
The WAN miniport driver passes the PPP frame to Ndiswan.sys.
Ndiswan.sys verifies the PPP checksum and uses the PPP protocol ID to determine that it is an IP datagram. For more information on PPP, see "Point-to-Point Protocol" later in this chapter.
The IP datagram is passed to the TCP/IP protocol driver.
The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and an IP address based on the destination IP address in the IP datagram and the contents of its routing table.
To forward the IP datagram using the LAN adapter, the TCP/IP protocol calls NDIS with an NdisSend(), along with instructions to send it using the LAN adapter.
NDIS forwards the IP datagram to the appropriate LAN miniport driver.
The LAN miniport forwards the IP datagram to the LAN adapter through NDIS.

The end result is that packets from the remote access client are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the remote access server can find a suitable entry in the IP routing table. Therefore, either the remote access server is configured with a default gateway, or the remote access server has specific routes to all the locations on the intranet to which the remote access server is attached. Specific routes can be added through static routes, or by enabling a routing protocol on the remote access server.

Packets to Remote Access Clients

The following process describes how IP packets sent by intranet hosts to the remote access client are forwarded by the remote access server.

The LAN adapter passes a frame to its appropriate LAN miniport driver through NDIS. The details of how an IP datagram is forwarded to the MAC address of the remote access server can be found in "TCP/IP On-Subnet and Off-Subnet Addressing."
The LAN miniport driver passes the IP datagram to the TCP/IP protocol driver through NDIS.
The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and IP address based on the destination IP address in the IP datagram and the contents of its routing table. When the remote access client connects, a host route is created in the IP routing table for the IP address allocated to the remote access client that points to the RAS server interface.
To forward the IP datagram using the WAN adapter, the TCP/IP protocol calls NDIS with an NdisSend() with instructions to send it using NDISWAN and a specific connection handle.
NDISWAN resolves the connection handle to a specific device and port, adds a PPP header and trailer, and forwards the IP datagram to the appropriate WAN miniport driver through NDIS.
The WAN miniport forwards the IP datagram to the WAN adapter through NDIS.

The end result is that packets from intranet hosts are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the IP addresses of remote access clients are reachable from the hosts on intranet.

TCP/IP On-Subnet and Off-Subnet Addressing

The exact mechanism of how an IP node on a subnet to which the remote access server is attached resolves the MAC address of the LAN interface of the remote access server depends on whether the remote access server is configured for on-subnet or off-subnet addressing:

On-subnet addressing is the allocation of IP addresses to remote access clients that are in a range defined by a subnet to which the remote access server is attached. On-subnet addressing uses a subset of addresses of an attached subnet.
Off-subnet addressing is the allocation of IP addresses to remote access clients that are not in a range defined by a subnet to which the remote access server is attached. Off-subnet addressing uses a separate subnet address space that is unique to the intranet.

On-Subnet Addressing and Proxy ARP

With on-subnet addressing, remote access clients are logically on the same subnet as a subnet attached to the remote access server. Proxy ARP is used by the remote access server to receive IP datagrams being forwarded to remote access clients.

There are two cases where Proxy ARP is used:

When the remote access server is configured to use DHCP to obtain addresses for IP-based remote access clients
When the remote access server is configured with a static IP address pool that is a subset of addresses for a subnet to which the remote access server is attached.

In either case, the remote access clients are logically on the same subnet as the remote access server. Therefore, IP nodes on that subnet forwarding IP datagrams to a remote access client perform a direct delivery by sending a broadcast Address Resolution Protocol (ARP) Request frame for the remote access client's IP address.

The remote access client cannot respond to the ARP Request because the remote access server does not forward the ARP Request frame to the remote access client, and the remote access client does not have a Media Access Control (MAC) address corresponding to the remote access connection.

Therefore, the remote access server responds with an ARP Reply frame with its own MAC address. The node forwarding the packet then sends the IP datagram to the remote access server's MAC address. The remote access server then uses the IP routing process to forward the IP datagram across the dial-up connection to the remote access client.

Off-Subnet Addressing and IP Routing

With off-subnet addressing, remote access clients are logically on a separate subnet reachable across the remote access server. In this case, Proxy ARP is not used. The remote access server is acting as a router between the subnet of the remote access clients and the subnet(s) to which the remote access server is attached. IP nodes on the LAN-based subnet(s) attached to the remote access server forwarding IP datagrams to a remote access client perform an indirect delivery by sending a broadcast Address Resolution Protocol (ARP) Request frame for the remote access server's IP address.

In order for the remote access clients to be reachable from IP nodes on the intranet, a route representing the IP address pool and pointing to the LAN interface of the remote access server must be present in intranet routers.

When the first TCP/IP-based remote access client connects, a route corresponding to the off-subnet address pool pointing to the RAS server interface is added to the IP routing table of the remote access server. If the remote access server is configured with an IP routing protocol, the new route is advertised to neighboring routers using the normal advertising process of the configured routing protocol. If the remote access server is not configured with an IP routing protocol, a static route corresponding to the off-subnet address pool pointing to the remote access server's LAN interface must be added to the routers of the intranet.

NetBIOS Gateway

Windows NT 4.0 includes the NetBIOS gateway for remote access clients that use either the NetBEUI protocol with the PPP remote access protocol or the AsyBEUI remote access protocol. With the NetBIOS gateway, a remote access client using NetBEUI can access any NetBIOS-based network resource that is reachable from the remote access server.

With the NetBIOS gateway, the remote access client can access any of the following resources:

Network resources available from the remote access server using NetBEUI.
Network resources available from the remote access server using NetBIOS over TCP/IP.
Network resources available from the remote access server using NetBIOS over IPX.

The NetBIOS gateway component is responsible for:

NetBIOS Name Management

When the initial connection is made, the remote access client passes its NetBIOS name and it is added to the NetBIOS name table at the remote access server.
Passing NetBIOS packets from the remote access client to the LAN.

When the remote access client sends NetBEUI packets across the phone line, those packets are submitted to the NetBIOS gateway and sent over the NetBIOS providing protocol(s).
Passing NetBIOS packets from the LAN to the remote access client.

NetBIOS packets from the LAN, from any of the NetBIOS providing protocols, are inspected for the NetBIOS computer name of the remote access client and sent back to the remote access client using NetBEUI.

Note: The NetBIOS gateway cannot be used to access non-NetBIOS resources, such as Web servers, FTP servers, and other types of Windows Sockets–based resources.

Figure 9 illustrates the NetBIOS gateway architecture of the remote access server.

Figure 9: The NetBIOS Gateway

The Point-to-Point Protocol

The Point-to-Point Protocol (PPP) is an industry standard method of utilizing point-to-point links to transport multi-protocol datagrams. PPP is documented in RFC 1661.

PPP performs the following functions:

Provides multi-protocol data link layer encapsulation

PPP creates frames that contain separate IP datagrams, IPX datagrams, or NetBEUI frames.
Establishes, maintains, and ends the logical link

The PPP protocol uses the Link Control Protocol (LCP) to establish and configure the parameters of the data-link connection. Part of the LCP negotiation authenticating the credentials of the remote access client.
Provides protocol configuration

After the data-link connection has been negotiated, network layer protocols such as IP and IPX are configured. For example, for TCP/IP, an IP address is allocated to the remote access client by the remote access server. Compression and encryption are also negotiated.

PPP Encapsulation

PPP encapsulation uses a variant of the ISO High Level Data Link Control (HDLC) protocol to encapsulate multi-protocol datagrams as the payload of PPP frames. The PPP header and trailer is shown in Figure 10 and contains the following fields:

Flag - Set to 0x7E (bit sequence 011111110) to signify the start and end of a PPP frame. In successive PPP frames only a single Flag character is used.
Address - In HDLC environments, the Address field is used to address the frame to the destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, the broadcast address. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Address field is not included.
Control - In HDLC environments, the Control field is used for data link layer sequencing and acknowledgments. PPP does not provided link-to-link reliable data transfer. Therefore, for all PPP frames, the Control field is set to 0x03 to indicate an unnumbered information (UI) frame. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Control field is not included.
Protocol ID - The two byte Protocol ID field identifies the protocol of the PPP payload. If both PPP peers agree to perform protocol field compression during LCP negotiation, the Protocol ID field is one byte for Protocol IDs in the range 0x00-00 to 0x00-FF.
Frame Check Sequence (FCS) - A 16-bit checksum that is used to check for bit level errors in the PPP frame. If the receiver's calculation of the FCS does not match the FCS in the PPP frame, the PPP frame is silently discarded.

The maximum size of a PPP frame, known as the maximum receive unit (MRU), is determined during the negotiation of the logical link. The default MRU is 1,500 bytes. If negotiated lower, a PPP host must still have the ability to receive 1,500-byte frames in the event of link synchronization failure.

Figure 10: PPP Encapsulation

Figure 10: PPP Encapsulation

Typical values for the PPP protocol ID are listed in Table 2.

Table 2 PPP Protocol IDs

Protocol	Protocol ID/Compressed Value
Internet Protocol (IP)	0x00-21 / 0x21
IPX	0x00-2B / 0x2B
Van Jacobsen Compressed TCP/IP	0x00-2D / 0x2D
Multilink	0x00-3D / 0x3D
NetBEUI	0x00-3F / 0x3F
Microsoft Point-to-Point Compression Protocol (MPPC)	0x00-FD / 0xFD
Microsoft Point-to-Point Encryption Protocol (MPPE)	0x00-FD / 0xFD

If MPPE or MPPC are negotiated, then the PPP protocol ID is set to 0x00-FD. With MPPE and MPPC both using the same PPP Protocol ID, each peer must know that the resulting PPP payload either is encrypted or compressed, or both.

If just MPPC is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is compressed.
If only MPPE is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is encrypted.
If both MPPC and MPPE are negotiated, then compression always occurs before encryption. The compressed PPP frame, consisting of the PPP protocol ID field set to 0xFD and the compressed data, is then encrypted and encapsulated with another PPP header consisting of the protocol ID field set to 0xFD and 2-byte MPPE header.

Preventing the Occurrence of the Flag Character

The use of the Flag character introduces a problem. What if the Flag character (0x7E) appears elsewhere in the PPP frame besides the beginning or end of the PPP frame? PPP employs two different methods to prevent the occurrence of the Flag character depending on whether PPP is being used on an asynchronous link or a synchronous link.

PPP on Asynchronous Links

On asynchronous links, such as analog phone lines, PPP uses a technique called character stuffing to prevent the occurrence of the Flag character within the PPP frame. If the Flag character (0x7E) occurs elsewhere in the PPP frame, the sender replaces it with the sequence 0x7D-5E. The 0x7D character is known as the PPP Escape character. If the PPP Escape character occurs, the sender replaces it with the sequence 0x7D-5D. The receiver translates 0x7D-5E sequences back to 0x7E and 0x7D-5D sequences back to 0x7D.

Additionally, character values less than 0x20 can be modified to prevent the serial drivers from interpreting them as control characters. If negotiated by LCP, characters below 0x20 are modified by sending the sequence: 0x7D-[Original character with the 6th bit complemented]. For example, the byte 0x01 would be transmitted as 0x7D-0x21.

PPP on Synchronous Links

With synchronous links, such as T-Carrier, ISDN, or other digital links, a technique called bit stuffing is used to prevent the occurrence of the FLAG character within the PPP frame. Recall that the Flag character is the bit sequence 01111110. Bit stuffing ensures that six 1 bits in a row occur only when the Flag character is sent. To accomplish this, bit stuffing sends the Flag character unmodified and elsewhere inserts a 0 bit whenever a sequence of five 1 bits occurs. Therefore, the bit sequence 111111 is encoded on the medium as 1111101 and the bit sequence 111110 is encoded as 1111100 (the stuffed bits are underlined). Bit stuffing means that a byte can be encoded on the medium as more than 8 bits, but the stuffed bits are added and removed by the synchronous link hardware.

PPP Link Negotiation with LCP

The PPP Link Control Protocol (LCP) is documented in RFC 1661. LPC negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and Multilink options.

LCP Packet Structure

LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in Figure 11. Each LCP packet is a single LCP message consisting of an LCP Code field identifying the type of LCP packet, an Identification field so that requests and replies can be matched, a Length field indicating the size of the LCP packet and LCP packet type–specific data.

Figure 11: LCP Packet Structure

Figure 11: LCP Packet Structure

Table 3 lists the LCP packet types documented in RFC 1661.

Table 3 LCP Packet Types

LCP Code	LCP Packet Type	Description
1	Configure-Request	Sent to open or reset a PPP connection. The Configure-Request contains a list of LCP options with changes to default option values.
2	Configure-Ack	Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete.
3	Configure-Nack	Sent when all the LCP options are recognized, but the values of some options are not acceptable. The Configure-Nack includes the offending options and their acceptable values.
4	Configure-Reject	Sent when LCP options are not recognized or not acceptable for negotiation. The Configure-Reject includes the unrecognized or non-negotiable options.
5	Terminate-Request	Optionally sent to close the PPP connection.
6	Terminate-Ack	Sent in response to the Terminate-Request.
7	Code-Reject	Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet.
8	Protocol-Reject	Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet. A Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a LAN protocol not enabled on the PPP peer.
9	Echo-Request	Optionally sent to test the PPP connection.
10	Echo-Reply	Sent in response to an Echo-Request. The PPP Echo-Request and Echo-Reply are not related to the ICMP Echo Request and Echo Reply messages.
11	Discard-Request	Optionally sent to exercise the link in the outbound direction.

LCP Options

When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options as illustrated in Figure 12. Each LCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option and the data associated with the option.

Figure 12: LCP Options

Figure 12: LCP Options

Table 4 lists common LCP options negotiated by Microsoft PPP peers. For information about other LCP options, see RFC 1661.

Table 4 LCP Options

Option Name	Option Type	Option Length	Description
Maximum Receive Unit	1	4	The maximum size (up to 65,535) of the PPP frame. The default MRU is 1500. If neither peer is changing the default, this option is not negotiated.
Asynchronous Control Character Map (ACCM)	2	6	A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for the 32 ASCII control characters from 0x00 to 0x20. By default, character escapes are used. The ACCM bit map is set to 0x00-00-00-00 for links with XON/XOFF software flow control.
Authentication Protocol	3	5 or 6	Indicates the authentication protocol used during the authentication phase of the connection. Values for this field for Microsoft PPP peers are 0xC2-23-80 for MS-CHAP version 1, 0xC2-23-81 for MS-CHAP version 2, 0xC2-23-05 for MD5-CHAP, 0xC0-27 for SPAP, and 0xC0-23 for PAP.
Magic Number	5	6	A random number chosen to distinguish a peer and detect looped back lines.
Protocol Compression	7	2	A flag indicating that the PPP protocol ID be compressed to a single octet when the two-byte protocol ID is in the range 0x00-00 to 0x00-FF.
Address and Control Field Compression	8	2	A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) be removed from the PPP header.
Callback	13 or 0x0D	3	A 1-octet indicator of how callback is to be determined. For remote access clients and server running Microsoft® Windows 32-bit operating systems, the callback option octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation.

LCP Negotiation Process

The LCP negotiation is a series of LCP packets exchanged between PPP peers to negotiate a set of options and option values when sending data. The LCP negotiation is actually two separate dialogs between two PPP peers (Peer1 and Peer 2):

Peer 1 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 2. This dialog starts with Peer 1 sending a Configure-Request and ends when Peer 2 sends a Configure-Ack.
Peer 2 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to peer 1. This dialog starts with Peer 2 sending a Configure-Request and ends when Peer 1 sends a Configure-Ack.

Peer 1 and Peer 2 do not have to use the same set of LCP options.

When a PPP peer sends its initial Configure-Request, the response is any of the following:

A Configure-Nack because one or more options have unacceptable values.
A Configure-Reject because one or more of the options are unknown or not negotiable.
A Configure-Ack because all of the options have acceptable values.

When a PPP peer receives a Configure-Nack or Configure-Reject in response to its Configure-Request, it sends a new Configure-Request with modified options or option values. When a Configure-Ack is received, the PPP peer is ready to send data.

Figure 13 shows a hypothetical LCP negotiation process for Peer 1 using the fictional options W, X, Y, Z.

Figure 13: Sample LCP Negotiation

From the LCP messages in Figure 13:

Peer 1 sends a Configure-Request requesting option W, option X set to 100, option Y set to 0, and option Z. Options W and Z are flag options.
Peer 2 does not understand option Z so it sends a Configure-Reject containing option Z.
Peer 1 sends a new Configure-Request packet requesting option W, option X set to 100, and option Y set to 0.
Peer 2 prefers that option X be set to 200 so it sends a Configure-Nack containing option X and its preferred value.
Peer 1 sends a new Configure-Request packet requesting option W, option X set to 200, and option Y set to 0.
Peer 2 sends a Configure-Ack.

Each time Peer 1 sends a new Configure-Request, it changes the Identifier value in the LCP header so that Configure-Requests can be matched with their responses.

The previous process only configures how Peer 1 sends data to Peer 2. A separate LCP negotiation must be done so that Peer 2 can be configured to send data to Peer 1. Very often, the LCP packets for the two dialogs are intermixed during the connection process. Peer 1 is configuring the way it sends data at the same time as Peer 2.

Callback Negotiation with the Callback Control Protocol

CBCP negotiates the use of callback where the remote access server, after authenticating the remote access client, terminates the physical connection, waits a specified amount of time, and then calls the remote access client back at either a static or dynamically configured phone number. Common CBCP options include the phone number being used by the remote access server to call the remote access client back.

Packet Structure

CBCP uses the PPP Protocol ID of 0xC0-29. The packet structure of CBCP is exactly the same for LCP; however, only the Callback-Request (type 1), Callback-Response (type 2), and Callback-Ack (type 3) types are used. For all CBCP packet types, the CBCP data portion of the CBCP packet consists of one or more CBCP options. Each CBCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 5 lists the CBCP options negotiated by Microsoft PPP peers.

Table 5 CBCP Options

Option Name	Option Type	Option Length	Description
No callback	1	2	Specifies that no callback is used for the connection.
Callback to a user-specified number	2	variable	The user of the remote access client computer determines the callback number.
Callback to an administrator-defined number	3	variable	Settings on the remote access server determine the callback number.
Callback to any of a list of numbers	4	variable	The remote access server callbacks to one of a list of phone numbers.

PPP Network Layer Negotiation with NCP

Once the link and PPP parameters have been negotiated with LCP, the PPP peers then use a series of Network Control Protocols (NCPs) to negotiate the parameters of individual LAN protocols. Microsoft PPP supports the following NCPs:

Internet Protocol Control Protocol (IPCP) to negotiate the use of IP.
Internetwork Packet Exchange Control Protocol (IPXCP) to negotiate the use of IPX.
NetBIOS Frames Control Protocol (NBFCP) to negotiate the use of NetBEUI.

IPCP

Internet Protocol Control Protocol (IPCP) as used by Microsoft PPP peers is documented in RFC 1332 and 187 IPCP negotiates IP-based parameters to dynamically configure a TCP/IP-based PPP peer across a point-to-point link. Common IPCP options include an IP address and the IP address(es) of DNS and NetBIOS name servers.

Packet Structure

IPCP uses the PPP Protocol ID of 0x80-21. The packet structure of IPCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPCP packet types, the IPCP data portion of the IPCP packet consists of one or more IPCP options. Each IPCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 6 lists the IPCP options negotiated by Microsoft PPP peers.

Table 6 IPCP Options

Option Name	Option Type	Option Length	Description
IP Compression Protocol	2	4	Van Jacobsen TCP compression protocol.
IP Address	3	6	The IP address to be allocated to the remote access client
Primary DNS Server Address	129 or 0x81	6	The primary DNS server for the remote access client.
Primary NBNS Server Address	130 or 0x82	6	The primary WINS server for the remote access client.
Secondary DNS Server Address	131 or 0x83	6	The secondary DNS server for the remote access client.
Secondary NBNS Server Address	132 or 0x84	6	The secondary WINS server for the remote access client.

Notice that there are no IPCP options for these common TCP/IP configuration items:

Subnet mask

The subnet mask is assumed by the remote access client to be the class-based subnet mask of the IP address that is allocated to the remote access client.
Default gateway

The default gateway IP address is not allocated by the remote access server. However, a default route is created on the remote access client, which points to the remote access connection. If a default route already exists in the routing table, then the metric of the existing default route is increased and a new default route is added with a lower metric. This is the default behavior for remote access clients running Windows 32-bit operating systems and can be modified by disabling the Use Default Gateway on Remote Network setting on the TCP/IP properties of a remote access client's phonebook entry or dial-up connection object.
DNS domain name

The DNS domain name configured from the TCP/IP protocol properties is not allocated during IPCP.
NetBIOS Node Type

If the IP addresses of primary or secondary NetBIOS name servers are negotiated, then the hybrid NetBIOS node type (H-node) is assumed.

IPXCP

Internetwork Packet Exchange Control Protocol (IPXCP) as used by Microsoft PPP peers is documented in RFC 1552. IPXCP negotiates IPX-based parameters to dynamically configure a IPX-based PPP peer across a point-to-point link. Common IPXCP options include IPX network and node addresses.

Packet Structure

IPXCP uses the PPP Protocol ID of 0x80-2B. The packet structure of IPXCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPXCP packet types, the IPXCP data portion of the IPXCP packet consists of one or more IPXCP options. Each IPXCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 7 lists the IPXCP options negotiated by Microsoft PPP peers.

Table 7 IPXCP Options

Option Name	Option Type	Option Length	Description
IPX Network Number	1	6	The IPX network number for the remote access client.
IPX Node Number	2	6	The IPX node number for the remote access client.

NBFCP

NetBIOS Frames Control Protocol (NBFCP) as used by Microsoft PPP peers is documented in RFC 2097. NBFCP negotiates NetBEUI-based parameters to dynamically configure an NetBEUI-based PPP peer across a point-to-point link. Common NBFCP options include multicast filtering options and peer information.

Packet Structure

NBFCP uses the PPP Protocol ID of 0x80-3F. The packet structure of NBFCP is exactly the same for LCP, except that only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject NBFCP packet types, the NBFCP data portion of the NBFCP packet consists of one or more NBFCP options. Each NBFCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 8 lists the NBFCP options negotiated by Microsoft PPP peers.

Table 8 NBFCP Options

Option Name	Option Type	Option Length	Description
Multicast filtering	3	5	Negotiates the handling of multicast packets.
Peer information	2	17	Used to convey NetBIOS configuration information.

Compression Control Protocol

Compression Control Protocol (CCP) is documented in RFC 1962. CCP negotiates parameters to dynamically configure, enable, and disable data compression algorithms between PPP peers across a point-to-point link. Common CCP options include an organization identifier and the use of MPPC.

Packet Structure

CCP uses the PPP Protocol ID of 0x80-FD. The packet structure of CCP is exactly the same for LCP, except only packet types 1–7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject CCP packet types, the CCP data portion of the CCP packet consists of one or more CCP options. Each CCP option consists of an Option Type field, a Length field indicating the total length in bytes of the option, and the data associated with the option.

Negotiated Options

Table 9 lists the CCP options negotiated by Microsoft PPP peers.

Table 9 CCP Options

Option Name	Option Type	Option Length	Description
Organization Unique Identifier	0	6 or larger	Used to negotiate an organization's proprietary compression protocol.
MPPC	18 or 0x12	6	Used to indicate the use of MPPC, MPPE, and the encryption strength.

MPPE and MPPC

With CCP option 18, Microsoft PPP peers negotiate both MPPC and MPPE at the same time. The option data field for CCP option 18 is 4 bytes (32 bits) long. Bits within this data field are used as flags to indicate:

Whether compression is enabled (0x00-00-00-01).
Whether 40-bit session keys are derived from the LAN Manager version of the user's password (0x00-00-00-10).
Whether 40-bit session keys are derived from the Windows NT version of the user's password (0x00-00-02-00).
Whether 128-bit session keys are derived from the Windows NT version of the user's password (0x00-00-00-40).
Whether the encryption keys are refreshed with each PPP frame (0x01-00-00-00).

For multiple choices, the flag values are added together. For example, for compression (0x00-00-00-01) and 128-bit encryption keys (0x00-00-00-40), the resulting 32-bit option data field is set to 0x00-00-00-41.

For more information about MPPE, see the Internet draft, draft-ietf-pppext-mppe-x.txt.

ECP

The Encryption Control Protocol (ECP) is used to negotiate a specific encryption method and is documented in RFC 1968. However, for Microsoft PPP peers, the only encryption that is supported is MPPE and MPPE is negotiated during CCP with the negotiation of MPPC. Therefore, Microsoft PPP peers do not use ECP.

The PPP Connection Process

There are four distinct phases of negotiation of a PPP connection. Each of these four phases must complete successfully before the PPP connection is ready to transfer user data. The four phases of a PPP connection are:

Phase 1: PPP configuration
Phase 2: Authentication
Phase 3: Callback
Phase 4: Protocol configuration

Phase 1: PPP Configuration

PPP configures PPP protocol parameters using LCP (Link Control Protocol). During the initial LCP phase, each peer negotiates communication options that are used to send data and include:

PPP parameters, such as MRU, address and control field compression, and protocol ID compression.
Which authentication protocols are used to authenticate the remote access client. An authentication protocol is selected but not implemented until the authentication phase.
Multilink options.

Phase 2: Authentication

After LCP is complete, the authentication protocol agreed upon by the remote access server and the remote access client is implemented. The nature of this traffic is specific to the PPP authentication protocol. For more details, see "PPP Authentication Protocols" later in this chapter.

Phase 3: Callback

Microsoft's implementation of PPP includes an optional callback phase using the Callback Control Protocol (CBCP) immediately after authentication. In order for a remote access client user to get called back, the dial-in properties of the user account must be enabled for callback and either the remote access client can specify the callback number or the remote access server must specify the callback number.

If a connection is implementing callback, both PPP peers hang up and the remote access server calls the remote access client at the negotiated number.

Phase 4: Protocol Configuration

Once the PPP is configured and callback is complete (optional), network layer protocols can be configured. With remote access on Windows 32-bit operating systems, the remote access server sends the remote access client Configuration-Request packets for all of the LAN protocols enabled for remote access on the remote access server. The remote access client either continues the negotiation of the LAN protocols enabled at the remote access client or sends an LCP Protocol-Reject message containing the Configuration-Request message.

IPCP, IPXCP, ATCP, and NBFCP each go through a negotiation process very similar to LCP negotiation to configure their corresponding network layer protocol. CCP packets are exchanged to configure MPPC and MPPE.

A Sample PPP Connection

To actually see the PPP connection establishment process in Windows NT 4.0, there are two tools available:

Network Monitor, a packet capture and analysis tool, is used to capture all PPP packets sent over a serial link including connection establishment and PPP-encapsulated user data.
PPP tracing is used to create a log of the PPP packets exchanged during the PPP connection establishment process.

Network Monitor

To capture PPP packets with Network Monitor, set the capture network to the network 000000000000 and begin capturing PPP frames as desired. Network Monitor can capture any PPP frames. You can use Network Monitor to:

Troubleshoot the PPP connection establishment process.
Ensure that PPP payloads are being encrypted.
Ensure that PPP payloads are being compressed.

Note: If compression or encryption is being used, then the PPP payload is not interpreted by Network Monitor. Compressed or encrypted payloads are indicated with the PPP protocol ID of 3D (assuming protocol ID compression). To see the structure of user data within PPP payloads, disable compression and/or encryption.

When using Network Monitor, keep the following in mind:

Captured PPP frames do not contain a Flag character but do contain an Ethernet-like source address and destination address. This behavior is due to the fact that Network Monitor receives the packets from the Ndiswan.sys driver. Recall that Ndiswan.sys is an intermediate NDIS driver that looks like an Ethernet adapter to protocols.

For each PPP frame, the Ethernet-like source and destination address are both set to either SEND or RECV to indicate that the PPP frame was either sent or received by the computer on which the capture was taken. The SEND and RECV addresses do not necessarily identify the traffic of a remote access server or remote access client. If the capture was taken on the remote access server, then SEND frames were sent by the remote access server and RECV frames were sent by the remote access client. If the capture was taken on the remote access client, then SEND frames were sent by the remote access client and RECV frames were sent by the remote access server.
Captured PPP frames contain an Address or Control field regardless of whether address and control field compression are negotiated.
Protocol ID compression is usually negotiated with Microsoft PPP peers, making the PPP Protocol ID a single byte when possible.
Use Network Monitor display filtering to view only the traffic of desired protocols. For example, to view only the IPCP negotiation, set the display filters to disable the display of all protocols except IPCP.

The below printout is an example of a PPP connection establishment process captured with Network Monitor showing only the frame summaries. The entries are indented to improve readability.

1       8.726   SEND         SEND         LCP       
                    Config Req Packet, Ident = 0x00, Length = 36
2       8.796   RECV         RECV         LCP       
                    Config Req Packet, Ident = 0x00, Length = 25
3       8.796   SEND         SEND         LCP       
                    Config Ack Packet, Ident = 0x00, Length = 25
4       8.816   RECV         RECV         LCP       
                    Config Reject Packet, Ident = 0x00, Length = 17
5       8.816   SEND         SEND         LCP       
                    Config Req Packet, Ident = 0x01, Length = 23
6       8.886   RECV         RECV         LCP       
                    Config Ack Packet, Ident = 0x01, Length = 23
7       8.886   SEND         SEND         LCP       
                    Ident Packet, Ident = 0x02, Length = 18
8       8.886   SEND         SEND         LCP       
                    Ident Packet, Ident = 0x03, Length = 23
9       8.886   RECV         RECV         PPPCHAP   
                    Challenge, ID = 0x 1: Challenge
10      8.886   SEND         SEND         PPPCHAP   
                    Challenge, ID = 0x 1: Response, administrator
11      8.976   RECV         RECV         PPPCHAP   
                    Challenge, ID = 0x 1: Success
12      8.976   RECV         RECV         CBCP      
                    Callback Request, Ident = 0x01
13      8.976   SEND         SEND         CBCP      
                    Callback Response, Ident = 0x01
14      8.996   RECV         RECV         CBCP      
                    Callback Acknowledgement, Ident = 0x01
15      8.996   SEND         SEND         CCP       
                    Configuration Request, Ident = 0x04
16      8.997   SEND         SEND         IPCP      
                    Configuration Request, Ident = 0x05
17      8.997   RECV         RECV         CCP       
                    Configuration Request, Ident = 0x01
18      9.017   RECV         RECV         IPCP      
                    Configuration Request, Ident = 0x02
19      9.037   RECV         RECV         IPXCP     
                    Configuration Request, Ident = 0x03
20      9.037   RECV         RECV         NBFCP     
                    Configuration Request, Ident = 0x04
21      9.117   SEND         SEND         IPXCP     
                    Configuration Request, Ident = 0x06
22      9.147   SEND         SEND         CCP       
                    Configuration Acknowledgement, Ident = 0x01
23      9.147   SEND         SEND         IPCP      
                    Configuration Acknowledgement, Ident = 0x02
24      9.167   SEND         SEND         IPXCP     
                    Configuration Acknowledgement, Ident = 0x03
25      9.167   SEND         SEND         LCP       
                    Protocol Reject Packet, Ident = 0x07, Length = 32
26      9.237   RECV         RECV         CCP       
                    Configuration Reject, Ident = 0x04
27      9.237   RECV         RECV         IPCP      
                    Configuration Reject, Ident = 0x05
28      9.237   SEND         SEND         IPCP      
                    Configuration Request, Ident = 0x08
29      9.257   RECV         RECV         IPXCP     
                    Configuration No Acknowledgement, Ident = 0x06
30      9.257   SEND         SEND         IPXCP     
                    Configuration Request, Ident = 0x09
31      9.287   RECV         RECV         IPCP      
                    Configuration No Acknowledgement, Ident = 0x08
32      9.287   SEND         SEND         IPCP      
                    Configuration Request, Ident = 0x0A
33      9.287   RECV         RECV         IPXCP     
                    Configuration Acknowledgement, Ident = 0x09
34      9.327   RECV         RECV         IPCP      
                    Configuration Acknowledgement, Ident = 0x0A
35      10.729  SEND         SEND         CCP       
                    Configuration Request, Ident = 0x04
36      10.960  RECV         RECV         CCP       
                    Configuration Reject, Ident = 0x04
37      10.960  SEND         SEND         CCP       
                    Configuration Request, Ident = 0x0B
38      10.960  RECV         RECV         CCP       
                    Configuration Acknowledgement, Ident = 0x0B

The trace was captured on the remote access client. Therefore, the SEND frames were sent from the remote access client and the RECV frames were sent from the remote access server. In this trace, you can see the four phases of the PPP connection establishment:

Phase 1: PPP configuration is done in frames 1–8 through the exchange of LCP configuration packets.

Phase 2: Authentication is done in frames 9–11 where the user's credentials are verified.

Phase 3: Callback is done in frames 12–14.

Phase 4: Protocol configuration is done in frames 15–38 where compression, encryption, IP, and IPX is configured.

In addition to the summary view, Network Monitor can also expand frames for detailed analysis. For example, frame 1 from this trace is displayed as:

  FRAME: Base frame properties
  FRAME: Time of capture = Nov 18, 1998 15:23:6.967
  FRAME: Time delta from previous physical frame: 0 milliseconds
  FRAME: Frame number: 1
  FRAME: Total frame length: 50 bytes
  FRAME: Capture frame length: 50 bytes
  FRAME: Frame data: Number of data bytes remaining = 50 (0x0032)
  PPP: Link Control Protocol Frame (0xC021)
  PPP: Destination Address =  SEND_
  PPP: Source Address =  SEND_
  PPP: Protocol = Link Control Protocol
  LCP: Config Req Packet, Ident = 0x00, Length = 36
  LCP: Code = Configuration Request
  LCP: Identifier = 0 (0x0)
  LCP: Length = 36 (0x24)
  LCP: Options: ASYNC.MAP:00 00 00 00-MAGIC#:0x0C05-PROT.COMP-
  ADR/CF.COMP-CALL.BACK:Unkn---
  LCP: ASYNC.MAP:00 00 00 00
  LCP: Option Type = Async Control Character Map
  LCP: Option Length = 6 (0x6)
  LCP: Async Control Character Map = 00 00 00 00
  LCP: MAGIC#:0x0C05
  LCP: Option Type = Majic Number
  LCP: Option Length = 6 (0x6)
  LCP: Magic Number = 3077 (0xC05)
  LCP: PROT.COMP
  LCP: Option Type = Protocol Field Compression
  LCP: Option Length = 2 (0x2)
  LCP: ADR/CF.COMP
  LCP: Option Type = Address and Control Field Compression
  LCP: Option Length = 2 (0x2)
  LCP: CALL.BACK:Unkn
  LCP: Option Type = Calback
  LCP: Option Length = 3 (0x3)
  LCP: CallBack = 0x06
  LCP: Multilink Maximum Receive Reconstructed Unit
  LCP: Option Type = 0x11
  LCP: Option Length = 4 (0x4)
  LCP: Multilink Endpoint Discriminator
  LCP: Option Type = 0x13
  LCP: Option Length = 9 (0x9)

Network Monitor captures can also be saved as files and sent to Microsoft PSS engineers for analysis.

PPP log for Windows NT 4.0 Remote Access Service

For the Windows NT 4.0 Remote Access Service, the PPP log records programming code and network events to the file <SystemRoot>\tracing\Ppp.log. PPP logging is enabled by setting the value of the Logging registry entry (in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Rasman \PPP) to 1.

PPP Tracing for RRAS

Tracing is a facility of Windows NT 4.0 RRAS remote access and routing components that allow you to optionally enable and disable the recording of programming code and network events to either a console window or to a file on the disk.

To enable PPP tracing, change the value of the EnableFileTracing registry entry (in HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Tracing \PPP) to 1. The file Ppp.log is created in the <SystemRoot>\tracing folder.

Example of a PPP log or trace

The PPP log or PPP trace contains information on the PPP connection establishment process. The PPP logs generated by PPP tracing contain the programming calls and actual packet contents of PPP packets for PPP control protocols. PPP tracing cannot be used to view PPP user data sent across the connection.

The following printout is an excerpt from a PPP trace of a PPP connection establishment process. The entries are indented to improve readability.

[1472] 15:57:50:094: Line up event occurred on port 5
[1472] 15:57:50:104: Starting PPP on link with IfType=0x0,IPIf=0x0, 
IPXIf=0x0
[1472] 15:57:50:104: RasGetBuffer returned ae70054 for SendBuf
[1472] 15:57:50:104: FsmInit called for protocol = c021, port = 5
[1472] 15:57:50:104: ConfigInfo = 273e
[1472] 15:57:50:104: APs available = 1
[1472] 15:57:50:104: FsmReset called for protocol = c021, port = 5
[1472] 15:57:50:104: Inserting port in bucket # 5
[1472] 15:57:50:104: Inserting bundle in bucket # 6
[1472] 15:57:50:104: FsmOpen event received for protocol c021 on port 5
[1472] 15:57:50:104: FsmThisLayerStarted called for protocol = c021, 
port = 5
[1472] 15:57:50:104: FsmUp event received for protocol c021 on port 5
[1472] 15:57:50:104: <PPP packet sent at 11/04/1998 23:57:50:104
[1472] 15:57:50:104: <Protocol = LCP, Type = Configure-Req, Length = 
0x2f, Id = 0x0, Port = 5
[1472] 15:57:50:104: <C0 21 01 00 00 2D 02 06 00 00 00 00 03 05 C2 23 
|.!...-.........#|
[1472] 15:57:50:104: <80 05 06 72 5F 50 9A 07 02 08 02 0D 03 06 11 04 
|...r_P..........|
[1472] 15:57:50:104: <06 4E 13 09 03 00 60 08 3E 46 07 17 04 00 03 00 
|.N....`.>F......|
[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=c021, 
EventType=0,fAuth=0
[1472] 15:57:50:104: InsertInTimerQ called portid=6,Id=0,Protocol=0,
EventType=3,fAuth=0
[1472] 15:57:50:104: >PPP packet received at 11/04/1998 23:57:50:104
[1472] 15:57:50:104: >Protocol = LCP, Type = Configure-Req, Length = 
0x26, Id = 0x0, Port = 5
[1472] 15:57:50:104: >C0 21 01 00 00 24 02 06 00 00 00 00 05 06 00 00 
|.!...$..........|
[1472] 15:57:50:104: >C0 05 07 02 08 02 0D 03 06 11 04 06 4E 13 09 03 
|._..........N...|
[1472] 15:57:50:104: >00 60 08 52 F9 D8 00 00 00 00 00 00 00 00 00 00 
|.`.R............|

The last three lines of this trace excerpt is a hexadecimal display of the same LCP packet as frame 1 of the previous Network Monitor trace. To understand this frame, you must manually parse this frame according to the PPP and LCP packet structure. An example of the parsing of this PPP frame is listed in Table 10.

Table 10 Parsing of the LCP Configuration-Request

Bytes	Meaning
C0 21	PPP Protocol ID for LCP.
01	LCP Code for a Configure-Request.
00	LCP Identifier for this Configure-Request.
00 24	Length in bytes of the LCP packet (36 bytes long).
02	LCP option for Asynchronous Control Character Map (ACCM).
06	Length in bytes of the ACCM option.
00 00 00 00	Data for the ACCM option.
05	LCP option for the magic number.
06	Length in bytes of the magic number option.
00 00 C0 05	Data for the magic number option.
07	LCP option for protocol compression.
02	Length in bytes of the protocol compression option.
08	LCP option for address and control field compression.
02	Length in bytes of the address and control field compression option.
0D	LCP option for callback.
03	Length in bytes of the callback option.
06	Callback option data.
11	LCP option for the Multilink Maximum Receive Reconstructed Unit. Multilink LCP options are discussed in the "Multilink and Bandwidth Allocation Protocol" section of this chapter.
04	Length in bytes of the Multilink Maximum Receive Reconstructed Unit option.
06 4E	Multilink Maximum Receive Reconstructed Unit option data.
13	LCP option for the Multilink Endpoint Discriminator option.
09	Length in bytes of the Multilink Endpoint Discriminator option.
03 00 60 08 52 F9 D8	Multilink Endpoint Discriminator option data.

As you can see, Network Monitor is the easier tool for the interpretation of PPP traffic. However, the PPP trace contains valuable internal component interaction information that can be useful to troubleshoot connection problems and behavior. When in doubt, obtain both a Network Monitor capture and a PPP trace.

PPP Connection Termination

PPP can terminate the link at any time. Termination generally occurs due to carrier loss, authentication failure, link quality failure, time-out, or link closure by the dial-up client or system administrator. When the link is closing, PPP informs the network layer protocols so that they can take appropriate action.

PPP Authentication Protocols

Phase 2 of the PPP connection establishment process is the authentication of the remote access client. Authentication for PPP is accomplished through a PPP authentication protocol. During phase 1, both PPP peers agree on a single, specific PPP authentication protocol.

Windows NT 4.0 remote access supports Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP).

A secure authentication scheme provides protection against replay attacks, remote access client impersonation, remote access server impersonation.

A replay attack occurs when a person captures the packets of a successful connection attempt and then replays those packets in an attempt to obtain an authenticated connection.
Remote access client impersonation occurs when a person takes over an existing authenticated connection. The intruder waits until the connection is authenticated and then obtains the connection parameters, disconnects the user, and takes control of the authenticated connection.
Remote server impersonation occurs when a computer appears to the remote access client, as the remote access server. The impersonator appears to verify the remote access client credentials and then captures all of the traffic from the remote access client.

PAP

Password Authentication Protocol (PAP) is a simple, clear text authentication scheme. The user name and password are requested by the remote access server and returned by the remote access client in clear text. PAP, however, is not a secure authentication protocol. A person capturing the PAP packets between the remote access server and remote access client can easily determine the remote access client's password. PAP offers no protection against replay attacks, remote client impersonation, or remote server impersonation.

The use of PAP is negotiated during LCP negotiation by specifying the Authentication Protocol LCP option (type 3) and the authentication protocol 0xC0-23. Once LCP negotiation is complete, PAP messages use the PPP protocol ID of 0xC0-23.

PAP is a simple exchange of messages:

The remote access client sends a PAP Authenticate-Request message to the remote access server containing the remote access client's user name and clear text password.
The remote access server checks the user name and password and sends back either a PAP Authenticate-Ack message when the user's credentials are correct, or a PAP Authenticate-Nak message when the user's credentials are not correct.

PAP is included in Windows NT 4.0 so that remote access clients running Windows 32-bit operating systems can connect to older remote access servers that do not support a secure authentication protocol, and remote access clients not running a Microsoft operating systems that do not support a secure remote access protocol can connect to a remote access server running Windows 32-bit operating systems.

Note: To make your remote access server more secure, ensure that PAP is disabled. However, older remote access clients not running a Microsoft operating systems that do not support secure authentication protocols are unable to connect.

SPAP

The Shiva Password Authentication Protocol (SPAP) is a two-way, reversible encryption mechanism employed by Shiva remote access servers. A Windows NT 4.0 remote access client can use SPAP to authenticate itself to a Shiva remote access server. A remote access client running Windows 32-bit operating systems can use SPAP to authenticate itself to a Windows NT 4.0 remote access server. SPAP is more secure than PAP but less secure than CHAP or MS-CHAP. SPAP offers no protection against remote server impersonation.

The use of SPAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC0-27. Once LCP negotiation is complete, SPAP messages use the PPP protocol ID of 0xC0-27.

Like PAP, SPAP is a simple exchange of messages:

The remote access client sends an SPAP Authenticate-Request message to the remote access server containing the remote access client's user name and encrypted password.
The remote access server decrypts the password, checks the user name and password, and sends back either an SPAP Authenticate-Ack message when the user's credentials are correct, or an SPAP Authenticate-Nak message with a reason why the user's credentials were not correct.

CHAP

The Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol documented in RFC 1994 that uses the industry-standard Message Digest 5 (MD5) one-way encryption scheme to hash the response to a challenge issued by the remote access server.

CHAP is used by various vendors of dial-in servers and clients. CHAP is supported by both the Windows NT 4.0 remote access server and remote access client.

CHAP is an improvement over PAP and SHAP in that the password is never sent over the link. Instead, the password is used to create a one-way hash from a challenge string. The server, knowing the client's password, can duplicate the operation and compare the result with that sent in the client's response.

The use of CHAP is negotiated during phase 1 by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x05. Once LCP negotiation is complete, CHAP messages use the PPP Protocol ID of 0xC2-23.

CHAP authentication is an exchange of three messages:

The remote access server sends a CHAP Challenge message containing a session ID and an arbitrary challenge string.
The remote access client returns a CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the client's password using the MD5 one-way hashing algorithm.
The remote access server duplicates the hash and compares it to the hash in the CHAP Response. If the hashes are the same, the remote access server sends back a CHAP Success message. If the hashes are different, a CHAP Failure message is sent.

CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt. However, CHAP does not protect against remote server impersonation.

MS-CHAP v1

The Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 (MS-CHAP v1) is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the remote access server sends a challenge to the remote client that consists of a session ID and an arbitrary challenge string. The remote client must return the user name and an MD4 hash of the challenge string, the session ID, and the MD4-hashed password.

One difference between CHAP and MS-CHAP v1 is that, in CHAP, the clear-text version of the password must be available to validate the challenge response. With MS-CHAP v1, the remote access server only requires the MD4 hash of the password to validate the challenge response.

MS-CHAP v1 authentication is an exchange of three messages:

The remote access server sends an MS-CHAP Challenge message containing a session ID and an arbitrary challenge string.
The remote access client returns an MS-CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the MD4 hash of the client's password using the MD4 one-way hashing algorithm.
The remote access server duplicates the hash and compares it to the hash in the MS-CHAP Response. If the hashes are the same, the remote access server sends back a CHAP Success message. If the hashes are different, a CHAP Failure message is sent.

The use of MS-CHAP v1 is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x80. Once LCP negotiation is complete, MS-CHAP v1 messages use the PPP protocol ID of 0xC2-23.

MS-CHAP v1 also allows for error codes including a "password expired" code and password changes. MS-CHAP v1 protects against replay attacks by using an arbitrary challenge string per authentication attempt. MS-CHAP v1 does not provide protection against remote server impersonation.

If MS-CHAP v1 is used as the authentication protocol and MPPE is negotiated, then shared secret encryption keys are generated by each PPP peer.

MS-CHAP v2

Windows NT 4.0 service pack 4 and above, Windows 98 with with the Windows 98 Service Pack 1 and above includes support for MS-CHAP version 2 (MS-CHAP v2) that provides stronger security for remote access connections. MS-CHAP v2 offers the additional security features:

LAN Manager encoding of responses and password changes is no longer supported.
Two-way authentication verifies the identity of both sides of the connection. The remote access client authenticates against the remote access server and the remote access server authenticates against the remote access client. Two-way authentication, also known as mutual authentication, ensures that the remote access client is dialing into a remote access server that has access to the user's password. Mutual authentication provides protection against remote server impersonation.
Separate cryptographic keys are generated for transmitted and received data.
The cryptographic keys are based on the user's password and the arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used.

The use of MS-CHAP v2 is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x81. Once LCP negotiation is complete, MS-CHAP messages use the PPP protocol ID of 0xC2-23.

MS-CHAP v2 authentication is an exchange of three messages:

The remote access server sends an MS-CHAP v2 Challenge message to the remote access client that consists of a session identifier and an arbitrary challenge string.

The remote access client sends an MS-CHAP v2 Response message that contains:
- The user name.
- An arbitrary peer challenge string.
- An MD4 hash of the received challenge string, the peer challenge string, the session identifier, and the MD4 hashed version of the user's password.
The remote access server checks the MS-CHAP v2 Response message from the client and sends back an MS-CHAP v2 Response message containing:
- An indication of the success or failure of the connection attempt.
- An authenticated response based on the sent challenge string, the peer challenge string, the client's encrypted response, and the user's password.
The remote access client verifies the authentication response and if it is correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.

Remote Access and LAN Protocols

The following sections describe how the Windows NT 4.0 remote access server allocates network configuration parameters for TCP/IP and IPX-based remote access clients.

TCP/IP

To configure a TCP/IP-based remote access client with IPCP, the remote access server allocates an IP address and assigns the IP addresses of DNS and WINS servers (a primary and a backup).

IP Address Allocation

To allocate an IP address to a remote access client, the remote access server is either configured to use Dynamic Host Configuration Protocol (DHCP) to obtain IP addresses, or with a static IP address pool.

Static IP Address Pools

When a static IP address pool is configured, the remote access server uses the first IP address in the range for the RAS server interface, and subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. IP addresses freed due to remote access clients disconnecting are reused.

If the static IP address pool is an off-subnet address pool, either enable an appropriate routing protocol on the remote access server or add a static route corresponding to the IP address pool to the routers of your intranet. For more information, see "TCP/IP On-Subnet and Off-Subnet Addressing" earlier in this chapter.

DNS and WINS Address Assignment

As part of the IPCP negotiation, the remote access server assigns the IP addresses of DNS and WINS servers configured on the remote access server to remote access clients.

IPX

To configure an IPX-based remote access client with IPXCP, the remote access server allocates an IPX network number and an IPX node number. The network number allocation behavior is configured from the Network Configuration dialog box from the properties of the Remote Access Service. The main elements of IPX configuration are:

IPX network numbers for remote access clients can be automatically allocated or specified as a range by the network administrator. For automatically allocated IPX network numbers, the remote access server ensures that the IPX network number is not being used on the IPX internetwork by sending a RIP GetLocalTarget packet on its LAN interfaces. If there is a response to the RIP GetLocalTarget, then the IPX network number is in use and another IPX network number is chosen.
The same IPX network number can be assigned to all remote access clients.
Specific IPX node numbers can be requested by remote access clients.

Multilink

The Multilink PPP (MP) protocol is defined in RFC 1990 and used to aggregate multiple physical links into a single logical link. A good example is the aggregation of both B-channels of an ISDN Basic Rate Interface (BRI) connection. MP fragments, sequences, and re-orders alternating packets sent across multiple physical connections so that the end result is a single logical link with the combined bandwidth of all of the aggregated physical links. MP is the recommended method of combining multiple B-channels of a BRI connection because the support for bonding — the combining of ISDN B-channels through hardware support — can be specific to the ISDN adapter. MP can be done for any ISDN adapter. MP must be supported on both sides of the connection.

Figure 14 illustrates the structure of an MP frame. The payload of a Multilink PPP packet is either a fragment of a PPP frame or the entire PPP frame. Multilink PPP fragmentation need not occur if the Multilink PPP packet fits within the MRU of the link. To prevent misordering of the datagrams or fragments across multiple links, additional fields are used between the PPP Protocol field and the IP datagram. Multilink PPP uses the PPP Protocol ID of 0x00-3D.

Figure 14: Multilink PPP

RFC 1990 defines two different packet formats for short sequence numbers and long sequence numbers. When using either short or long sequence numbers, the sequence number is used to prevent misordering of frames that are sent across multiple links, not to sequence fragments.

For short sequence numbers, a two byte Delimitation/Sequence # field consists of four bits used for delimitation and 12 bits used for the sequence number. Within the delimitation field are two flags. The first bit (the Beginning bit) is an indicator that this fragment begins a sequence of fragments corresponding to a packet. The second bit (the Ending bit) is an indicator that this fragment ends a sequence of fragments corresponding to a packet. The other bits in the first four bits of the short sequence number header are set to 0.

For a PPP frame that is sent without fragmentation, both the Beginning and Ending bits are set. For a PPP frame that is larger than the MRU of the physical link, the PPP frame is fragmented, and each fragment is sent as a separate PPP packet. MP performs a Data Link layer fragmentation that is not related to IP fragmentation.

For long sequence numbers, a four byte Delimitation/Sequence # field consists of eight bits (one byte) used for delimitation, and 24 bits (3 bytes) used for the sequence number. Within the delimitation field, the same bits as the short sequence number header define the Beginning bit and the Ending bit. The other bits in the first byte of the long sequence number header are set to 0. The long sequence number header is used by default, unless the short sequence number is chosen during LCP negotiation.

Table 11 lists Multilink PPP LCP options negotiated by Microsoft PPP peers. For information about other Multilink PPP options, see RFC 1990.

Table 11 Multilink LCP Options

Option Name	Option Type	Option Length	Description
Multilink Maximum Receive Reconstructed Unit	17 or 0x11	4	Specifies the number of octets that a peer can reconstruct when performing reassembly of fragmented MP frames.
Short Sequence Number Header Format	18 or 0x12	2	Specifies the use of the short sequence number in the MP header.
Multilink Endpoint Discriminator	19 or 0x13	9	A unique system identifier to differentiate links from two PPP peers with the same authenticated name.

Troubleshooting the Remote Access Server

Troubleshooting remote access is a combination of troubleshooting IP connectivity, addressing, routing, and dial-up hardware. A firm understanding of all of these topics is required. The following sections outline common remote access problems and the troubleshooting tools provided with Windows NT 4.0.

To troubleshoot VPN connections, see "Virtual Private Networks".

Common Remote Access Problems

Remote access problems typically include the following:

Connection attempt is rejected when it should be accepted.
Connection attempt is accepted when it should be rejected.
Unable to reach locations beyond the remote access server.
Miscellaneous remote access problems.

The following sections give troubleshooting tips to isolate the configuration or infrastructure problem causing the remote access problem.

Connection Attempt Is Rejected When It Should Be Accepted

Verify that the Remote Access Service or the Routing and Remote Access Service is running on the remote access server.
Verify that the ports on the remote access server are configured to receive calls.
Verify that all of the ports on the remote access server are not already connected.
Verify that the remote access client and the remote access server have common authentication settings.
Verify that the remote access client and the remote access server have common encryption settings.
Verify that the LAN protocol(s) being used by the remote access clients is enabled for remote access.
Verify that the remote access client's credentials consisting of user name, password, and domain name are correct and can be validated by the remote access server.
Verify that the user account corresponding to the user credentials of the remote access client has been granted dialin permission.
If the remote access server is configured to use DHCP to allocate IP addresses to remote access clients, verify that a DHCP server is available.
If the remote access 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 remote access clients, then the remote access server is unable to allocate an IP address. If the remote access client is only configured to use TCP/IP as a LAN protocol, the connection attempt is denied.
If the remote access client is configured to request its own IPX node number, verify that the server is configured to allow IPX clients to request their own IPX node number.
If the remote access server is configured with a range of IPX network numbers, verify that the IPX network numbers in the range are not being used elsewhere on your IPX internetwork.
Verify the configuration of the authentication provider.

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

Connection Attempt Is Accepted When It Should Be Rejected

Verify that the parameters of the connection does not have permission through remote access policies.

In order for the connection to be rejected, the parameters of the connection attempt must be denied remote access permission either through the remote access permission of the user account (set to Deny access) or the user account is set to Control access through Remote Access Policy and the remote access permission of the first remote access policy that matches the parameters of the connection attempt is set to Deny remote access permission.

Unable to Reach Locations Beyond the Remote Access Server

Verify that the LAN protocols being used by the remote access clients are enabled to allow access to the network to which the remote access server is attached.
Verify the IP address allocation settings of the remote access server. If the remote access 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, then an IP route consisting of the remote access server static IP address pool, as defined by the IP address and subnet mask of the range, must be added to the routers of the intranet. If the route is not added, then remote access clients do not receive traffic from locations on the intranet. A route for the network can be implemented through static routing entries, or through a routing protocol, such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF).

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 remote access 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 through static configuration or through DHCP.

Miscellaneous Remote Access Problems

Multilink Is Not Working

Verify that Multilink is enabled on the properties of the Remote Access Service or the Routing and Remote Access Service..

Troubleshooting Tools

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

Network Monitor

Network Monitor is a packet capture and analysis tool that you can use to view the traffic sent between a remote access server and remote access client during the remote access connection process and during data transfer. Network Monitor does not interpret the compressed or encrypted portions of remote access traffic.

The proper interpretation of the remote access traffic with Network Monitor requires an understanding of PPP protocols described in this chapter and the referenced RFCs. Network Monitor captures can be saved as files and sent to Microsoft Product Support Services (PSS) 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.

Windows NT 4.0: Remote Access Server

On This Page

Remote Access Overview

Remote Access Versus Remote Control

Remote Access Server Architecture

The Point-to-Point Protocol

PPP Authentication Protocols

Remote Access and LAN Protocols

Multilink

Troubleshooting the Remote Access Server

Additional resources