Remote access components and problem isolation

This section familiarizes you with the important components involved in a typical remote access connection. It begins with a brief conceptual overview of the component. A configuration checklist follows this overview for most components. You can use the items in this checklist to ensure that the component is configured correctly. This section also describes how you can isolate a specific component from the configuration by replacing it with another component capable of achieving a similar function. This process serves to identify the excluded component as the problem component.

On This Page

Client configuration Dial-up connections VPN connections Remote Access Server DHCP Relay Agent Authenticating Server

Client configuration

User name and password

A remote access client typically requires a valid user name and password to attempt a connection to a remote access server. However, as a result of a remote access connection attempt using user name and password credentials, the client does not actually log on to the network. Credentials used for remote access only provide a connection to the network of the remote access server. Each time the client attempts to access a network resource, it will be challenged for credentials, such as the user name and password. If it does not respond to the challenge with acceptable credentials, the access attempt will fail.

Phone number, IP address, and domain name

In dial-up connections, you can specify the phone numbers that are used to make a remote access connection. Additionally, you can configure the phone number details with country code, area code, and established dialing rules. Dialing rules help accomplish tasks, such as setting up an automatic process that dials phone numbers in sequence until you find a modem that answers.

You can also configure the connection to use multiple phone numbers using the Alternate Phone Numbers option in the remote access connection properties dialog box.

In a VPN connection, the host name or IP address specifies the name of the destination server to which the client will be connecting. The host name is resolved to the IP address of the VPN server using the Internet Domain Name System (DNS) at the time of connection.

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify the phone number, area code, and country code used for the connection are correct.

  • If these are correct, then make sure that the host name of the VPN server is entered correctly.

  • If necessary, verify you have selected to prompt for name and password in your dialing options so that you can verify the connection credentials during the connection attempt.

  • To see if the problem area is in the DNS server, first ping and verify the VPN server name can be resolved. Even if ping displays "Request timed out", it will display the server name.

Component replacement and isolation Try the following tasks to remove this component from the configuration for purposes of troubleshooting:

  • Use a regular phone and call the phone number that you are trying to reach to verify the phone service is functioning properly. If not, then either the number you are calling is incorrect or the modem on the other side is not responding properly.

  • If possible, use a different phone number. If the connection is established successfully, then it was the phone number in your configuration that needed to be fixed.

  • If your VPN connection is using a host name for the VPN server and the DNS server is not working, try the connection using the VPN server's IP address. If that works, verify that you are using the correct name.

  • Use the credentials for a different user account. If the connection is successful, then the user name and password that you were using are not correct.

Authentication and encryption settings

Default settings for dial-up connections allow for insecure passwords and connections to be established without data encryption. You can choose to require secure authentication with the use of smart cards or authentication protocols like, Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), EAP-MD5 CHAP, and EAP-TLS.

Encrypted PPTP connections require you to use MS-CHAP, MS-CHAP v2, or EAP-TLS authentication protocols. You can use any authentication method for L2TP connections, however, MS-CHAP v2 and EAP-TLS are recommended.

Password authentication can be based on whether the password can be encrypted. It is advisable to use an encrypted password unless the remote access server prohibits the use of encrypted passwords. There are some ISPs that do not allow the use of encrypted passwords.

Encryption is typically essential for VPN connections and optional for dial-up connections. In PPP and PPTP, encryption depends on the authentication protocols uses. In L2TP, encryption is independent of the authentication protocol.

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify the remote access client and the remote access server are using at least one common authentication and encryption strength. Authentication protocols for the remote access server are enabled on the Security tab on the properties of the remote access server in the Routing and Remote Access snap-in. Authentication protocols and encryption strengths for allowed connections are configured using the profile properties of the matching remote access policy. It is recommended to change the authentication and encryption settings by configuring the remote access policy as compared to changing settings on the Security tab on the properties of the remote access server in the Routing and Remote Access snap-in.

  • The remote access server is responsible for negotiating the legacy authentication protocols with the remote access clients. The remote access policy then takes the result of this negotiation and decides whether to accept the connection request. By default, the remote access server is ready to negotiate both EAP and any legacy authentication protocol except CHAP. Because it requires a special reversibly encrypted database in the domain controller or in the local account database, CHAP is disabled by default.

Component replacement and isolation Try the following tasks to remove this component from the configuration for purposes of troubleshooting:

  • Enable a common encryption strength (shared by the client and the server) and try the connection attempt again. If the attempt is accepted, it means that the remote access client and the remote access server were not using a common encryption method.

  • Enable a common authentication method and try the connection attempt again. If the attempt is accepted, it means that the remote access client and the remote access server were not using a common authentication method.

  • Reconfigure the connection so that the server and the client do not require encryption for a successful connection. Try the connection again. If the connection is successful, then the encryption strengths being used were causing the connection to fail. Reconfigure your encryption settings. This will work only if you have administrative privileges for both client and server.

  • Enable all authentication methods and encryption strengths on both the client and the server and then verify the connection works.

Type of server

In dial-up connections for Windows 2000 remote access clients, the type of server can be PPP: Windows 95/98/NT 4/2000, Internet server or a SLIP: Unix connection server. Most dial-up access servers now support PPP, with very few requiring SLIP. Windows 2000 servers support only the PPP protocol; they do not support SLIP. For VPN connections using Windows 2000 remote access clients, you can select the type of VPN server you are calling. This could be a PPTP server or an L2TP server.

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify you are using the appropriate tunneling protocol based on the type of VPN server you are trying to call. This is set to Automatic by default.

Component replacement and isolation Try the following task to remove this component from the configuration for purposes of troubleshooting:

  • For VPN connections, configure the client for PPTP or L2TP instead of automatic. For example, for Windows 2000 VPN clients, choose Point to Point Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) instead of Automatic in Type of VPN server I am calling. You will find these settings on the Networking tab of the properties of the VPN connection.

Dial-up connections

The properties of a dial-up connection provide all the parameters required to dial the connection, negotiate password and data handling rules, and provide remote network connectivity. When you create a dial-up connection, the default settings include the following:

  • A standard modem, capable of 56 kilobits per second (Kbps), for dialing.

  • A phone number to dial.

  • A secure authentication protocol. Your computer will negotiate with the server to decide whether to use CHAP, MS-CHAP, or MS-CHAP v2.

  • The TCP/IP protocol is enabled, configured to obtain addresses automatically.

When you double-click this connection, it dials the number by using the specified modem. The connection completes successfully if the remote access server uses one of the specified encrypted authentication methods, and if the remote access server agrees to encrypt data. When connected, the remote access server assigns the remote access client an IP address.

Modems and remote access connectivity

Modems make it possible for computers to connect over conventional telephone lines. Dial-up analog lines require analog modems to establish a remote access connection with other computers whereas dial-up digital lines, such as Integrated Services Digital Network [ISDN], require digital modems. If the modems involved in a remote access connection do not function as they are intended to, the connection fails.

If the remote access client is not able to access the remote access server, one of the first few components that you need to check is the modem.

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify the client uses the same type of modem, such as analog or digital, as the server. This is because the client modem negotiates with the modem of the remote access server and if they are not of the same type, they may not be able to communicate with each other.

  • Because most modems work only with analog phone lines, you need to have analog phone lines installed for your analog dial-up connection. If you have a digital setup, you will need a digital modem and you must make sure that both the servers and clients have a digital modem.

  • Verify the modem appears in the list of devices. If not, then the appropriate modem drivers are not installed. Install the appropriate modem drivers in Windows 2000.

  • Check the connection rate of your modem.

  • Verify your modem cable is connected.

  • Check the remote access server to see if all available ports are already in use.

Component replacement and isolation Try the following task to remove this component from the configuration for purposes of troubleshooting:

  • Verify you are using the appropriate COM port.

VPN connections

A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. With a VPN connection, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point private link. Virtual private networking is the act of creating and configuring such a virtual private network.

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

The following illustration shows the logical equivalent of a VPN connection.

The logical equivalent of a VPN connection

Figure 1: The logical equivalent of a VPN connection

Types of VPN connections

There are two types of PPP-based VPN technologies in the Windows 2000 Server family:

  • Point-to-Point Tunneling Protocol (PPTP)

    PPTP enables the secure transfer of data from a remote computer to a private server by creating a VPN connection across IP-based data networks. PPTP supports on-demand, multiprotocol, virtual private networking over public networks, such as the Internet. PPTP uses user-level Point-to-Point Protocol (PPP) authentication methods and Microsoft Point-to-Point Encryption (MPPE) for data encryption.

  • Layer Two Tunneling Protocol (L2TP) with Internet Protocol security (IPSec)

    L2TP/IPSec uses user-level PPP authentication methods and computer-level authentication using either certificates or a preshared key. IPSec provides data encryption, data integrity, data origin authentication, and replay protection. L2TP/IPSec is a more secure VPN protocol than PPTP, but is more difficult to deploy. In addition, L2TP/IPSec cannot carry multicast or non-IP communications.

Remote access connections

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

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify that the Routing and Remote Access Service (RRAS) is enabled on the VPN server and that the PPTP and L2TP device usages are enabled for inbound remote access connections.

  • Verify you have enabled and configured the LAN protocols (IP, IPX) used by the remote access VPN clients to allow access to the network to which the VPN server is attached.

  • If the VPN server does support the tunneling protocol of the VPN client, you need to verify that the appropriate number of PPTP or L2TP ports is configured.

  • Verify that the PPTP or L2TP ports on the VPN server are not already being used.

  • Verify that the VPN connection has authorization through dial-in properties of the user account and the matching remote access policy. You can do this by using the Routing and Remote Access snap-in for the remote access server or for the RADIUS server.

Component replacement and isolation Try the following tasks to remove the above-mentioned components from the configuration for purposes of troubleshooting:

  • For VPN connections, configure the client for PPTP or L2TP, instead of automatic. For a Windows 2000 VPN client, choose Point to Point Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) instead of Automatic in the Type of VPN server I am calling list. You will find these settings on the Networking tab of the properties of a VPN connection.

  • If your L2TP connection failed, try configuring the connection for PPTP. If the connection attempt is successful, then you need to troubleshoot your L2TP/IPSec configuration. If a PPTP connection attempt is successful, but an L2TP/IPSec connection attempt is not, the problem is generally in establishing an IPSec association between the client and server. Typical problems that prevent L2TP/IPSec connections are the existence of a Network Address Translation (NAT) between the VPN client and VPN server, the lack of a computer certificate, or an incorrect certificate on the VPN client of VPN server.

  • If your PPTP VPN connection failed, try configuring the connection for L2TP. If the connection attempt is successful, then you need to troubleshoot your PPTP configuration.

IP connectivity between server and client

For VPN connections, the VPN client and server must have IP connectivity; they must be able to send and receive IP packets to each other across the Internet. Normally, you troubleshoot IP connectivity with the Ping and Tracert TCP/IP tools. These tools use ICMP Echo and Echo Reply messages and the default packet filter configuration of the VPN server is to only allow PPTP and L2TP traffic. Therefore, to use these tools on a Windows 2000 VPN server, you must temporarily modify the IP packet filters on the Internet interface of the VPN server to allow ICMP traffic.

Configuration Checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Check your error messages. If you get Error 678 for a PPTP connection, then the VPN server is probably not responding due to a timeout in the TCP connection to the VPN server. This happens if the TCP port 1723 is blocked somewhere between the VPN client and the VPN server.

  • The VPN server for a PPTP connection may not respond and cause Error 721 if the GRE is blocked (IP protocol 47). In this case, the TCP connection to the server is successful; however, the VPN server does not respond to repeated LCP requests from the VPN client.

  • If the L2TP server and client are both not behind a firewall and you do not see L2TP or IPSec packets coming from the other side in a trace, the problem could also be with an ISP. There are many ISPs that are now blocking L2TP and IPSec unless you pay for a “business” level account.

Component replacement and isolation Try the following task to remove this component from the configuration for purposes of troubleshooting:

  • Enable ICMP traffic on the Internet interface of the VPN server using the following steps:

    1. Click IP Routing from the tree pane of the Routing and Remote Access snap-in.

    2. Click General.

    3. Right-click the interface that corresponds to the interface connected to the Internet, and then click Properties.

    4. In the Properties dialog box for the interface, click Input Filters.

    5. Click Add. In the Add IP filter dialog box, click Protocol.

    6. In Protocol, click ICMP. Click OK.

    7. Complete this procedure again to add the corresponding output filter for ICMP traffic.

After you have enabled ICMP traffic on the Internet interface of the VPN server, the Ping or Tracert tools can be used from a remote access client on the Internet. You can now verify IP connectivity between the remote access server and the remote access client, detect network or host communication failures, and troubleshoot common TCP/IP connectivity problems.

Caution: This is a temporary configuration setting that will help you identify the problem component in your configuration. Because this can cause security issues, do not leave this setting on. Reverse this setting once you have successfully determined IP connectivity between the VPN client and the VPN server.

After you have verified IP connectivity, you can troubleshoot whether PPTP or L2TP/IPSec traffic is being either blocked by firewalls or by NATs.

Integrating VPN servers and firewalls

A VPN server can be positioned in one of several ways to operate with the Internet.

Firewalls outside the internal network and their role in remote access A firewall employs IP packet filtering to allow or disallow the flow of specific types of network traffic. IP filtering is the ability to define what traffic is allowed into and out of each interface based on filters defined by the values of source and destination IP addresses, TCP and UDP port numbers, ICMP types and codes, and IP protocol numbers. IP packet filtering provides a way to define precisely what IP traffic is allowed to cross the firewall and plays a key role in connecting private intranets to public networks like the Internet.

When setting up a firewall with a VPN server, you can use one of the following two layouts:

  • The VPN server is placed outside the firewall and attached directly to the Internet.

  • The VPN server is placed inside the firewall, which in turn is attached to the Internet.

Firewalls outside the internal network and their role in remote access

In the first scenario, the VPN server receives tunneled data from authenticated VPN clients. It decrypts all inbound traffic and sends it to the firewall. The firewall then employs its filters to allow traffic to be forwarded to intranet resources. The advantage is that the firewall checks the content of the users’ tunnels to ensure that only valid applications are running, or that only valid targets are being accessed Because the source of the data packets are authenticated VPN clients, the firewall prevents VPN users from accessing specific intranet resources.

Firewalls inside the internal network and their role in remote access In the second scenario, the VPN server receives all traffic that passes through the firewall. Because the firewall does not have encryption keys for each VPN connection it can only filter on the plaintext headers of the tunneled data. In this case, the firewall can do little to examine the traffic in user’s tunnels and trusts the VPN server to ensure that only authenticated users will be allowed access to the corporate network. In terms of security, it is the authentication requirement of the VPN server that prevents unauthorized access beyond the VPN server. The firewall has to be configured with input and output filters on its Internet interface to allow the passing of tunnel maintenance traffic and tunneled data to the VPN server.

Often, corporations prefer placing the firewall in front of the VPN server to help screen attacks from known IP addresses, let the VPN server select authenticated traffic, and then route the same to the firewall behind the VPN server that examines traffic further.

Firewalls inside the internal network and their role in remote access

Configuration Checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Verify the packet filters for PPTP and L2TP/IPSec have been appropriately set.

  • Verify that the packet filters for PPTP on the firewall between the VPN server and the Internet and on the VPN server perform the following actions:

    • Allow PPTP tunnel maintenance traffic to and from the VPN server

    • Allow PPTP tunneled data to and from the VPN server

      For more information about the specific packet filters for PPTP traffic, see VPNs and Firewalls.

  • Verify that the packet filters for L2TP/IPSec on the VPN server perform the following actions:

    • Allow Internet Key Exchange (IKE) traffic to and from the VPN server

    • Allow L2TP traffic to and from the VPN server

      For more information about the specific packet filters for L2TP/IPSec traffic, see VPNs and Firewalls.

  • Verify that the packet filters for L2TP/IPSec on the firewall between the VPN server and the Internet perform the following actions:

    • Allow Internet Key Exchange (IKE) traffic to and from the VPN server

    • Allow ESP traffic to and from the VPN server

      For more information about the specific packet filters for L2TP/IPSec traffic, see VPNs and Firewalls.

Component replacement and isolation Try the following tasks to remove this component from the configuration for purposes of troubleshooting:

  • If your configuration places the firewall between the VPN server and the intranet, configure packet filters on the firewall that allows all traffic to and from the VPN server. If the connection attempt is successful, then the packet filters in this configuration were causing the connection attempt to fail. Troubleshoot the existing packet filters and remove the filters that allow all traffic.

  • If your configuration places the firewall between the VPN server and the Internet, configure a packet filter on the firewall that allows all traffic to and from the VPN server. If the connection attempt is successful, the packet filters in this configuration were causing the connection attempt to fail. Troubleshoot the existing packet filters and remove the filters that allow all traffic.

  • If your firewall is placed between the VPN server and the Internet, configure the packet filters in the perimeter network and between the firewall and the Internet, temporarily, to allow all traffic to and from the VPN server. If the connection is successful, then you need to troubleshoot the firewall filters between the VPN server and the Internet. Troubleshoot the existing packet filters and remove the filters that allow all traffic.

  • If your firewall is placed between the VPN server and the intranet, configure the packet filters between the firewall and the intranet, temporarily, to allow all traffic to and from the VPN server. If the connection is successful, then you need to troubleshoot the firewall filters between the VPN server and the intranet. Troubleshoot the existing packet filters and remove the filters that allow all traffic.

NATs and PPTP and L2TP connections

A network address translator (NAT) is an IP router with the ability to translate the IP addresses and TCP/UDP port numbers of packets as they are forwarded. Consider the following items when using NATs with PPTP and L2TP connections:

PPTP clients can be placed behind a NAT only if the NAT has a PPTP editor, which can translate PPTP tunneled data. Most NATs have a PPTP editor, including the Microsoft implementations of network address translation (Internet Connection Sharing and the NAT routing protocol component of the RRAS).

PPTP servers cannot be placed behind a NAT unless you configure the NAT with a static translation table entry that allows all traffic to a specific public address to be mapped to a specific private address (a one-to-one address mapping).

L2TP/IPSec for Windows 2000 cannot work across a NAT. The IPSec SA negotiation and ESP-encrypted packets cannot be translated, even with a NAT editor. Although IPSec NAT Traversal (IPSec NAT-T) is a new standard that allows SA negotiation and ESP-encrypted traffic to transparently traverse a NAT, it is not supported at this time by the Windows 2000 VPN client or VPN server. IPSec NAT-T is supported by Microsoft L2TP/IPSec VPN Client (Windows 98, Windows Millennium Edition, and Windows NT® 4.0 Workstation) and Windows Server 2003. IPSec NAT-T support for Windows 2000 and Windows XP is under consideration.

Component replacement and isolation Try the following task to remove this component from the configuration for purposes of troubleshooting:

  • Connect the VPN client or server directly to the Internet, bypassing the NAT device and try the connection again. If the connection attempt is successful, then troubleshoot the configuration of the NAT device.

Remote Access Server

Server settings - general

With Windows 2000 remote access, remote access clients connect to remote access servers and are transparently connected to the network to which the remote access server is attached. 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. The position of a remote access server in a network can affect the bandwidth available to the network and remote access clients.

To allow remote access, you need to configure the following settings:

  • On the General tab of the properties of the remote access server in the Routing and Remote Access snap-in:

    • Verify that the Remote access server check box is selected.
  • On the Security tab:

    • Authentication Provider: You can verify the credentials of dial-up clients by choosing Windows Authentication or RADIUS Authentication. If RADIUS is selected, you need to configure RADIUS server settings for your RADIUS servers or proxies.

    • Authentication Methods: Select the authentication methods that are supported by the remote access server to authenticate the credentials of remote clients. Microsoft remote access clients typically use MS-CHAP or MS-CHAP v2 authentication. Non-Microsoft remote access clients typically use CHAP authentication. You also have the option to allow unauthenticated access.

    • Accounting Provider: You can record remote access activity for analysis or accounting purposes by selecting and configuring an accounting provider, such as RADIUS Accounting or Windows Accounting.

      Note: It is advisable not to change the default settings in the Security tab. However, if you need to make changes to the options available in the Security tab, ensure that you fully understand the implications

  • On the IP tab:

    • Verify that the Enable IP routing and Allow IP-based remote access and demand-dial connections check boxes are selected. This is on by default.

    • If a DHCP server is available, click Dynamic Host Allocation Protocol (DHCP). This is on by default. Otherwise, click Static address pool and configure the ranges of IP addresses that are dynamically allocated to remote access clients.

-Or-

  • On the PPP tab:

    • If you are using multilink or multilink with dynamic bandwidth (Bandwidth Allocation Protocol [BAP]), select Multilink connections and Dynamic bandwidth control using BAP or BACP.

    • If you are using the LCP extensions described in RFC 1570, select Link Control Protocol (LCP) extensions. This should be on by default unless the user disabled it.

    • If you are using Microsoft Point-to-Point Compression (MPPC), select Software compression.

  • On the Event Logging tab:

    • Select the appropriate level of logging.

    • To enable PPP logging, select Enable Point-to-Point Protocol (PPP) logging and restart the RRAS.

For more information about using event logging as a tool for troubleshooting, see the "Troubleshooting Tools" section of this article.

Server settings - security

Since 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 2000 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 EAP-MD5, EAP-TLS, MS-CHAP, MS-CHAPv2, CHAP, or 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. EAP allows vendor extensions on the client and the server.

Mutual authentication Mutual authentication is performed by authenticating both ends of the connection through the encrypted exchange of credentials. This is possible with the PPP remote access protocol using either the EAP-Transport Level Security (EAP-TLS) or MS-CHAP v2 authentication protocols. During mutual authentication, the remote access client authenticates itself to the remote access server, which in turn authenticates itself to the remote access client.

It is possible for a remote access server to not request authentication from the remote access client. However, if a Windows 2000 remote access client is configured only for MS-CHAP2 or EAP-TLS, then the remote access client will force mutual authentication of the client and the server. If the remote access server does not respond to the authentication request, the client terminates the connection.

Data encryption Data encryption is the process of encrypting the data sent between the remote access client and the remote access server. Remote access data encryption only provides data encryption on the communications link between the remote access client and the remote access server. If end-to-end encryption is needed, use IPSec to create an encrypted end-to-end connection after the remote access connection has been established.

In a PPP remote access connection, data encryption is based on a secret encryption key known to both the remote access server and remote access client. This shared secret key is generated during the PPP user authentication process.

Data encryption is possible over dial-up remote access links when using the PPP remote access protocol and the EAP-TLS, MS-CHAP, or MS-CHAP v2 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.

Windows 2000, Microsoft Windows NT 4.0, Windows 98, and Windows Millennium Edition remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and 40-bit, 56-bit, or 128-bit secret keys. MPPE keys for dial-up and PPTP remote access connections are generated from the MS-CHAP, MS-CHAP v2, and EAP-TLS user authentication process.

Remote access account lockout The remote access account lockout feature is used to specify the number of times a remote access authentication fails for a valid user account before the user is denied remote access. This feature is especially important for remote access virtual private network (VPN) connections over the Internet. Malicious users on the Internet can attempt to access an organization’s intranet by sending credentials, such as valid user name and guessed password, during the VPN connection authentication process. During a dictionary attack, the malicious user sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases. With remote access account lockout enabled, a dictionary attack is thwarted after a specified number of failed attempts. For more information, see Internet Authentication Service for Windows 2000.

Authentication protocols To authenticate the user who is attempting to create a PPP connection, Windows 2000 supports the following PPP authentication protocols:

  • Password Authentication Protocol (PAP)

  • Challenge-Handshake Authentication Protocol (CHAP)

  • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

  • MS-CHAP version 2 (MS-CHAP v2)

  • Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)

  • Extensible Authentication Protocol-Transport Level Protocol (EAP-TLS)

For PPTP connections, you must use MS-CHAP, MS-CHAP v2, or EAP-TLS. Only these three authentication protocols provide a mechanism to generate the same encryption key on both the VPN client and the VPN server. MPPE uses this encryption key to encrypt all PPTP data sent on the VPN connection. MS-CHAP and MS-CHAP v2 are password-based authentication protocols.

In the absence of user certificates or smart cards, MS-CHAP v2 is highly recommended, as it is a stronger authentication protocol than MS-CHAP and provides mutual authentication. With mutual authentication, the VPN server authenticates the VPN client and the VPN client authenticates the VPN server.

For L2TP/IPSec connections, any authentication protocol can be used because the authentication occurs after the VPN client and VPN server have established a secure channel of communication known as an IPSec security association (SA). However, the use of either MS-CHAP v2 or EAP-TLS is recommended to provide strong user authentication.

For more information about design issues on which authentication protocol to use, see Virtual Private Networking with Windows 2000: Deploying Remote Access VPNs.

Address allocation You can use a DHCP server to obtain IP addresses assigned to TCP/IP based remote access connections. Remote access clients are assigned an APIPA address (in the range 169.254.0.0/16) if the correct adapter is not selected on the IP tab in the properties of the remote access server in the Routing and Remote Access snap-in. You could also be assigned an APIPA address when the DHCP server becomes unavailable or when it runs out of addresses for the subnet.

Alternately, you can configure the RRAS to use static addresses, which specifies that the server will use a configured static pool of IP addresses for allocation to TCP/IP-based remote access connections.

Configuration checklist Use the information in the following checklist to identify whether the server components or settings mentioned above are responsible for your failed remote access connection:

  • Verify you are using MS-CHAP, MS-CHAP v2, or EAP-TLS for PPTP connections.

  • Verify that the Remote access server option is selected.

  • Verify you are using an authentication protocol that is common between the remote access server and the remote access client. Verify that the common authentication method is also enabled on the matching remote access policy.

  • If you are using RADIUS, verify you have properly configured the RADIUS servers or proxies.

  • Verify that IP routing is enabled.

  • Verify that your remote access client is configured to support data encryption. If the client does not meet the server’s requirement for data encryption, the connection attempt is rejected.

  • If you are using the remote access account lockout feature, verify the account is not being locked out.

Component replacement and isolation Try the following tasks to remove these components from the configuration for purposes of troubleshooting:

  • For a PPTP connection, try using MS-CHAP instead of MS-CHAP v2, or EAP-TLS. You could also try temporarily configuring the connection to use no encryption at all and then use PAP to establish the connection.

  • To isolate the issue to a misconfiguration of a common authentication protocol, enable all authentication protocols (including PAP) on the remote access client, the remote access server, and the remote access policy.

  • For remote access account lockout, reset the account and try the connection again.

  • If you are getting APIPA addresses, try reconfiguring for static IP address pools or troubleshoot your DHCP configuration.

Caution: Suggestions to use PAP are temporary configuration settings that will help you identify the problem in your configuration. Because this can cause security issues, do not leave this setting on. Reverse this setting after you have successfully identified your problem component.

Ports

A port is a hardware or software channel of a device that can support a single point-to-point connection. Ports are grouped by type, such as analog phone ports, ISDN B-channel ports, and VPN ports, such as PPTP and L2TP.

Configuration checklist

  • Verify that the port usage for the device being used for the connection is enabled for remote access (inbound).

  • Verify that there are enough PPTP or L2TP ports.

DHCP Relay Agent

A Windows 2000 remote access server can function as an RFC 1542-compliant DHCP relay agent relaying Dynamic Host Configuration Protocol (DHCP) messages between DHCP clients and DHCP servers on different IP networks. For Windows 2000 and Windows XP remote access clients, the remote access server forwards the DHCPInform message sent by remote access clients to the DHCP server. The response is sent back to the remote access client, providing additional configuration information.

If the remote access server is using DHCP to obtain an IP address configuration for its intranet interface when the Routing and Remote Access Server Setup Wizard runs, then the wizard configures the DHCP Relay Agent automatically. Otherwise, you must manually configure the DHCP Relay Agent routing protocol component with the IP address of at least one DHCP server on your intranet.

Configuration checklist Use the information in the following checklist to identify whether the components mentioned above are responsible for your failed remote access connection:

  • Check to see if the DHCP Relay Agent has been added as a routing protocol component with the Internal interface.

  • Verify that the Relay DHCP packets check box is selected for the Internal interface.

  • Check to see if the DHCP Relay Agent has been configured with the IP address of at least one DHCP server.

  • Verify that the IP addresses of DHCP servers configured on the global properties of the DHCP Relay Agent are the correct IP addresses for DHCP servers on your internetwork.

  • From the remote access server, use the ping command to ping each of the configured DHCP servers. If you cannot ping the DHCP servers from the DHCP Relay Agent router, troubleshoot the lack of connectivity between the remote access server and the DHCP server or servers.

  • Verify that IP packet filtering is not preventing the receiving (through input filters) or sending (through output filters) of DHCP traffic on the intranet interface. DHCP traffic uses the UDP ports of 67 and 68.

  • Verify that TCP/IP filtering on the intranet interface is not preventing the receiving of DHCP traffic.

Component replacement and isolation To remove this component from the configuration for purposes of troubleshooting, try the following:

  • To identify whether IP packet filtering is the problem, try removing or disabling the IP packet filtering on the intranet interface. If this allows DHCP traffic to pass through from the DHCP server to the DHCP client, then you need to troubleshoot the IP packet filtering settings on the intranet interface.

  • To identify whether a specific DHCP server is the problem, reconfigure the DHCP Relay Agent with the address of a different DHCP server on your intranet.

Authenticating Server

Depending on the configured authentication provider, the authenticating server can be the remote access server (Windows Authentication) or a RADIUS server (RADIUS Authentication).

Remote Access Server

When Windows Authentication is configured, the remote access server performs authentication by validating the credentials of the remote access client using:

  • The local account database, if the remote access server is a member of a workgroup or a stand-alone computer.

  • A domain account database located on a domain controller, if the remote access server is a member of a domain.

    Windows 2000 uses Kerberos security as the default authentication method for Active Directory domains.

Configuration checklist Use the information in the checklist given below to identify whether the above-mentioned components are responsible for your failed remote access connection.

  • Ensure that you have added the computer account of your remote access server as a member of the RAS and IAS Servers group for each domain.

  • You could also be having authentication and authorization issues with the remote access server.

  • Verify that the remote access server is a domain member.

  • Verify that other domains have two-way trusts with the domain of the remote access server.

  • Verify that remote access server can access a local domain controller and global catalog server.

Component replacement and isolation To remove this component from the configuration for purposes of troubleshooting, try the following:

  • Specify a local account instead of a domain-based account. If the connection attempt is successful then it means that you need to troubleshoot domain authentication.

  • Instead of using Windows authentication, try using RADIUS authentication. If the connection attempt is successful, then you need to troubleshoot Windows local or domain authentication.

  • Try to view the list of accounts on a different domain from your remote access server. If other domains have two-way trusts with your remote access server domain, you should be able to access other domains. If you cannot access different domains, you may need to troubleshoot the domain relationships.

RADIUS Server

RADIUS is an industry standard protocol used to authenticate, authorize, and account for remote access server connections. Internet Authentication Service (IAS) in Windows 2000 is the Microsoft implementation of a RADIUS server. IAS can be used as a RADIUS server to any device, typically a network access server (NAS), which supports RADIUS, including the Windows 2000 RRAS. IAS can be used in a variety of scenarios, including centralized authentication and accounting for an organization’s remote access infrastructure, outsourced corporate access using third party dial-up service providers, and centralized authentication and accounting for an Internet service provider (ISP).

An administrator can use RADIUS accounting to track network usage for auditing and billing purposes. The IAS server creates a log file based on the data returned by the NAS. This information is useful for keeping track of usage and for correlating authentication information with accounting records.

IAS performs authentication by validating the credentials of the remote access client using:

  • The local account database, if the IAS server is a member of a workgroup or a stand-alone computer

  • A domain account database located on a domain controller, if the IAS is a member of a domain.

Configuration checklist Use the information in the checklist given below to identify whether your RADIUS configuration is correct.

  • Verify that the IAS service has started on the RADIUS server.

  • Verify that the remote access server is configured with the correct address of the IAS server(s).

  • Verify that the IAS server is configured with the correct address of the remote access server(s) as RADIUS clients.

  • Verify that the shared secret configured both on the remote access server and the IAS server is the same. The remote access server running Windows 2000 and the IAS server share a secret that is used to provide security for messages sent between them.

  • Verify that both the remote access server and the IAS server are using a common UDP port. The default RADIUS port for authentication traffic is 1812.

  • Verify that the remote access policies on the IAS servers are correctly configured. Once the remote access servers are configured to use RADIUS authentication, the remote access policies stored on the remote access servers are no longer used. Instead the remote access policies stored on the IAS server are used.

  • Check to see if the RADIUS server is reachable from the remote access server.

  • Check to see if the authentication is working for all domains or only some domains.

Component replacement and isolation To remove this component from the configuration for purposes of troubleshooting, try the following:

  • Try and reconfigure RRAS for Windows authentication. If authentication does not take place successfully, it’s not the RADIUS configuration that is causing the connection to fail. If authentication does take place successfully, then you will need to troubleshoot your RADIUS configuration.

  • Try to ping the IAS server from the remote access server. If you are not successful, you will need to troubleshoot the connectivity between the remote access server and the IAS server.

  • If you are using IPSec to encrypt RADIUS traffic, temporarily disable IPSec protection for RADIUS traffic.

Note: To provide redundancy and fault tolerance, configure two IAS servers, a primary and a backup, and copy the remote access policies from the primary to the backup. Then configure each remote access server with two RADIUS servers that correspond to the primary and backup IAS servers. If the primary IAS server becomes unavailable, then the remote access servers automatically begin to use the secondary IAS server.

Remote Access Policies

Remote access policies are a set of conditions and connection settings that allow configuration flexibility in authorizing connection attempts. Remote access policies are either configured on the remote access server, when configured for the Windows authentication provider, or the IAS server, when configured for the RADIUS authentication provider.

Configuration checklist Use the information in the checklist given below to identify whether the above-mentioned components are responsible for your failed remote access connection.

  • Verify that the settings of the connection attempt match at least one of the remote access policies.

  • Make sure that you have correctly configured the dial-in properties for the user account corresponding to the user who is attempting a connection.

Component replacement and isolation To remove this component from the configuration for purposes of troubleshooting, try the following:

  • Move the default remote access policy, recreating it if necessary, so that it is the first policy. Change the remote access permission of the default policy to Grant remote access permission. If the connection attempt is successful, it means that you need to troubleshoot your custom remote access policies.

User Accounts

User accounts are the security objects that exist either on the local computer or in a domain against which remote access client credentials are checked.

Configuration checklist Use the information in the checklist given below to identify whether the following are responsible for your failed remote access connection.

  • Verify that the remote access client user is using a correct user account name and password.

  • Verify that the user account is enabled, not locked out, not expired, and is connecting during valid logon time.

  • Verify that the user account is not being disabled for remote access connections with remote access account lockout.

Component replacement and isolation To remove this component from the configuration for purposes of troubleshooting, try the following:

  • Create a new user account with default settings and try the connection again. If the attempt is successful, then troubleshoot the user account configuration that you were using.

  • Try the connection attempt using a local user account that is configured using the Local Users and Groups folder in the Computer Management snap-in. If the connection attempt is successful, then troubleshoot the configuration of the domain user account.