Export (0) Print
Expand All
Expand Minimize
2 out of 3 rated this helpful - Rate this topic

Appendix D: Troubleshooting

Published: August 01, 2002

Troubleshooting tools

Windows 2000 provides the following tools to troubleshoot VPN connections:

  • TCP/IP Troubleshooting Tools

  • Authentication and Accounting Logging

  • Event Logging

  • IAS Event Logging

  • PPP Logging

  • Tracing

  • Network Monitor

TCP/IP Troubleshooting Tools
The Ping, Tracert, and Pathping tools use ICMP Echo and Echo Reply messages to verify connectivity, display the path to a destination, and test path integrity. The route print command can be used to display the IP routing table. Alternately, on the VPN server, you can use the netsh routing ip show rtmroutes command or the Routing and Remote Access snap-in. The Nslookup tool can be used to troubleshoot DNS and name resolution issues.

In addition to the normal TCP/IP tools, use the Netdiag tool to test and display your network configuration.

Authentication and Accounting Logging
A VPN server running Windows 2000 supports the logging of authentication and accounting information for remote access VPN connections in local logging files when Windows authentication or Windows accounting is enabled. This logging is separate from the events recorded in the system event log. You can use the information that is logged 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.

Enable authentication and accounting logging from the Settings tab on the properties of the Local File object in the Remote Access Logging folder in the Routing and Remote Access snap-in (if the Routing and Remote Access service is configured for Windows authentication and accounting) or the Internet Authentication Service snap-in (if the Routing and Remote Access service is configured for RADIUS authentication and accounting and the RADIUS server is an IAS server)

The authentication and accounting information is stored in a configurable log file or files stored in the SystemRoot\System32\LogFiles folder. The log files are saved in Internet Authentication Service (IAS) or database-compatible format, meaning that any database program can read the log file directly for analysis.

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

Event Logging
On the Event Logging tab in the properties of a VPN server in the Routing and Remote Access snap-in, there are four levels of logging. Select Log the maximum amount of information, and then try the connection again. After the connection fails, check the system event log for events logged during the connection process. After you are done viewing remote access events, select the Log errors and warnings option on the Event logging tab to conserve system resources

IAS Event Logging
If your VPN servers are configured for RADIUS authentication and your RADIUS servers are computers running Windows 2000 Server and IAS, check the system event log for IAS events for rejected or accepted connection attempts. IAS system event log entries contain a lot of information on the connection attempt including the name of the remote access policy that accepted or rejected the connection attempt. IAS event logging for rejected or accepted connection attempts is enabled by default and configured from the Service tab from the properties of an IAS server in the Internet Authentication Service snap-in.

PPP logging
PPP logging records the series of programming functions and PPP control messages during a PPP connection and is a valuable source of information when you are troubleshooting the failure of a PPP connection. To enable PPP logging, select the Enable Point-to-Point Protocol (PPP) logging option on the PPP tab on the properties of a remote access server.

The PPP log in Windows NT 4.0 has been replaced by the tracing function. To duplicate the PPP log, you need to enable file tracing for the PPP key. By default, the PPP log is stored as the Ppp.log file in the SystemRoot\Tracing folder.

Tracing
The Windows 2000 Routing and Remote Access service has an extensive tracing capability that you can use to troubleshoot complex network problems. You can enable the components in Windows 2000 Server to log tracing information to files using the Netsh command or through the registry.

Enabling Tracing with Netsh
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

where Component is a component in the list of Routing and Remote Access service components found in the Windows 2000 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. For example, to enable tracing for the RASAUTH component, the command is:

netsh ras set tracing rasauth enabled

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

netsh ras set tracing * enabled

Enabling Tracing through the Registry
The tracing function can also be configured by changing settings in the Windows 2000 registry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing

You can enable tracing for each Routing and Remote Access service component by setting the registry values described later. You can enable and disable tracing for components while the Routing and Remote Access service is running. Each component is capable of tracing and appears as a subkey under the preceding registry key.

To enable tracing for each component, you can configure the following registry value entries for each protocol key:

EnableFileTracing REG_DWORD Flag

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

FileTracingMask determines how much tracing information is logged to the file. The default value is 0xFFFF0000.

MaxFileSize REG_DWORD SizeOfLogFile

You can change the size of the log file by setting different values for MaxFileSize. The default value is 0x10000 (64K).

Note:  Tracing consumes system resources and should be used sparingly to help identify network problems. After the trace is captured or the problem is identified, you should immediately disable tracing. Do not leave tracing enabled on multiprocessor computers.

Tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft support professionals or to network administrators who are very experienced with the Routing and Remote Access service. Tracing information can be saved as files and sent to Microsoft support for analysis.

Network Monitor
Use Network Monitor, a packet capture and analysis tool supplied with Windows 2000 Server, to capture and view the traffic sent between a VPN server and VPN client during the VPN connection process and during data transfer. You cannot interpret the encrypted portions of VPN traffic with Network Monitor. Network Monitor is installed as an optional networking component.

The proper interpretation of the remote access and VPN traffic with Network Monitor requires an in-depth understanding of PPP, PPTP, IPSec, and other protocols. Network Monitor captures can be saved as files and sent to Microsoft support for analysis.

Troubleshooting remote access VPNs

Remote access VPN problems typically fall into the following categories:

  • Connection attempt is rejected when it should be accepted.

  • Connection attempt is accepted when it should be rejected.

  • Unable to reach locations beyond the VPN server.

  • Unable to establish a tunnel.

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

Connection attempt is rejected when it should be accepted

  • Using the Ping command, verify that the host name is being resolved to its correct IP address. The ping itself might not be successful due to packet filtering that is preventing the delivery of ICMP messages to and from the VPN server.

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

  • Verify that the user account of the VPN client is not locked out, expired, disabled, or that the time the connection is being made does not correspond to the configured logon hours. If the password on the account has expired, verify that the remote access VPN client is using MS-CHAP v1 or MS-CHAP v2. MS-CHAP v1 and MS-CHAP v2 are the only authentication protocols provided with Windows 2000 that allow you to change an expired password during the connection process. For an administrator-level account whose password has expired, reset the password using another administrator-level account.

  • Verify that the user account has not been locked out due to remote access account lockout.

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

  • Verify that the VPN server is enabled for remote access from the General tab on the properties of a VPN server in the Routing and Remote Access snap-in.

  • Verify that the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices are enabled for inbound remote access from the properties of the Ports object in the Routing and Remote Access snap-in.

  • Verify that the VPN client, the VPN server, and the remote access policy corresponding to VPN connections are configured to use at least one common authentication method.

  • Verify that the VPN client and the remote access policy corresponding to VPN connections are configured to use at least one common encryption strength.

  • Verify that the parameters of the connection have permission through remote access policies. In order for the connection to be established, the parameters of the connection attempt must:

    • Match all of the conditions of at least one remote access policy.

    • Be granted remote access permission through the user account (set to Allow access), or if the user account has the Control access through Remote Access Policy option selected, the remote access permission of the matching remote access policy must have the Grant remote access permission option selected.

    • Match all the settings of the profile.

    • Match all the settings of the dial-in properties of the user account.

    To obtain the name of the remote access policy that rejected the connection attempt, scan the accounting log for the entry corresponding to the connection attempt for the policy name.

  • If you are logged on using an account with domain administrator permissions when you run the Routing and Remote Access Server Setup Wizard, it automatically adds the computer account of the RAS and IAS Servers domain-local security group. This group membership allows the VPN server computer to access user account information. If the VPN server is unable to access user account information, verify that:

    • The computer account of the VPN server computer is a member of the RAS and IAS Servers security group for all the domains that contain user accounts for which the VPN server is authenticating remote access. You can use the netsh ras show registeredserver command at the command prompt to view the current registration. You can use the netsh ras add registeredserver command to register the server in a domain in which the VPN server is a member or other domains. Alternately, you or your domain administrator can add the computer account of the VPN server computer to the RAS and IAS Servers security group of all the domains that contain user accounts for which the VPN server is authenticating remote access.

    • If you add or remove the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Windows 2000 caches Active Directory information). For the change to take effect immediately, you need to restart the VPN server computer.

  • For a VPN server that is a member server in a mixed-mode or native-mode Windows 2000 domain that is configured for Windows authentication, verify that:

    • The RAS and IAS Servers security group exists. If not, then create the group and set the group type to Security and the group scope to Domain local.

    • The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.

  • Verify that the LAN protocols (TCP/IP, IPX, NetBEUI) used by the VPN client are enabled for remote access on the VPN server.

  • Verify that all of the PPTP or L2TP ports on the VPN server are not already being used. If necessary, change the number of PPTP to L2TP ports from the properties of the Ports object in the Routing and Remote Access snap-in to allow more concurrent connections.

  • Verify that the tunneling protocol of the VPN client is supported by the VPN server. By default, Windows 2000 remote access VPN clients have the Automatic server type option selected, which means that they try to establish a L2TP/IPSec-based VPN connection first, then they try a PPTP-based VPN connection. If either the Point to Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option is selected, verify that the selected tunneling protocol is supported by the VPN server.

    By default, Windows XP remote access VPN clients have the Automatic VPN type option selected, which means that they try to establish a PPTP -based VPN connection first, then they try a L2TP/IPSec-based VPN connection. If either the PPTP VPN or L2TP IPSec VPN type is selected, verify that the selected tunneling protocol is supported by the VPN server.

    Depending on your selections when running the Routing and Remote Access Server Setup Wizard, a Windows 2000 Server–based computer running the Routing and Remote Access service is a PPTP and L2TP server with five or 128 L2TP ports and five or 128 PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections for the WAN Miniport (PPTP) device from the properties of the Ports object in the Routing and Remote Access snap-in.

  • For L2TP/IPSec connections, verify that computer certificates, also known as machine certificates, are installed on the VPN client and the VPN server.

  • If the VPN server is configured with static IP address pools, verify that there are enough addresses. If all of the addresses in the static pools have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address for TCP/IP-based connections, and the connection attempt is rejected.

  • If the VPN client is configured to request its own IPX node number, verify that the VPN server is configured to allow IPX clients to request their own IPX node number.

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

  • Verify the configuration of the authentication provider. The VPN server can be configured to use either Windows or RADIUS to authenticate the credentials of the VPN client.

    • For RADIUS authentication, verify that the VPN server computer can communicate with the RADIUS server.

    • For a VPN server that is a member of a Windows 2000 native-mode domain, verify that the VPN server has joined the domain.

    • For a Windows NT version 4.0 Service Pack 4 and later VPN server that is a member of a Windows 2000 mixed mode domain or a Windows 2000 VPN 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, 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. If not, issue the net localgroup "Pre-Windows 2000 Compatible Access" everyone /add command on a domain controller computer and then restart the domain controller.

    • For a Windows NT version 4.0 Service Pack 3 and earlier VPN server that is a member of a Windows 2000 mixed-mode domain, verify that the 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.

  • For PPTP connections using MS-CHAP v1 and attempting to negotiate 40-bit MPPE encryption, verify that the user's password is not larger than 14 characters.

Connection attempt is accepted when it should be rejected

  • Verify that the remote access permission on the user account is set to either Deny access or Control access through Remote Access Policy. If set to the latter, verify that the first matching remote access policy's remote access permission is set to Deny remote access permission. To obtain the name of the remote access policy that accepted the connection attempt, scan the accounting log for the entry corresponding to the connection attempt for the policy name.

  • If you have created a remote access policy to explicitly reject all connections, verify the policy conditions, remote access permission, and profile settings.

Unable to reach locations beyond the VPN server

  • Verify that either the protocol is enabled for routing or that dial-in clients are allowed to access the entire network for LAN protocols being used by the VPN clients.

  • Verify the IP address pools of the VPN server. If the VPN server is configured to use a static IP address pool, verify that the routes to the range of addresses defined by the static IP address pools are reachable by the hosts and routers of the intranet. If not, then IP route consisting of the VPN server static IP address pools, as defined by the IP address and mask of the range, must be added to the routers of the intranet or enable the routing protocol of your routed infrastructure on the VPN server. If the routes to the remote access VPN client subnets are not present, remote access VPN clients cannot receive traffic from locations on the intranet. Routes for the subnets are implemented either through static routing entries or through a routing protocol, such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP).

    If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, the VPN server assigns 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 VPN server is attached is also using APIPA addresses.

    If the VPN 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. By default, the VPN server chooses the adapter to use to obtain IP addresses through DHCP based on your selections in the Routing and Remote Access Server Setup Wizard. You can manually choose a LAN adapter from the Adapters list on the IP tab on the properties of a VPN server in the Routing and Remote Access snap-in.

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

  • Verify that there are no packet filters on the profile properties of the remote access policy corresponding to VPN connections that are preventing the sending or receiving of traffic.

Unable to establish tunnel

  • Verify that packet filtering on a router interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic. See Appendix A for information on the types of traffic that must be allowed for PPTP and L2TP/IPSec traffic.

    On a Windows 2000–based VPN server, IP packet filtering can be separately configured from the advanced TCP/IP properties and from the Routing and Remote Access snap-in. Check both places for filters that might be excluding VPN connection traffic.

  • Verify that the Winsock Proxy client is not currently running on the VPN client. When the Winsock Proxy client is active, Winsock API calls such as those used to create tunnels and send tunneled data are intercepted and forwarded to a configured proxy server.

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

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

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.