Troubleshooting Windows 2000 Remote Access...

Troubleshooting Windows 2000 Remote Access Connections

Microsoft CorporationPublished: January 2003

Abstract

This article helps Windows 2000 network administrators troubleshoot remote access connections by providing information on how to isolate the problem component in a failed connection. This article describes the components of a remote access connection, the connection setup process, troubleshooting tools, and common remote access problems. This article assumes a basic level of understanding of remote access connections, networks, and their administration and familiarity with the online Help files for remote access in Windows 2000 Server Help. It is intended for network engineers and support professionals who are already familiar with TCP/IP, IP routing, IPX routing, and wide area network technology.

Microsoft® Windows® 2000 Server Technical Article

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.© 2003 Microsoft Corporation. All rights reserved.Microsoft, Active Directory, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


ContentsAcknowledgements..................................................................................................................... vi

Introduction................................................................................................................................... 1

Windows 2000 remote access..................................................................................................1

Icon key...................................................................................................................................... 1

Remote access components and problem isolation.................................................................3

Client configuration.................................................................................................................. 3

User Name and Password.....................................................................................................3

Phone number, IP address, Domain name..........................................................................3

Authentication and encryption settings..............................................................................4

Type of Server........................................................................................................................ 5

Dial-up connections.................................................................................................................. 5

Modems and remote access connectivity...........................................................................6

VPN connections....................................................................................................................... 6

Types of VPN connections...................................................................................................7

Remote access connections................................................................................................7

IP connectivity between server and client...........................................................................8

Integrating VPN Servers and Firewalls................................................................................9

NATs and PPTP and L2TP connections............................................................................12

Remote Access Server...........................................................................................................12

Server settings - General....................................................................................................12

Server settings - Security...................................................................................................14

Ports..................................................................................................................................... 17

DHCP Relay Agent.................................................................................................................. 17

Authenticating Server.............................................................................................................18

Remote Access Server........................................................................................................18

RADIUS Server.....................................................................................................................19

Remote Access Policies.....................................................................................................20

User Accounts.....................................................................................................................20

Remote access connection setup process..............................................................................22

Step 1: Physical or logical link setup....................................................................................22


Dial-up connection..............................................................................................................22

PPTP..................................................................................................................................... 22

L2TP/IPSec........................................................................................................................... 23

Step 2: PPP connection setup...............................................................................................24

PPP phase 1: Link negotiation...........................................................................................24

PPP phase 2: Authentication..............................................................................................24

PPP phase 3: Callback (dial-up only).................................................................................24

PPP phase 4: Network protocol negotiation.....................................................................25

Step 3. Remote access client registration............................................................................25

Using a DHCPInform message...........................................................................................25

Name registration................................................................................................................26

Remote access troubleshooting tools......................................................................................27

TCP/IP Utilities......................................................................................................................... 27

The tracert command..........................................................................................................27

The ping command..............................................................................................................27

Event Logging.........................................................................................................................29

Routing and Remote Access..............................................................................................29

Internet Authentication Service (IAS)................................................................................29

iasparse.exe tool.................................................................................................................. 31

Authentication and Accounting Logging..............................................................................31

Windows Authentication and Accounting Logging..........................................................31

Network Monitor...................................................................................................................... 32

Using Network Monitor to troubleshoot............................................................................32

Tracing..................................................................................................................................... 33

Oakley Logging....................................................................................................................... 34

PPP Logging............................................................................................................................ 34

Enabling PPP logging for Routing and Remote Access..................................................35

Enabling PPP logging by using Netsh.exe........................................................................35

Disabling PPP Logging.......................................................................................................35

Common remote access problems...........................................................................................36

Users cannot connect.........................................................................................................36

Users can connect but can’t authenticate.........................................................................39


L2TP/IPSec authentication Issues......................................................................................40

EAP-TLS authentication Issues..........................................................................................41

Users can connect and authenticate but cannot reach locations beyond the remote access server.................................................................................................................................... 44

Users can connect, authenticate and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing)................................................................................................................................................ 45

Miscellaneous remote access solutions...........................................................................46

System Event Log Error IDs......................................................................................................47

Common System Event Log Error IDs..................................................................................47

Event ID # 20050.................................................................................................................. 47

Event ID # 20189.................................................................................................................. 48

Event ID # 1051....................................................................................................................49

Event ID # 20187.................................................................................................................. 51

Event ID # 20049.................................................................................................................. 52

Event ID # 20014.................................................................................................................. 52

Event ID # 20073.................................................................................................................. 53

Event ID # 20171.................................................................................................................. 55

Summary..................................................................................................................................... 56

Related Links.............................................................................................................................. 57


AcknowledgementsJoyce Paul, Technical Writer, Microsoft Corporation

Jenelle Coberly, Test Lead, Microsoft Corporation

Tod Edwards, Technical Lead, Microsoft Corporation

David Eitelbach, Program Manager, Microsoft Corporation

Susan Ferrell, Technical Writer, Microsoft Corporation

John Lamb, Software Test Engineer, Microsoft Corporation

Elliot Lewis, Program Manager, Microsoft Corporation

Patrick Sears, Software Test Engineer, Microsoft Corporation

Jeff Sigman, Software Design Engineer, Microsoft Corporation

Mike Stanger, Software Test Engineer, Microsoft Corporation

Rob Trace, Program Manager, Microsoft Corporation

vi


Introduction IndexA remote access connection allows computers to securely access organization intranets.

Due to the large number of components involved in a remote access connection this article:

helps Windows 2000 administrators troubleshoot remote access connections by providing information on how to isolate the problem component in a failed connection.

begins with a general introduction to the components of a remote access connection that are most likely to cause a problem and includes information on how to identify and isolate a component as the potential problem component.

describes the connection setup process, which is critical to understanding the phases of a remote access connection and the information gathered by troubleshooting tools.

describes the tools used in troubleshooting and how to troubleshoot common remote access problems.

lists frequently occurring error Ids

Windows Technical Article 1


describes how to trace events based on these IDs

refers to Microsoft Knowledge Base (KB) articles that contain the related solution.

Ultimately, creating a standardized methodology that administrators can use to efficiently track down the problem area and fix it can save precious time spent deciphering complex error logs.

resolve issues on your own before calling Microsoft Product Support Services.

Windows 2000 remote access IndexRemote access technology as supported by Microsoft® Windows® 2000 Server allows dial-up or remote access clients to connect to corporate networks or the Internet. Using Windows 2000 remote access, remote access clients can either be:

transparently connected to the remote access server, known as point-to-point remote access connectivity,

or be transparently connected to the network to which the remote access server is attached, known as point-to-LAN remote access connectivity. In most cases, point-to-LAN connectivity is used.



This transparent connection allows remote access clients to connect from remote locations and access resources as if they were physically attached to the network.

Windows 2000 remote access provides two different types of remote access connectivity:

dial-up remote access

virtual private network (VPN) remote access.

Connection Protocols

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

The following typically-used remote access protocols are supported by Windows 2000 remote access:

Point-to-Point Protocol (PPP), which is an industry-standard set of protocols providing the best security, multi-protocol support, and interoperability.



Serial Line Internet Protocol (SLIP), which is used by older remote access servers.

While Windows 2000 remote access servers do not support SLIP, a Windows 2000 remote access client can use SLIP as a remote access protocol.

Icon keyThe following icons are used to identify specific types of content in this article:

- Isolation - Caution - Important

- Checklist - Note

If you are already familiar with the different components involved in a remote access connection and do not need to review concepts or learn how to remove a specific component from the configuration for purposes of troubleshooting, see "Remote access common problems" in this article. This section contains information on common remote access problems, the associated error



messages, and troubleshooting tips. You may be able to locate your problem in the list of common problems and benefit from the troubleshooting methods described.



Remote access components and problem isolation IndexThis 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.

o You can use the items in this checklist to ensure that the component is configured correctly.

describes how you can isolate a specific component from the configuration by replacing it with another component capable of achieving a similar function.

o This process serves to identify the excluded component as the problem component.



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

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.




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 IndexTry 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 serverIn dial-up connections for Windows 2000 remote access clients, the type of server can be:

PPP:

Windows 95/98/NT 4/2000,

Internet server

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 IndexUse 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 IndexThe 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

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.

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.

Configuration checklist Index

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.


Verify you are using the appropriate COM port.



VPN connectionsA 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.



Fig 1. The logical equivalent of a VPN connection



Types of VPN connections IndexThere 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 IndexUsers 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.


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

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

Click General.

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

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

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

In Protocol, click ICMP. Click OK.

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.



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 IndexA 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 accessA 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.



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




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.


http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/intwork/inbe_vpn_hidv.asp



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 IndexTry 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 IndexA 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.




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 Index

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. For information about enabling CHAP, see CHAP. 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.


http://www.microsoft.com/windows2000/en/server/help/sag_RRAS-Ch1_78.htm?id=2365


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 Index

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.


http://www.microsoft.com/windows2000/techinfo/howitworks/communications/remoteaccess/ias.asp



Authentication protocolsTo 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 IndexYou 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.


http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/network/deploy/depovg/vpndeply.asp

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/network/deploy/depovg/vpndeply.asp


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

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




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 ServerDepending on the configured authentication provider, the authenticating server can be the remote access server (Windows Authentication) or a RADIUS server (RADIUS Authentication).



Remote Access ServerWhen 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.


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 ServerRADIUS 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,




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.

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.




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


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.



Remote access connection setup processThe creation of a remote access connection for either a dial-up or VPN remote access connection occurs in the following three steps:

1.Physical or logical link setup

The physical or logical link setup creates the point-to-point link between the remote access client and the remote access server for the purposes of sending PPP protocol suite frames or PPP frames containing data. A physical link is used for a dial-up connection, in which the phone line is the physical link. A logical link is used for VPN connections, in which the VPN tunnel represents a logical point-to-point link. With the Windows 2000 remote access client, the message displayed to the user during the physical or logical link setup is "Connecting."

2.PPP connection setup

The PPP connection setup uses the suite of PPP protocols to negotiate the parameters of the PPP link, authenticate the credentials of the remote access user, perform callback, and negotiate the use of and



the parameters for the protocols that will be operating over the PPP link. With the Windows 2000 remote access client, the message displayed to the user during the PPP connection setup is "Verifying user name and password."

3.Remote access client registration

During the remote access client registration, the remote access client obtains addition configuration parameters and registers itself for name resolution. With the Windows 2000 remote access client, the message displayed to the user during remote access client registration is "Registering your computer on the network."

Step 1: Physical or logical link setupThe process for the physical or logical link setup depends on whether the connection is a dial-up or a VPN connection.

Dial-up connectionFor the dial-up connection, the following process occurs:



1.The user of the remote access client computer initiates the dial-up connection. In Windows 2000, the user double-clicks the connection in the Network and Dial-up Connections folder.

2.The modem picks up phone line and gets a dial tone.

3.The modem then dials the phone number of the remote access server.

4.The remote access server answers the incoming call.

5.The modems of the remote access client and the remote access server use modem negotiation protocols to determine line speed and other modem communication parameters.

6.The physical connection is established and the dial-up call is complete.

PPTPFor a PPTP-based VPN connection, the connection is established in the following two phases:

Phase 1

A TCP connection is initiated from the remote access client using a dynamically allocated TCP port to the remote access server using TCP port 1723.



Phase 2

The remote access client and the remote access server exchange a series of PPTP messages to negotiate the use of a PPTP tunnel and a specific call ID to identify the PPTP connection. For more information, see RFC 2637. The result of the negotiation is a call ID that is used when sending PPTP-encapsulated data using the PPTP Generic Routing Encapsulation (GRE) header.

When the PPTP connection setup begins, the remote access client must already be connected to the Internet. If not, a dial-up connection to an Internet service provider can be made prior to initiating the PPTP connection.

L2TP/IPSecFor an L2TP/IPSec-based VPN connection, the connection is established in the following two phases:

Phase 1

The IPSec security associations needed to protect IPSec-based communications and data are negotiated and created. IPSec uses the Internet Key Exchange (IKE) protocol to negotiate the IKE main mode and quick mode security associations (SAs). The main mode SA is used to protect IPSec



negotiations. The quick mode SAs—one for inbound packets and one for outbound packets—are used to protect L2TP data using UDP port 1701. The main mode SA is authenticated using either certificates or a preshared key.

For certificate authentication, the remote access server sends the remote access client a list of acceptable root certification authorities (CAs) from which a certificate will be accepted for authentication. The remote access client responds with a certificate chain (ending at a root CA certificate for a root CA from the list sent by the remote access server) and its own list of root CAs from which a certificate will be accepted for authentication. The remote access server verifies the certificate chain of the remote access client, and then sends a certificate chain (ending at a root CA certificate for a root CA from the list sent by the remote access client). The remote access client verifies the certificate chain of the remote access server.

For preshared key authentication, both the remote access client and remote access server send a hash value that incorporates the preshared key. The hash value sent by the remote access client is verified by the remote access server and the hash value sent by the remote access server is verified by the remote access client.



For more information about main mode and quick mode negotiations, see IKE Negotiation for IPSec Security Associations.

Phase 2

The remote access client and the remote access server exchange a series of L2TP messages to negotiate the use of an L2TP tunnel and a specific call ID to identify a connection within the L2TP tunnel. For more information, see RFC 2661. The result of the negotiation is a tunnel ID and a call ID that is used when sending L2TP-encapsulated data using the L2TP header.

When the L2TP/IPSec connection setup begins, the remote access client must already be connected to the Internet. If not, a dial-up connection to an Internet service provider can be made prior to initiating the L2TP/IPSec connection.

Step 2: PPP connection setupThe PPP connection process occurs in the following phases:

1.Link negotiation

2.Authentication


http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/cableguy/cg0602.asp

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/cableguy/cg0602.asp


3.Callback (dial-up only)

4.Network protocol negotiation

PPP phase 1: Link negotiationThe remote access client and remote access server exchange the following series of Link Control Protocol (LCP) messages to negotiate the parameters of the PPP links:

The authentication protocol to use to verify the credentials of the remote access client, and for mutual authentication protocols, the remote access server, in the authentication phase.

The PPP maximum receive unit (MRU), the maximum number of bytes in a PPP frame.

Whether to use protocol and address and control field compression.

The use of callback.

PPP phase 2: AuthenticationThe remote access client and remote access server exchange a series of messages for the authentication protocol specified in the link negotiation phase. For PAP, SPAP, CHAP, MS-CHAP, and MS-CHAP v2, a



fixed set of messages is exchanged. For EAP, an EAP type is negotiated and then a set of messages corresponding to the EAP type are exchanged. EAP negotiations can have a variable number of messages.

MS-CHAP v2 and EAP-TLS provide mutual authentication, in which the remote access client authenticates itself to the remote access server and the remote access server authenticates itself to the remote access client.

PPP phase 3: Callback (dial-up only)If negotiated during the link negotiation phase, the dial-up remote access client and the remote access server use the Callback Control Protocol (CBCP) to determine the phone number at which the remote access client is to be called back. Based on the Callback Options settings on the Dial-in tab on the properties of the remote access client user account, either the callback number is specified or the user at the remote access client is either prompted for the callback number. In either case, the following actions occur:

1.The remote access server hangs up.

2.The remote access server calls the remote access client back at the determined phone number.



3.The remote access connection proceeds to the next phase.

PPP phase 4: Network protocol negotiationAfter authentication and callback, protocols known as Network Control Protocols (NCPs) are used to negotiate the use of and configuration for network protocols, such as TCP/IP and IPX. The following NCPs are used:

Internet Protocol Control Protocol (IPCP)

Used to negotiate parameters for the TCP/IP protocol, including IP address, the use of IP compression, and the addresses of DNS and WINS servers.

IPX Control Protocol (IPXCP)

Used to negotiate parameters for the IPX protocol, including the IPX network and node numbers.

AppleTalk Control Protocol (ATCP)

Used to negotiate parameters for the AppleTalk protocol, including the AppleTalk network and node numbers.



NetBIOS Frames Control Protocol (NBFCP)

Used to negotiate parameters for the NetBIOS Extended User Interface (NetBEUI) protocol.

Bandwidth Allocation Control Protocol (BACP)

Used to negotiate parameters for the Bandwidth Allocation Protocol (BAP). BAP is used to dynamically add and remove links from a Multilink Protocol (MP) connection based on bandwidth needs. BAP only applies to dial-up connections.

Compression Control Protocol (CCP)

For Microsoft remote access clients and servers, CCP is used to negotiate the use of Microsoft Point-to-Point Compression Protocol (MPPC) and the use of and encryption strength for Microsoft Point-to-Point Encryption (MPPE).

Step 3. Remote access client registrationRegistration for remote access clients consists of using a DHCPInform message to obtain additional TCP/IP configuration parameters and performing name registration.



Using a DHCPInform messageThe remote access client uses a DHCPInform message using the following process:

1.The remote access client sends a DHCPInform message on the PPP link to the remote access server.

2.The remote access server, configured with the DHCP Relay Agent and at least one address of a DHCP server, relays the DHCPInform message to the DHCP server.

3.The DHCP server sends back a DHCPAck message, which contains the requested options that are configured on the DHCP server.

4.The remote access server relays the DHCPAck to the remote access client.

The principal use of the DHCPInform message is to obtain TCP/IP configuration parameters that are not obtained using IPCP, such as the domain name assigned to the PPP connection. Only Windows 2000 and Windows XP remote access clients send the DHCPInform message.



Name registrationTo allow nodes on the private network to resolve the names of remote access clients while they are connected, the names and IP addresses of the remote access clients must be registered in the DNS and NetBIOS namespaces of the private network. Because a remote access client is typically assigned a different IP address any time they connect, names in the namespaces should be dynamic, rather than static. To achieve dynamic registration of DNS and NetBIOS names for the private network, remote access client name registration consists of the following:

1.The remote access client sends NetBIOS name registration messages to its configured WINS server to register its NetBIOS names.

2.The remote access client sends dynamic DNS update messages to its configured DNS server to register its DNS names.



Remote access troubleshooting toolsThis section introduces you to tools that can be used to troubleshoot remote access connections.

TCP/IP utilities

The tracert command If you are having connectivity problems, you can use the tracert command to check the path to the destination IP address that you want to reach and record the results. The tracert command displays the series of IP routers that are used in delivering packets from your computer to the destination computer and also how long it took on each hop. If the packets are unable to be delivered to the destination, the tracert command displays the last router that successfully forwarded your packets.

For more information about the tracert command, type tracert –? at a command prompt.

The most common use of tracert is as follows:tracert AddressOrName [–d]



This command returns a list of the routers that are crossed to get to destination IP address. By using the –d option, the router path is displayed faster because tracert does not try to resolve the names of the routers in the path.

Usage of the command is as follows:tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] AddressOrName

Options:-d Do not resolve addresses to hostnames-h maximum_hops Maximum number of hops to search for target-j host-list Loose source root along host list-w timeout Wait timeout milliseconds for each reply

The ping command If you are having connectivity problems on your TCP/IP network, you can use the ping command to check the destination IP address that you want to reach and record the results. The ping command displays



whether the destination responded and how long it took to receive a reply. If there is an error in the delivery to the destination, the ping command displays an error message.

The ping command is an external command that is available in Windows 2000. This command helps determine IP addresses in TCP/IP networks as well as identify and resolve network issues.

You can use the ping command to:

Ping your computer (by address, not host name) to determine that TCP/IP is functioning. Note that pinging your computer does not verify that your network adapter is functioning.

Ping the local router to determine whether the router is running.

Ping beyond your local router.

Verify IP-level connectivity.

Send an Internet Control Message Protocol (ICMP) echo message to a target host name or IP address.

Verify that a host computer can connect to the TCP/IP network and network resources.



Isolate network hardware problems and incompatible configurations.

The following table shows some useful ping command options.

Option Use

-n Count Determines the number of ICMP Echo messages to send. The default is 4.

-w Timeout Enables you to adjust the time-out (in milliseconds). The default is 1,000 (a 1-second time-out).

-l Size Enables you to adjust the size of the ICMP echo message data field. The default size is 32 bytes.

-f Sets the Don’t Fragment bit on the ICMP echo message. By default, the ICMP echo message allows fragmentation.

For more information about other ping options, see Command-line utilities.

For example, to check connectivity by using the ping command, at a command prompt, type ping and the IP address you want to reach.


http://www.microsoft.com/windows2000/en/server/help/sag_tcpip_tro_usingcommands.htm


A response of "Destination net unreachable" means there was no route to the destination. You need to check the routing table on the router listed in the "Reply from" address in the "Destination net unreachable" message. For more information about the routing table, see Understanding the IP routing table.

A response of "Request timed out" means there was no response to the ping attempt in the default time period of one second. In this case, look for the following problems:

A router is down. To check the routers in the path between the source and the destination, use the tracert command. For more information, see Using the tracert command.

The destination host is down. Physically verify that the host is running or check connectivity through another protocol.

There is no route back to your computer. If the host is running, you can check for a return route by viewing the default gateway and local routing table on the destination host.

The latency of the response is more than one second. Use the -w option on the ping command to increase the time-out. For example, to allow responses within five seconds, use ping -w 5000.


http://www.microsoft.com/windows2000/en/server/help/sag_rras-ch5_3a.htm

http://www.microsoft.com/windows2000/en/server/help/sag_RRAS-Ch5_4.htm


If the ping command is not found or the command fails, you can use Event Viewer to check the System Log and look for problems reported by Setup or the Internet Protocol (TCP/IP) service.

The ping command uses ICMP echo and echo reply messages. Packet filtering policies on routers, firewalls, or other types of security gateways might prevent the forwarding of this traffic. For example, a computer running Windows 2000 with IIS as a Web server and packet filters that allow only Web-based traffic will not respond to ICMP echo messages.

To test a TCP/IP configuration by using the ping command, complete the following steps:

1. To quickly obtain the TCP/IP configuration of a computer, type ipconfig at a command prompt. From the display of the ipconfig command, ensure that the network adapter for the TCP/IP configuration you are testing is not in a Media disconnected state.

2. At a command prompt, ping the loopback address by typing ping 127.0.0.1. If the ping command fails, verify that the computer was restarted after TCP/IP was installed and configured. (The loopback address is designated for the software loopback interface of a computer, has no hardware associated with it, and is not physically connected to a network. Therefore, it allows you to test IP software


http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/windows2000/en/server/help/event_overview.htm?id=4022


without worrying about broken or corrupted drivers or hardware.)

3. Ping the IP address of the computer. If the ping command fails, verify that the computer was restarted after TCP/IP was installed and configured.

4. Ping the IP address of the default gateway. If the ping command fails, verify that the default gateway IP address is correct and that the gateway (router) is operational.

5. Ping the IP address of a remote host (a host that is on a different subnet). If the ping command fails, verify that the remote host IP address is correct, that the remote host is operational, and that all of the gateways (routers) between this computer and the remote host are operational.

6. Ping the IP address of the DNS server. If the ping command fails, verify that the DNS server IP address is correct, that the DNS server is operational, and that all of the routers between this computer and the DNS server are operational.

Event loggingEvent logging for remote access connections is the recording of events into the system log, which can be viewed with the Event Viewer snap-in. System administrators commonly use event logging for



troubleshooting or to get information about unusual events that might have occurred during a remote access attempt.

Routing and remote accessThe Event Logging tab on the Properties dialog box of a remote access server allows you to enable the following different levels of event logging:

Log errors only

Log errors and warnings

Log the maximum amount of information

Disable event logging

If a connection fails, select the Log the maximum amount of information option and try the connection again. This will record all events associated with the connection process in the system event log. Logging consumes system resources and should be used sparingly to help identify network problems. So once you



are done viewing the remote access events or identifying the problem, immediately reset logging to its default value by selecting Log errors only.

Internet Authentication Service (IAS)

IAS and RRAS share the same remote access policies and authentication and accounting logging capabilities. When RRAS is configured for Windows authentication, the local policies and logging are used. When RRAS is configured as a Remote Access Dial-In User Service (RADIUS) client to an IAS server, the policies and logging of the IAS server are used.

IAS supports RADIUS accounting, which an administrator can use to track network usage for auditing and billing purposes. Third-party products can be used to analyze RADIUS accounting data to provide charge-back, performance, and exception reports.

Support for the RADIUS standard allows IAS to collect the usage (accounting) records returned by NAS at a single point and create a log file. IAS logs audit information, for example, authentication accepts and rejects, and usage information, for example, logon and logoff records, to log files. This information is useful for keeping track of usage and correlated authentication information with accounting records, for example,



to discover missing records or instances of over-billing. IAS logs can also be used to track events and troubleshoot a failed connection.

IAS log files can be created in two formats:

Database: The database format allows you to keep track of a predetermined set of attributes. Use this format if you want to import data directly into a database. You can analyze the data in the database by using third-party data-analysis software.

IAS format: The IAS format is more detailed and can contain information about all attributes. Use this format if you need to record more detailed information than what the database log format allows.

While the IAS log file contains all the IAS user-related events, the IAS service and system-related events are recorded in the Event log files.

RADIUS accounting RADIUS accounting provides the following benefits:

Real-time data collection.



Accounting data collected at a centralized place.

The RADIUS accounting process

The RADIUS server has access to user account information and can check remote access authentication credentials. If the user's credentials are authentic and the connection attempt is authorized, the RADIUS server authorizes the user's access based on specified conditions and logs the remote access connections as accounting events.

When a client is configured to use RADIUS accounting, at the start of service delivery, it generates an accounting start packet describing the type of service being delivered and the user to whom it is being delivered. The packet is then sent to the RADIUS accounting server, which sends back an acknowledgment that the packet has been received. At the end of service delivery, the client generates an accounting stop packet describing the type of service that was delivered and statistics (optional), such as elapsed time, input and output octets, or input and output packets. It then sends that data to the RADIUS accounting server, which sends back an acknowledgment that the packet has been received.

The accounting-request packet (the start or stop packet) is submitted to the RADIUS accounting server through the network. If no response is returned within a length of time, the request is sent again repeatedly.



The client can also forward requests to an alternate server or servers if the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. If the RADIUS accounting server is unable to successfully record the accounting packet, it does not send an accounting-response acknowledgment to the client. For example, when the log file gets filled, IAS starts discarding accounting packets. This prompts the NAS to switch to the backup IAS server.

You can monitor IAS by using Windows 2000–based tools, such as Event Viewer or System Monitor, or by using Simple Network Management Protocol (SNMP). For more information on accounting, authentication, authorization and troubleshooting IAS, see the article, “Internet Authentication Service for Windows 2000 ”

Iasparse.exe toolIAS creates a log file based on the authentication and accounting requests received from the NAS when using RADIUS authentication. The remote access server logs similar information when using Microsoft Windows 2000 authentication. Unlike the database import log files, which use a fixed sequence of attributes, the sequence of the attributes in IAS-formatted log files depends on the format used by the NAS. IAS log files are multi-language and are written in UTF-8.




The log file generated by both these services is very cryptic to an ordinary user. To present this largely incomprehensible log file information in a user-friendly way, the Windows 2000 Server Resource Kit includes Iasparse.exe (in the Diag.cab folder), a command–line tool used to parse and read IAS log files. This command-line tool parses IAS and remote access server logs and converts them into a readable format.

The following list shows the advantages of using Iasparse.exe:

Simplifying administration of the service.

Using logs for tracking accounting information, such as logon and logoff records for billing purposes.

Troubleshooting connections where the user fails to authenticate.

Calculating billing information. For this, you can use TRU Access Manager Limited Edition, a network accounting application developed by Telco Research that ships with the Windows 2000 Server Resource Kit.

Running diagnostics, such as obtaining information about the RADIUS attributes received and sent.



Authentication and accounting logging

Windows authentication and accounting loggingA remote access server running Windows 2000 supports the logging of authentication and accounting information for remote access connections in local logging files when Windows authentication or Windows accounting is enabled. Windows logging is separate from the events recorded in the system event log. You can use the logged information to track remote access usage and authentication attempts.

Authentication and accounting logging is especially useful for troubleshooting remote access policy issues. For each authentication attempt, the name of the remote access policy that either accepted or rejected the connection attempt is recorded.

You can configure the authentication or accounting activity to be logged and configure log file settings from the properties dialog box of the Remote Access Logging folder in the Routing and Remote Access snap-in.

From the following options on the Settings tab, you can choose the events you want to log:

Log accounting requests, for example, accounting start or stop. Recommended.



Log authentication requests, for example, access-accept or access-reject. Recommended.

Log periodic status, for example, interim accounting requests.

On the Local File tab, you can choose the file format that you want to use for your log file.

Database compatible file format

IAS format

Using this property sheet, you can also set new log time periods and a path to the log file directory.

If the remote access server is configured for RADIUS authentication and accounting and the RADIUS server is a Windows 2000 computer running IAS, the authentication and accounting logs are stored in the SystemRoot\System32\LogFiles folder on the IAS server computer.

Unlike IAS-formatted log files where the sequence of attributes depends on the format used by the access server, database import log files present data in a standard sequence and use a structure that is identical, regardless of the access server that sends the data. This consistent sequence and structure allows data to be easily imported into a database and helps simplify accounting and authentication records.



Network MonitorMicrosoft Network Monitor is a packet capture and analysis tool (installed as an optional networking component) supplied with Windows 2000 Server that helps analyze packets of data that are transferred over the network. It provides information about the network traffic that flows to or from a server. Using Network Monitor, you can capture and analyze information that helps you run your network smoothly, identify new patterns, and prevent, diagnose, and solve different types of network problems. You can also identify patterns that indicate whether changes such as an upgrade, might be worthwhile.

Network Monitor uses a Network Driver Interface Specification (NDIS) feature to copy all frames it detects to its capture buffer, which is a resizable storage area in memory. The buffer is a memory-mapped file and occupies disk space. The default size of this buffer is 1 megabyte (MB) but you can adjust the size manually as needed.

Because Network Monitor uses the local only mode of NDIS instead of the promiscuous mode (in which the network adapter passes on all frames sent on the network), you can use Network Monitor even if your network adapter does not support promiscuous mode. Networking performance is not affected when you use an NDIS driver to capture frames. Putting the network adapter in promiscuous mode can add 30 percent or more to the load on the CPU.



Using Network Monitor to troubleshootOnce you install Network Monitor, you can capture to a file all the frames sent to or received by the network adapter of the computer on which it is installed. These captured frames can then be viewed or saved as files and sent to Microsoft support for analysis.

For dial-up or VPN connections, you can capture and view the traffic sent between a remote access server and a remote access client during the connection process and also during data transfer. However, you cannot interpret the encrypted or compressed portions of the remote access traffic using Network Monitor.

The proper interpretation of the remote access traffic using Network Monitor requires an in-depth understanding of PPP, PPTP, IPSec, and other protocols.

TracingTracing is the recording of the sequence of programming functions called by a component and associated process data. The tracing information can be recorded in a log file and used to analyze network problems. To use tracing to gather information for troubleshooting, enable tracing for the remote access components and try the connection again. Because tracing uses system resources, disable tracing when you are done collecting information in the trace log files.



Tracing is disabled by default. You can use the Netsh command to enable and disable tracing for specific components or for all components. To enable and disable tracing for a specific component, use the following syntax:

netsh ras set tracing Component enabled|disabled

Component is a component in the list of RRAS components found in the Windows 2000 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. For example, to enable tracing for the RASAUTH component, use the following command:

netsh ras set tracing rasauth enabled

To enable tracing for all components, use the following command:

netsh ras set tracing * enabled

You can also enable tracing for each component by setting registry values under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. Each component is capable of tracing and appears as a subkey (such as RASAUTH) under the preceding registry key. You can enable and disable tracing for components even while the router is running.



Caution: Remember to back up valuable data before making changes to the registry.

Configure the following registry value entries for each protocol key:

EnableFileTracing REG_DWORD 1: You can enable logging tracing information to a file by setting EnableFileTracing to 1. The default value is 0.

FileDirectory REG_EXPAND_SZ Path: You can change the default location of the tracing files by setting FileDirectory to the path you want. The file name for the log file is the name of the component for which tracing is enabled. By default, log files are placed in the systemroot\Tracing folder.

FileTracingMask REG_DWORD LevelOfTracingInformationLogged: Determines how much tracing information is logged to the file. The default value is FFFF0000.

MaxFileSize REG_DWORD SizeOfLogFile: You can change the size of the log file by setting different values for MaxFileSize. The default value is 10000 (64 KB).

Tracing information can be very complex and detailed. Usually, this information is useful only to Microsoft support professionals, or to network administrators who are very experienced with the RRAS.



Oakley loggingYou can use the Oakley log to view details about the SA establishment process. The Oakley log is enabled in the registry. It is not enabled by default. To enable the Oakley log, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\EnableLogging registry setting to 1. The Oakley key does not exist by default and must be created.

After it is enabled, the Oakley log, which is stored in the systemroot\Debug folder, records all IPSec SA negotiations. A new Oakley.log file is created each time the IPSec Policy Agent is started and the previous version of the Oakley.log file is saved as Oakley.log.sav.

To activate the new EnableLogging registry setting after modifying its value, stop and start the IPSec Policy Agent and related IPSec services by running the following sequence of commands:

1.Stop the RRAS using the net stop remoteaccess command.

2.Stop the IPSec services using the net stop policyagent command.

3.Start the IPSec services using the net start policyagent command.

4.Start the RRAS using the net start remoteaccess command.



PPP loggingPoint-to-Point Protocol (PPP) is the suite of protocols used to establish a link, authenticate, and assign IP addresses to remote access connections. To establish a successful dial-up connection to the Internet, you need to authenticate and register the network. You can either authenticate using plain text (terminal mode) and then start a PPP session or allow authentication to take place under PPP.

You can enable logging to a PPP log file to help diagnose PPP-related connectivity problems.

Based on the entries in the PPP log, you can tell whether a connection failed or not.

If a PPP session is not started, then there are no entries made to the PPP log for the connection attempt. This lack of entries signifies that the connection failed on or before plain-text logon.

If you see entries in the PPP log, then the nature of the entries can provide a clue as to what failed during the connection attempt. When all other sources of information fail, PPP logs are the best place to review.

For RRAS, you can enable PPP logging from the Event Logging tab on the properties of a remote access server. For a Windows 2000 remote access client, you can enable PPP logging using netsh.



After you enable logging, the computer logs all PPP activity to the ppp.log file in the SystemRoot\Tracing folder. Because PPP logging uses system resources and hard disk space, it is recommended that you turn off logging when you are finished troubleshooting.

Enabling PPP logging for Routing and Remote Access1. Open the Routing and Remote Access snap-in.

2. In the tree pane, right-click the server for which you want to enable logging, and then click Properties.

3. Click the Event Logging tab.

4. Select the Enable Point-to-Point Protocol (PPP) logging check box.

5. Click OK.

6. Click OK when prompted to restart the router.

Enabling PPP logging by using Netsh.exe1. Open a command prompt.



2. Type netsh ras set tracing ppp enabled.

Disabling PPP Logging1. Open a command prompt.

2. Type netsh ras set tracing ppp disabled.



Common remote access problemsRemote access problems can typically be categorized into the following types of issues:

Users cannot connect.

Users can connect but cannot authenticate.

Users can connect and authenticate but cannot reach locations beyond the remote access server.

Users can connect, authenticate, and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing).

Users cannot connectIf the connection attempt is rejected and all configuration properties indicate that it should have been accepted, try to verify configuration details in the areas listed below.



Fax and modem troubleshooting: If the Windows 2000 Fax service and the RRAS are sharing the same modem, verify that the

modem supports adaptive answer. If the modem does not support adaptive answer, you must disable fax on the modem to receive incoming remote access connections.

If you are using an external modem, verify that your modem is turned on.

Lower the modem speed.

Replace the existing modem with a different one.

Run modem diagnostics to ensure that the COM port is configured correctly and that the modem is functioning properly.

Dial a different phone number if your ISP or the corporate RAS server that you are connecting to allows you to do so.

Use a different phone cable.



Service: Ensure that the RRAS is enabled and running on the remote access server.

Verify the dial-up or VPN ports on the remote access server are configured to allow inbound remote access connections.

Ensure that your dial-up equipment is working properly.

Verify all of the dial-up ports on the remote access server are already connected. If they are, the connection will fail.

Protocols: Ensure that the protocols being used by the remote access clients are enabled for routing.

IP address pool: If your remote access server is configured with a static IP address pool, verify that there are

enough addresses in the pool. In this case, the remote access server will be unable to allocate an IP address to the remote access client. In this situation, if the remote access client is only



configured to use TCP/IP as a LAN protocol, the connection attempt is denied.

IPX settings: 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 on the IPX tab of the properties of a remote access server in the Routing and Remote Access snap-in.

If the remote access server is configured with a range of IPX network numbers, verify that the IPX network numbers in that range are not being used elsewhere on your IPX internetwork.

Domain settings: For a remote access server that is a member of a Windows 2000 native-mode domain, verify

that the remote access server has actually joined the domain.

Verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows 2000 Compatible Access" command for:



o A Windows NT version 4.0 Service Pack 4 and later remote access server that is a member of a Windows 2000 mixed mode domain.

o A Windows 2000 remote access server that is a member of a Windows NT 4.0 domain that is accessing user account properties for a user account in a trusted Windows 2000 domain.

If not, issue the net localgroup "Pre-Windows 2000 Compatible Access" everyone /add command on a domain controller computer and then restart it.

For a Windows NT version 4.0 Service Pack 3 and earlier remote access server that is a member of a Windows 2000 mixed mode domain, verify that Everyone group has been granted list contents, read all properties, and read permissions to the root node of your domain and all sub-objects of the root domain.

User account: On the properties of the user account, verify that the user account has not been disabled or is

not locked out due to remote access account lockout.



Verify that the password on the user account has not expired.

For an administrator-level account with an expired password, use another administrator-level account to reset the password.

Remote access policies: It is possible that the connection properties of the remote access client are in conflict with the

remote access policy settings on the remote access server, thereby preventing the users from connecting. Make sure that the parameters of the connection have appropriate permissions through remote access policies.

For the connection to be accepted, the settings of the connection attempt must:

o Match the conditions of at least one remote access policy.

o Be granted remote access permission through the user account (set to Allow access), or through the user account (set to Control access through Remote Access Policy) and the



remote access permission of the matching remote access policy (set to Grant remote access permission).

o Match the settings of the profile.

o Match the settings of the dial-in properties of the user account.

Remote access server settings: Make sure that the settings of the remote access policy profile are not in conflict with the

properties of the remote access server. The properties of the remote access policy profile and the properties of the remote access server both contain settings for:

o Multilink

o Bandwidth allocation protocol

o Authentication protocols

If the profile settings of the matching remote access policy are in conflict with the settings of the remote access router, then the connection attempt is denied. For example, if the matching remote access policy



profile specifies that the EAP-TLS authentication protocol must be used and EAP-TLS is not enabled through the properties of the remote access server, then the remote access server denies the connection attempt.

Possible error messages The following common Windows 2000 remote access client errors occur when users are not able to connect to the remote access server.

Error 651 This error is a sign that the modem or any other connecting device has reported an error.

The remote access server stops responding while connections are in progress. It could also be that the remote access server is not responding because its PPTP ports are busy in active calls. The connection fails when the PPTP server sends a TCP disconnect to the client. If all the ports available on the server are busy, the server waits for 30 seconds before sending a TCP disconnect to the client.

When using PPTP, this error can also occur if GRE is not being forwarded between the remote access client and the remote access server. When GRE sends a packet with data, it sends the packet with a



sequence number for tracking purposes. The type of GRE response is based on whether data is included in the response packet or if the packet is an acknowledgement only. If the response packet includes data, then you see a sequence number and an acknowledgement number towards the bottom of the packet.

If the GRE packet is an acknowledgement only however, you may have some difficulty figuring out whether an acknowledgment has ever been sent. This however relates to a different issue of parsing inconsistencies with Microsoft Network Monitor. For more information, see the KB article Q241251 and Q241100.

Error 692

If you see this error, complete the checklist on Fax and Modem Settings earlier in this section.

Error 678 For PPTP/L2TP connections, this error represents a lack of response from the remote access server and is referred to as the ‘no answer’ error.

Make sure you are connected to the Internet and use the checklist provided earlier in this section to ensure that you are connecting to the correct server name or IP address.



Error 734 The above errors cover issues ranging from a bad phone line or a modem dropping PPP packets to multiple configuration problems on the remote access server. Please read the checklist above to assist troubleshooting.

Users can connect but cannot authenticate

This is a situation where remote access clients can connect to the remote access server but fail to authenticate. If authentication fails, verify settings in the following areas:

Authentication: Verify that the remote access client and the remote access server in conjunction with a remote access policy are enabled to use at least one common authentication method and at least one common encryption method.

If you are using MS-CHAP, verify that you are not using a user password over 14 characters long. If so, either use a different authentication protocol or change the password so that it is 14 characters or less in length.



Check the configuration of the authentication provider. The remote access server can be configured to use either Windows or RADIUS to authenticate the credentials of the remote access client.

If you are using Windows authentication for a remote access server that is a member of a mixed-mode or a native-mode Windows 2000 domain, verify that the remote access server computer account is a member of the RAS and IAS Servers security group. You can use the netsh ras show registeredserver command at the Windows 2000 command prompt to view the current registration. If your server is not registered, use the netsh ras add registeredserver command to register the server in a specified domain.

If you are using RADIUS authentication, verify that the remote access server computer can communicate with the RADIUS server.

If you are using RADIUS authentication for a remote access server and the RADIUS server is a computer running Windows 2000 and the Internet Authentication Service (IAS) that is a member of a mixed-mode or a native-mode Windows 2000 domain, verify that the IAS server computer account is a member of the RAS and IAS Servers security group. You can use the netsh ras show registeredserver command at the Windows 2000 command prompt to view the current registration. If



your server is not registered, use the netsh ras add registeredserver command to register the server in a specified domain.

If you add or remove the remote access server computer to the RAS and IAS Servers security group, the change does not take effect immediately because of how Windows 2000 caches Active Directory™ directory service information. For the change to take effect immediately, you need to restart the remote access server.

Client credentials: Incorrect client credentials may prevent successful authentication. Check to see if 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.

L2TP/IPSec authentication issuesThe following list shows the most common problems that cause L2TP/IPSec connections to fail:

No certificate



By default, L2TP/IPSec connections require that the remote access server and remote access client exchange computer certificates for IPSec peer authentication. Check the computer certificate stores of both the remote access client and remote access server using the Certificates snap-in to ensure that a suitable certificate exists.

Incorrect certificate

If certificates exist, they must be verifiable. Unlike manually configuring IPSec rules, the list of certification authorities (CAs) for L2TP/IPSec connections is not configurable. Instead, each computer in the L2TP connection sends a list of root CAs to its IPSec peer from which it accepts a certificate for authentication. The root CAs in this list correspond to the root CAs that issued computer certificates to the computer. For example, if Computer A was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPSec peer during main mode negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the IPSec peer, Computer B, does not have a valid computer certificate issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.

The VPN client must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the VPN server trusts. Additionally, the



VPN server must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the VPN client trusts.

By default, L2TP/IPSec connections require that the remote access server and remote access client exchange computer certificates for IPSec peer authentication. Check the computer certificate stores of both the remote access client and remote access server using the Certificates snap-in to ensure that a suitable certificate exists.

A NAT between the remote access client and remote access server

If there is a NAT between a Windows 2000 L2TP/IPSec client and a Windows 2000 L2TP/IPSec server, you cannot establish an L2TP/IPSec connection. IPSec NAT-T is not yet available for Windows 2000 from Microsoft.

Firewall between the remote access client and remote access server

If there is a firewall between a Windows 2000 L2TP/IPSec client and a Windows 2000 L2TP/IPSec server, you cannot establish an L2TP/IPSec connection, verify that the firewall is allow L2TP/IPSec traffic to be forwarded. For more information, see "Integrating VPN Servers and Firewalls" in this article.



One of the best tools for troubleshooting IPSec authentication issues is the Oakley log. For more information, see "Oakley log" in this article.

EAP-TLS authentication issuesWhen EAP-TLS is used for authentication, the remote access client submits a user certificate and the authenticating server (the remote access server or the RADIUS server) submits a computer certificate.

For the authenticating server to validate the certificate of the remote access client, the following must be true for each certificate in the certificate chain sent by the remote access client:

The current date must be within the validity dates of the certificate.

When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

The certificate has not have been revoked.

Issued certificates can be revoked at any time. Each issuing CA maintains a list of certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). By default, the authenticating server checks all the certificates in the remote access client’s certificate



chain (the series of certificates from the remote access client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this topic.

To view the CRL distribution points for a certificate in the Certificates snap-in, obtain the certificate properties, click the Details tab, and then click the CRL Distribution Points field.

The certificate revocation validation only works as well as the CRL publishing and distribution system. If the CRL in a certificate is not updated often, a certificate that has been revoked can still be used and considered valid because the published CRL that the authenticating server is checking is out of date.

The certificate has a valid digital signature.

CAs digitally sign certificates they issue. The authenticating server verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature.

The remote access client certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) (OID 1.3.6.1.5.5.7.3.2) and must either contain a UPN of a valid



user account or FQDN of valid computer account for the Subject Alternative Name property of the certificate.

To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field. To view the subject alternative name property for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Subject Alternative Name field.

Finally, to trust the certificate chain offered by the remote access client, the authenticating server must have the root CA certificate of the issuing CA of the remote access client certificate installed in its Trusted Root Certification Authorities store.

Additionally, the authenticating server verifies that the identity sent in the EAP-Response/Identity message is the same as the name in the Subject Alternative Name property of the certificate. This prevents a malicious user from masquerading as a different user from that specified in the EAP-Response/Identity message.



If the authenticating server is an IAS server, the following registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 can modify the behavior of the EAP-TLS when performing certificate revocation.

IgnoreNoRevocationCheck

When set to 1, IAS allows EAP-TLS clients to connect even when it does not perform or cannot complete a revocation check of the client's certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate does not include CRL information.

IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the server completes a revocation check of the client's certificate chain (including the root certificate) and verifies that none of the certificates have been revoked.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties.

IgnoreRevocationOffline



When set to 1, IAS allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network. IgnoreRevocationOffline is set to 0 by default. IAS does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates has been revoked. When it cannot connect to a server that stores a revocation list, EAP-TLS considers the certificate to have failed the revocation check.

Setting IgnoreRevocationOffline to 1 prevents certificate validation failure because poor network conditions prevented their revocation check from completing successfully.

NoRevocationCheck

When set to 1, IAS prevents EAP-TLS from performing a revocation check of the remote access client's certificate. The revocation check verifies that the remote access client’s certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

NoRootRevocationCheck

When set to 1, IAS prevents EAP-TLS from performing a revocation check of the remote access client's root CA certificate. NoRootRevocationCheck is set to 0 by default. This entry only eliminates the



revocation check of the client's root CA certificate. A revocation check is still performed on the remainder of the remote access client's certificate chain.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or is expired.

All of these registry settings must be added as a DWORD type and have the valid values of 0 or 1. The remote access client does not use these settings.

For the remote access client to validate the certificate of the authenticating server for either EAP-TLS authentication, the following must be true for each certificate in the certificate chain sent by the authenticating server:

The current date must be within the validity dates of the certificate.

When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

The certificate has a valid digital signature.



CAs digitally sign certificates they issue. The remote access client verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature.

Additionally, the authenticating server computer certificate must have the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field.

Finally, to trust the certificate chain offered by the authenticating server, the remote access client must have the root CA certificate of the issuing CA of the authenticating server certificate installed in its Trusted Root Certification Authorities store.

Notice that the remote access client does not perform certificate revocation checking for the certificates in the certificate chain of the authenticating server’s computer certificate. The assumption is that the remote access client does not yet have a physical connection to the network, and therefore cannot access a Web page or other resource to check for certificate revocation.



Possible error messages Listed below are some of the most common remote access client errors that occur when users are not able to authenticate.

Error 766 Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate. You will see this error message when such a certificate is not available.

Typically, this error is generated on a remote access server that has active L2TP ports configured, the remote access service started but there is no certificate in the computer certificate store. This generates an event log message that tells the administrator that L2TP ports will not be able to accept calls until a certificate is acquired and RRAS is restarted.

Error 781 This error message appears when the connection requires a certificate, and no valid certificate was found on the client while trying to make an L2TP call. However, this error is quite similar to Error 766 and troubleshooting methods for both these error messages will follow the same path.



Users can connect and authenticate but cannot reach locations beyond the remote access serverYou may encounter situations where users can connect and authenticate but are not able to connect to any computer on the network to which the remote access server is attached. In such a situation, the following configuration details may help:

LAN protocols Verify that the protocols being used by the remote access clients are either enabled for routing on the remote access server.

TCP/IP packet filters You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic allowed on the remote access connection. Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the remote access server (or the RADIUS server if IAS is used) that are preventing the sending or receiving of TCP/IP traffic.



IP address allocation settings In a situation where a static IP address pool is configured but there are no routes back to the remote access clients, you could try one of the following solutions:

o If the remote access server is configured to use a static IP address pool and the pool has one or more off-subnet address ranges, verify that the routes for the off-subnet address ranges of the static IP address pool are reachable by the hosts and routers of the intranet. If not, then IP routes consisting of the address ranges of the static IP address pool, as defined by the IP address and mask of each range, must be added to the routers of the intranet. Otherwise, the routing protocol of your routed infrastructure on the remote access server must be enabled. If the routes to the remote access client subnets are not present, remote access clients cannot receive traffic from locations on the intranet. A route for the network is implemented either through static routing entries or through a routing protocol, such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP).

o If the static IP address pool consists of ranges of IP addresses that are a subset of the range of IP addresses for the network to which the remote access server is attached, verify



that the ranges of IP addresses of the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.

If the remote access server is configured to use DHCP for IP address allocation and no DHCP server is available, the remote access server allocates addresses from the Automatic Private IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254. Allocating APIPA addresses for remote access clients works only if the network to which the remote access server is attached is also using APIPA addresses.

If the remote access server is using APIPA addresses when a DHCP server is available, verify that the proper adapter is selected from which to obtain DHCP-allocated IP addresses. You can manually choose a LAN adapter from the IP tab on the properties of a remote access server in the Routing and Remote Access snap-in.

IPX settings If Microsoft remote access clients using only the IPX protocol are unable to create file and print sharing connections to servers located beyond the remote access server, then NetBIOS over IPX broadcast forwarding must be enabled on the Internal interface and the appropriate LAN interfaces. For



IP-based remote access clients, IP routing should be enabled. Verify that IP routing is enabled on the IP tab on the properties page of the server.

If network access is denied for IPX or AppleTalk-based remote access clients, verify that network access is allowed on the IPX or AppleTalk tabs on the properties of a server. If you do not have one or more of these tabs, then the corresponding network protocol is not installed on the server.

Users can connect, authenticate and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing).In this situation, remote access clients will not be able to see all the workgroups, domains, and computers in My Network Places, also known as browsing (not to be confused with Internet browsing). However, using \\servername allows remote access clients to view the shared resources of all computers. Given below are some possible troubleshooting options:

General routing problems could be preventing the remote access clients from accessing the browse masters through the remote access server.

Faulty name resolution could also cause browsing problems. Name resolution (using WINS, DNS,



or LMHOSTS files) between all browsing clients and browse masters is critical and must be working properly throughout the network for browsing to operate correctly. Verify that name resolution is working correctly.

Check for NetBIOS broadcasts on the network. These broadcasts typically do not propagate across a router and the information received by browse masters is very sensitive to the configuration of routers on an IP internetwork. Since the browser roles are determined by broadcast elections, NetBIOS broadcasts must not be forwarded. Unpredictable behavior can occur if NetBIOS broadcast traffic is forwarded in one direction but not the other. This can cause a continuous cycle of browser elections.

If you have implemented full domain browsing by using only entries in LMHOSTS files on all computers, you are limiting browsing to the local domain. This could be preventing remote access clients from browsing the network through the remote access server. It is recommended that you implement WINS for name resolution and better browsing support. Even if WINS has been implemented in the domain, non-WINS clients will still need entries in their LMHOSTS files to browse across an IP router.

Another step that can be taken to resolve browser problems is to capture network traffic with a



protocol analyzer such as Microsoft Network Monitor. To directly view the communication between browsers, the Computer Browser service can be stopped and then restarted using the Service snap-in. Unfortunately, there is no guarantee that a computer assumes the same role that it had before the Computer Browser service is restarted.

You can monitor the master and backup browsers within a workgroup or domain using the command-line tool Browstat.exe. This tool is a powerful command-line browser monitoring and querying tool that ships as a Resource kit utility. For more information, see Folder Listing of the Support Tools Included in Windows 2000. To check the procedure for installation, see Install Windows 2000 support tools.

Verify the client is connected to a master browser. If the remote access server that the client is connecting to is not a master browser, then for browsing to function properly, the client should either get the broadcast messages from the other side of the remote access server or be able to reach the master browser that is receiving the broadcast messages. You can approach this problem in the following two ways:


http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q301423&





Verify it is possible to configure the remote access server to forward NetBIOS broadcast messages.

If broadcast cannot be enabled, try to make the remote access server the master browser. This way it will receive all broadcast messages and have lists that can be sent in response to a browse request sent by the remote access client.

To troubleshoot problems with the browser service, the Administrator must have full knowledge of the network subnet boundaries and router configurations on the network.

Miscellaneous remote access solutions Anytime you encounter a failed remote access connection, here are a few simple things you can do to understand the nature of the error:

Server system event log: Open the system event log and look for errors that relate to a failed connection attempt.

Client tracing logs: Review all client logs to get as much information as you can on events that



failed on the client side.

Server tracing logs: Review all server logs to get as much information as you can on events that failed on the server side.

If you are not getting the correct name server configuration on client, try the following:

Verify configuration of the DHCP Relay Agent: The DHCP Relay Agent should be configured with the IP address of at least one DHCP server on your network and have the Internal interface added and enabled for relaying DHCP packets.

If you are not using the DHCP Relay Agent, verify the name server configuration of the remote access server.



System Event Log Error IDs

Common System Event Log Error IDsThis chapter lists the top few event log error IDs, their description, the actual error messages that you might see, suggestions for troubleshooting and references to knowledge base articles, if any.

Event ID # 20050

DescriptionThe Windows NT 4.0 RRAS logs the Event ID 20050 when:

You are trying to configure RRAS and attempting to connect.

The remote access server does not accept a PPTP connection.

The remote access server running PPTP intermittently rejects client connections over an RRAS connection.



The following error message is logged in the event log on the PPTP server:Event ID: 20050 Source: Remote Access Description: The user Domain\User connected to port VPNx has been disconnected because the computer could not be projected onto the network.

The following table shows some questions that could facilitate troubleshooting.

Question Answer

Are you having problems with network services such as DHCP, WINS, or DNS? Yes

Are you having problems with WINS? No

Are you having problems with DHCP? No

Are you having problems integrating DNS and WINS? No

Are you having problems configuring DNS? No

Are you having problems with DNS Zone Transfers? No



Problem resolutionExamine the IPCP and PPP logs on the computer running RRAS. An example of a log examination could be as follows:

The call to activate a new route is not working properly and displays error 31.IPCP.LOG: [205] 02:03:30: IPCP: RasActivateRoute done (31)PPP.LOG: [205] 02:03:30:421: RasIPCPProjectionNotification returned 31

The RasActivateRoute entry in the log file is a reference to an API that submits the REQTYPE_ACTIVATEROUTE request that makes a route entry. In this case, the error indicates that the computer was not able to activate this route. This error is a result of projecting or "plumbing" the new route into the route table on the RRAS server for the connecting client. This only occurs when all the existing addresses have been used at least once and the clients connecting are actually recycling older, previously used IP addresses.

See hot fix in Q233048 for Microsoft RRAS Update for Windows NT Server version 4.0


http://support.microsoft.com/default.aspx?scid=kb;EN-US;q233048


KB articles

The following articles refer to related solutions:

Q162927 - Telnetting to Port 53 May Crash DNS Service

Q164982 - Lack of Secondary Address May Cause DNS Service to Hang

Q168033 - DNS Server Fails to Start After Promoting Secondary to Primary

Q171781 - DNS Server Fails to Start Due to Unavailable RPC Server Error

Q177119 - Unable to Create Zones in DNS Manager

Q159310 - Updated Version of Dns.exe Fixes Several Problems

Q171649 - DNS Err Msg: The Handle is Invalid

Q169461 - Access Violation in DNS.EXE Caused by Malicious Telnet Attack

Q169371 - DNS Error Message: No More Endpoints

Q154985 - DNS Registry Key Not Updated When Changing Zone Type



Q173676 - Client Cannot Resolve MX Record via Microsoft DNS Server

Q170518 - DNS Admin Fails When Managing Large Number of Zones

Event ID # 20189 PPTP clients cannot connect to the Windows 2000 PPTP server.

Description: When a Microsoft Windows 2000 Server is configured as a PPTP server and PPTP clients from Microsoft Windows NT, Windows 2000, Windows 95 or Windows 98 try to establish a PPTP session, they receive the following error message:

Error 649 Login failed: username, password, or domain was incorrect.

The Windows 2000 PPTP server logs the following error message: Event ID 20078 The account for user \username connected on port VPN3-127 does not have Remote Access privilege. The line has been disconnected.



Event ID 20189 The user \username connected from x.x.x.x but failed an authentication attempt due to the following reason: The user tried to connect using an unauthorized dial-in media.

Problem resolutionTo resolve this, try the following procedure:

1. Open the Routing and Remote Access snap-in.

2. Expand the node under your PPTP server's name.

3. Click the Remote Access Policies folder.

4. Right-click the default policy named Allow access if dial-in permission is enabled, and then click Properties.

5. Click Edit Profile in the Properties dialog box.

6. On the Dial-in Constraints tab, complete one of the following tasks:

Clear the Restrict Dial-in Media option.

OR



Select Restrict Dial-in Media, and then select Ethernet and VPN from the list of options available.

7. Click Apply, and then click OK.

KB articles

Q266460 PPTP Clients Cannot Connect to Windows 2000 PPTP Server.

Event ID # 1051Among the leading cause for customer service calls are authorization problems with the DHCP server. These problems generate Event 1051.

Description The DHCP Server service has not started.

Cause: It is possible that the DHCP was not authorized in the AD.

The DHCP server stopped running.


http://support.microsoft.com/default.aspx?scid=kb;en-us;Q266460


Cause: If your server had been issuing DHCP leases to clients for some time and then suddenly stopped running then it has been unauthorized.

A new DHCP server is not able to authorize in a network that already has authorized DHCP servers.

Existing DHCP servers might get unauthorized during the attempt to authorize a new DHCP server.

You may receive one of the following error messages:The specified servers are already present in the Directory Service-OR-DHCP Server not authorized:Error:Event ID: 1051Source: DHCPServerThe DHCP/BINL service has determined that it is not authorized to service clients on this network for the Windows domain: yourdomainname.com



Problem resolution Logon with an account that has enterprise administrator privileges and authorize the server using the Active Directory Sites and Services snap-in. If that does not resolve your problem, check the following possibilities:

It is possible that an administrator from another site may have unauthorized the server. Reauthorize the server, and clients should be able to log on successfully. (See procedure later in this section on how to reauthorize your DHCP server.)

It could also be that the server was never touched since the time when the server was promoted to Active Directory. In this case, the server will continue to work. However, the first time that you access the DHCP snap-in, you will have to authorize it.

A last possibility is that some level of corruption could have occurred in the Active Directory configuration.

In some cases, you might need to perform one or both of the following procedures:



Delete the DHCP servers in Active Directory Sites and Services, and then reauthorize the DHCP servers.

Authorize the DHCP servers by using Adsiedit.msc, which is an administrative tool that is included in the support tools for Windows 2000. Adsiedit.msc is installed when you install the support tools from the Support\Tools folder on the Windows 2000 Server CD-ROM or the Windows 2000 Professional CD-ROM.

To learn more about how to use Adsiedit.msc, see Authorizing the DHCP Servers by Using Adsiedit.msc in the KB article # Q306925.

To resolve the authorization problem, you need to re-authorize your DHCP server. To do so:

1. Go to Start, Programs, Administrative Tools, DHCP to start the DHCP snap-in.

2. Right-click DHCP in the upper-left corner of the DHCP snap-in, and then select Manage Authorized Servers. If your server is not already listed, select Authorize, and enter the IP address of the server you want to authorize.

3. When prompted, select Yes to verify that the IP address is correct.



4. Restart the DHCP server.

-OR

1. Start the Active Directory Sites and Services MMC.

2. Click Services, and then click Net Services.

3. Delete the DHCP servers that you cannot add to the Active Directory.

4. Either force replication for the Active Directory to the other sites or wait for the replication cycle.

5. Reauthorize the DHCP servers.

You can also change the rogue detection settings to try and resolve this problem. Try the following:

1. Set DisableRogueDetection to 1.

Set the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCPServer\Parameters

Value name: DisableRogueDetectionData type: REG_DWORD



Value data: 1

2. Restart the server for the setting to take effect.

Changing authorization intervals:

A Windows 2000 DHCP server verifies authorization status with the Active Directory when it starts and then does so again approximately every 60 minutes. If the server fails, it retries every five minutes. This process can consume as much as 1 MB of bandwidth. So if you have multiple DHCP servers, the authorization process can slow down performance considerably.

To resolve this issue:

1. Upgrade each DHCP Server to Windows 2000 SP2, which has been optimized to reduce the inefficiency in the authorization process.

2. Use Regedt32 to Add Value name RogueAuthorizationRecheckInterval, a REG_DWORD data type, at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCPServer\Parameters.

3. Change the minutes between authorizations from the default value of 60 minutes to a number that



yields acceptable performance.

As mentioned before, you can disable the Rogue Detection feature by setting DisableRogueDetection to 1.

KB articles

Q306925: Cannot Authorize New DHCP Server in Active Directory

Q303525: Invalid LDAP Filter for DHCP Server Authorization

Q299363: An Event ID 1051 Message May Be Displayed After You Install Service Pack 2

Event ID # 20187 Index



DescriptionThe users <domain name>\<user id> failed an authentication attempt due to the following reason:

The current configuration only supports local user accounts.

Problem resolutionEdit the registry HKEY_CURRENT_USER\RemoteAccess\Profile\<DUN name> and delete the "Domain" string.

-OR-

Enter the host computer name in the Domain field in the password dialog box on the client computer.


DescriptionYou may receive an error message when you attempt to connect your Windows 2000-based computer that uses RAS to a Windows NT Server 4.0-based computer that uses the RRAS Update.



The Windows 2000-based computer displays the following error message when it cannot establish a connection:

Retrying authentication... Error 691: Access denied because username and/or password is invalid on the domain.

The Windows NT Server 4.0-based computer logs the following error messages in the system log Event ID: 20049 Source: Router Type: Warning Description: The user connected to port %Name% has been disconnected due to an authentication timeout.

Problem resolutionYou may get this message if your remote access server is located behind a firewall. To resolve this issue, make sure that the firewall is configured to allow VPN traffic.

Microsoft has confirmed this to be an issue in Windows NT version 4.0. This issue was first corrected in Windows NT 4.0 Service Pack 4. To resolve this issue, obtain the latest service pack for Windows NT version 4.0. For additional information, please see Q152734 How to Obtain the Latest Windows NT 4.0 Service Pack.




KB articles

For additional information about RRAS and PPTP upgrades, please see the following articles in the Microsoft Knowledge Base:

Q189594 RRAS Upgrade for WinNT Server 4.0 Hotfix Pack 3.0 Release Notes

Q189595 PPTP Performance & Security Upgrade for WinNT 4.0 Release Notes


DescriptionYou may receive an error message when you attempt to connect your Windows 2000-based computer that uses RAS to a Windows NT Server 4.0-based computer that uses the RRAS Update.

The Windows 2000-based computer displays the following error message when it cannot establish a connection:





Retrying authentication... Error 691: Access denied because username and/or password is invalid on the domain.

The Windows NT Server 4.0-based computer logs the following error messages in the system log:Event ID: 20014 Source: Router Type: Warning Description: The user %Name% has connected and failed to authenticate on port %Name%. The line has been disconnected.

Problem resolutionInstall the latest RRAS upgrade for Windows NT Server 4.0 Hotfix Pack. Follow the instructions below to obtain and install the upgrade:

1.Download and install the PPTP Performance Update for Windows NT 4.0 from the following location: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/pptp3-fix/ NOTE: Do not restart your computer after you install the PPTP update.

2.Download and install the RRAS Upgrade for Windows NT Server 4.0 Hotfix Pack 3.0 from the following location: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/



rras30-fix/

3.Restart your computer.

Microsoft has confirmed this to be a problem in Windows NT version 4.0 first corrected in Windows NT 4.0 Service Pack 4. To resolve this issue, obtain the latest service pack for Windows NT version 4.0.

KB articles

For additional information about the RRAS and PPTP upgrades, please see the following articles in the Microsoft Knowledge Base: Q189594 RRAS Upgrade for WinNT Server 4.0 Hotfix Pack 3.0 Release Notes

Q189595 PPTP Performance & Security Upgrade for WinNT 4.0 Release Notes

For additional information, please see the following articles in the Microsoft Knowledge Base: Q152734 How to Obtain the Latest Windows NT 4.0 Service Pack.

Q191854 RAS Authentication Does Not Work Connecting to RRAS server.







DescriptionWhen you set up IAS for RRAS for either VPN or dial-up traffic, the client computers may receive the following error message:

Error 930: The authentication server did not respond to authentication requests in a timely fashion.

On the RRAS server, the following error message may be reported:

Event Type: Error Event Source: RemoteAccess Event Category: None Event ID: 20073 Date: May 22, 2001 Time: 11:59:48 A.M. User: N/A Computer: Computername



Description: The following error occurred in the Point-to-Point Protocol module port: Port, UserName: Username. The authentication server did not respond to authentication requests in a timely fashion.

On the IAS server, the following error message may be reported where IP_Address is the IP address of the RRAS server:

Event Type: Error Event Source: IAS Event Category: None Event ID: 13 Date: May 22, 2001 Time: 11:59:48 A.M. User: N/A Computer: Computername Description: A request was received from the invalid client IP Address IP_Address.

CauseThis can occur if the RRAS server has not been set up as a RADIUS client in the IAS MMC.



Problem resolutionTo resolve this, add the RADIUS clients in the IAS snap-in: 1. Click Start, click Control Panel, double-click Administrative Tools, and then click Internet

Authentication Service.

2. Right-click Clients, and then click New Client.

3. In the Friendly Name field, enter a descriptive name.

4. In Protocol, click RADIUS, and then click Next.

5. In the Client Address (IP or Domain Name System [DNS]) field, enter the DNS or IP address for the client. If you use a DNS name, click Verify. In the Resolve DNS Name dialog box, click Resolve, and then select the IP address that you want to associate with that name from "Search Results."

6. If the client is a NAS and you plan to use NAS-specific remote access policies for configuration purposes, for example, a remote access policy that contains vendor-specific attributes, click Client Vendor, and then click the name of the manufacturer. If you do not know the name of the manufacturer or the name is not on the list, click RADIUS Standard. If the RADIUS client is running



either Microsoft Windows NT Server or Windows 2000 Server with RRAS, click Microsoft.

7. In the Shared Secret field, enter the shared secret for the client, and then enter it again in the Confirm Shared Secret field.

8. If your NAS supports the use of the signature attribute for verification (with PAP, CHAP, MS-CHAP, or MS-CHAP v2), click to select the Client must always send the signature attribute in the request check box.

If NAS does not support the signature attribute for PAP, CHAP, MS-CHAP, or MS-CHAP v2, do not select the Client must always send the signature attribute in the request check box.

KB articles:

For more information, see Q299684


http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q299684



DescriptionThe following event may be recorded in the Event Viewer on a Windows 2000-based server running the RRAS and configured for L2TP connections:

Event Type: Warning Event Source: RemoteAccess Event Category: None Event ID: 20171 Description: Failed to apply IP Security on port Server name and L2tp Port number because of error: The RPC server is unavailable. No calls will be accepted to this port.

In addition, the L2TP clients will not be able to connect to the remote access server when this event is logged.

CauseThis event is typically logged on Windows 2000 servers that are running RRAS and Internet Security and Acceleration (ISA) Server on the same server, due to a race condition between these two services. A race condition is when supposedly asynchronous events suddenly occur simultaneously.



Problem resolutionTo work around this problem, configure RRAS to start manually instead of automatically, and then after you start the computer, you can manually start the Routing and Remote Access.

To configure RRAS to start manually, use the Services tool in the Administrative Tools folder (Click Start, point to Programs, and then click Administrative Tools), or change the configuration in the properties of the RRAS service.

Simply setting dependencies for the RRAS service may not resolve this race condition, which is why the workaround that is provided here is suggested.

KB articles

For additional information, see Q306193.




Summary IndexSuccessful remote access connections depend on a variety of components and their correct configuration. This article described the various remote access components, the role they play, and the process of removing some components from the configuration for purposes of troubleshooting. The article described the call setup process and detailed common remote access problems, including common error messages and event IDs and how to resolve the underlying problem.



Related LinksSee the following resources for further information:

Microsoft Virtual Private Networks Web site at http://www.microsoft.com/windows2000/technologies/communications/vpn/default.asp

Microsoft Remote Access Introduction and Overview at http://www.microsoft.com/windows2000/techinfo/howitworks/communications/remoteaccess/raoverview.asp

Virtual Private Networking with Windows 2000: Deploying Remote Access VPNs at http://www.microsoft.com/windows2000/techinfo/planning/incremental/vpndeploy.asp

For the latest information about Windows 2000 Server, see the Windows 2000 Server Web site at http://www.microsoft.com/windows2000/server.


http://www.microsoft.com/windows2000/server

http://www.microsoft.com/windows2000/server/

http://www.microsoft.com/windows2000/techinfo/planning/incremental/vpndeploy.asp

http://www.microsoft.com/windows2000/techinfo/howitworks/communications/remoteaccess/raoverview.asp

http://www.microsoft.com/windows2000/technologies/communications/vpn/default.asp

Date post:	13-Jun-2020
Category:	Documents
Upload:	others
View:	11 times
Download:	0 times

Troubleshooting Windows 2000 Remote Access...

Documents