Appendix C: Troubleshooting

  • Article
On This Page

Troubleshooting tools
Troubleshooting router-to-router VPN connections

Troubleshooting tools

Windows 2000 provides the following tools to troubleshoot VPN connections:

  • TCP/IP Troubleshooting Tools

  • Authentication and Accounting Logging

  • Unreachability reason

  • 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, you can use the netsh routing ip show rtmroutes command or the Routing and Remote Access snap-in.
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 router running Windows 2000 supports the logging of authentication and accounting information for 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 router-to-router connection 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 router 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.

Unreachability Reason

When a demand-dial interface fails to make a connection, the interface is left in an unreachable state and the Routing and Remote Access service records the reason why the connection attempt failed. To view the unreachable reason in the Routing and Remote Access snap-in, click Routing Interfaces. In the details pane, right-click the demand-dial interface, and then click Unreachability Reason.

Event Logging

On the Event Logging tab in the properties of a VPN router 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 routers 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 tracingComponentenabled|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 VPN routers 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 management and monitoring tool when you select Add/Remove Windows Components from Control Panel-Add/Remove Programs.

The proper interpretation of the 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 router-to-router VPN connections

Router-to-router 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 router.

  • Unable to reach the virtual interfaces of VPN routers.

  • On-demand connection is not made automatically.

  • Unable to establish 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

  • Verify that the credentials of the calling router, consisting of user name, password, and domain name, are correct and can be validated by the answering router.

  • Verify that the user account of the calling router is not locked out, expired, disabled, or that the time the connection is being made does not correspond to the configured logon hours.

  • Verify that the user account of the calling router is not configured to change its password at the next logon or if the password has expired. A calling router cannot change an expired password during the connection process and the connection attempt is rejected.

  • Verify that the user account has not been locked out due to remote access account lockout. For more information, see the topic titled "Account lockout" in Windows 2000 online Help.

  • Verify that the Routing and Remote Access service is running on the answering router.

  • Verify that the answering router is enabled for LAN and demand-dial routing from the General tab on the properties of a VPN router in the Routing and Remote Access snap-in.

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

  • Verify that the calling router, the answering router, and the remote access policy corresponding to router-to-router VPN connections are configured to use at least one common authentication method.

  • Verify that the calling router and the remote access policy corresponding to router-to-router VPN connections are configured to use at least one common encryption strength. If the calling router is not capable of 128-bit encryption and the Strongest encryption level is required in the remote access policy, the connection attempt is rejected.

  • Verify that the parameters of the connection are authorized 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 answering router computer to access user account information. If the answering router is unable to access user account information, verify that:

    • The computer account of the answering router computer is a member of the RAS and IAS Servers security group for all the domains that contain user accounts for which the answering router 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 answering router is a member or other domains. Alternately, you or your domain administrator can add the computer account of the answering router computer to the RAS and IAS Servers security group of all the domains that contain user accounts for which the answering router is authenticating router-to-router VPN connections.

    • If you add or remove the answering router 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 answering router computer.

  • For demand-dial connections using EAP-TLS and Router (Offline Request) certificates, verify that the calling router and answering router are correctly configured.

    On the calling router, verify that EAP is configured as the authentication protocol in the Security properties of the demand-dial interface. Verify the settings of the properties of the Smart Card or other Certificate (encryption enabled) EAP type. Verify that the correct Router (Offline Request) certificate is selected when configuring the credentials of the demand-dial interface.

    On the answering router, verify that EAP is enabled as an authentication protocol on the answering router and EAP-TLS is enabled on the matching remote access policy. Verify that the correct computer certificate of the authenticating server (the answering router or IAS server) is selected from the configuration settings of the Smart Card or other Certificate EAP type in the matching remote access policy.

    Verify that the user certificate of the calling router was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the answering router trusts. Additionally, verify that the computer certificate of the answering router was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the calling router trusts.

    By default, an answering router checks the certificate revocation list (CRL) when authenticating the calling router. If the CRL is locally available, it can be checked. In some configurations, the CRL cannot be checked until after the connection is made. The CRL is stored at the root CA and, optionally, in Active Directory. For a branch office router that is acting as an answering router in a site that does not contain the root CA, there are two solutions to this problem:

    1. Publish the CRL in Active Directory. For more information, see the topics titled "Schedule the publication of the certificate revocation list" or "To manually publish the certificate revocation list" in Windows 2000 online Help. Once the CRL is published in Active Directory, the local domain controller in the site will have the latest CRL after Active Directory synchronization.

    2. On the branch office router, set the following registry value to 1:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\EAP\13\IgnoreRevocationOffline

  • For an answering router 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 and IPX) used for routing over the router-to-router VPN connection are enabled for routing on both the calling router and answering router.

  • Verify that all of the PPTP or L2TP ports on the calling router and answering router 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 calling router is supported by the answering router.
    By default, a Windows 2000 demand-dial interface with the VPN type set to Automatic will 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 answering router.

    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 calling router and the answering router.
    Verify that the calling router has 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 answering router trusts. Additionally, the answering router 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 calling router trusts.

  • Verify the configuration of the authentication provider. The answering router can be configured to use either Windows or RADIUS to authenticate the credentials of the calling router.

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

    • For an answering router that is a member of a Windows 2000 native-mode domain, verify that the answering router has joined the domain.

    • For a computer Windows NT version 4.0 Service Pack 4 and later with RRAS server that is a member of a Windows 2000 mixed mode domain or a Windows 2000 answering router 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 RRAS 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 and attempting to negotiate 40-bit MPPE encryption, verify that the password of the calling router 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.

  • For certificate-based authentication when the certificate has been revoked, changes to the CRL of the CA might not yet be published. The authenticating server is using the old CRL that does not have the recently revoked certificate. To minimize the amount of time between the revoking of a certificate and when the authenticating server has knowledge of the revoked certificate, lower the CRL publication time. On a Windows 2000 CA, the publication time can be set as low as one hour. For more information, see the topic titled "Revoking certificates and publishing CRLs" in Windows 2000 online Help.

Unable to reach locations beyond the VPN router

  • Verify that IP routing is enabled (on the IP tab on the properties of the VPN router). Verify that network access is enabled (on the IPX tab on the properties of the VPN router).

  • Verify that IP routing is enabled (on the IP tab on the properties of the VPN router). Verify that network access is enabled (on the IPX tab on the properties of the VPN router).

  • Verify that the appropriate demand-dial interface has been added to the protocol being routed.

  • Verify that there are routes in the site routers on the calling router and answering router's site so that all locations on both networks are reachable. You can add routes to the routers of each site through static routes or by enabling a routing protocol on the site interface of the calling and answering routers.
    Unlike a remote access connection, a demand-dial connection does not automatically create a default route. You need to create routes on both sides of the demand-dial connection so that traffic can be routed to and from the other side of the demand-dial connection.

    You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent demand-dial connections, you can enable Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the demand-dial connection. For on-demand demand-dial connections, you can automatically update routes through an auto-static RIP update.

  • For two-way initiated router-to-router VPN connections, verify that the router-to-router VPN connection is not interpreted by the VPN router as a remote access connection.
    For two-way initiated connections, either router can be the calling router or the answering router. The user names and demand-dial interface names must be properly matched. For example, two-way initiated connections would work under the following configuration:

           Router 1 has a demand-dial interface called NEW-YORK which is configured to use SEATTLE as the user name when sending authentication credentials.

           Router 2 has a demand-dial interface called SEATTLE which is configured to use NEW-YORK as the user name when sending authentication credentials.

    This example assumes that the SEATTLE user name can be validated by Router 2 and the NEW-YORK user name can be validated by Router 1.

    If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state. If the user account name in the credentials of the calling router appears under Remote Access Clients in the Routing and Remote Access snap-in, then the calling router has been interpreted by the answering router as a remote access client.

  • For a one-way initiated demand-dial connection, verify that the appropriate static routes are enabled on the user account of the calling router and that the answering router is configured with a routing protocol so that when a connection is made, the static routes of the user account of the calling router are advertised to neighboring routers.

  • Verify that there are no IP or IPX packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of TCP/IP or IPX traffic.
    You can configure each demand-dial interface with IP and IPX input and output filters to control the exact nature of TCP/IP and IPX traffic that is allowed into and out of the demand-dial interface.

Unable to reach the virtual interfaces of VPN routers

  • Verify the IP address pools of the calling router and answering router. If the VPN router 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 site. If not, then IP route consisting of the VPN router static IP address pools, as defined by the IP address and mask of the range, must be added to the routers of the site or enable the routing protocol of your routed infrastructure on the VPN router. If the routes to the address pool subnets are not present, calling router logical interfaces cannot receive traffic from locations on the site. 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 router is configured to use DHCP for IP address allocation and no DHCP server is available, the VPN router assigns addresses from the Automatic Private IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254. Assigning APIPA addresses to VPN routers works only if the network to which the VPN router is attached is also using APIPA addresses.

    If the VPN router 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 router 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 the VPN router 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 router 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.

On-demand connection is not made automatically

  • Verify that IP routing is enabled on the IP tab on the properties of the calling router.

  • Verify that the correct static routes exist and are configured with the appropriate demand-dial interface.

  • For the static routes that use a demand-dial interface, verify that the Use this route to initiate demand-dial connections check box on the properties of the demand-dial interface is selected.

  • Verify that the demand-dial interface is not in a disabled state.

  • To enable a demand-dial interface that is in a disabled state, right-click the demand-dial interface under Routing Interfaces in the Routing and Remote Access snap-in, and then click Enable.

  • Verify that the dial-out hours for the demand-dial interface on the calling router are not preventing the connection attempt.
    To configure dial-out hours, right-click the demand-dial interface under Routing Interfaces in the Routing and Remote Access snap-in, and then click Dial-out Hours.

  • Verify that the demand-dial filters for the demand-dial interface on the calling router are not preventing the connection attempt.
    To configure demand-dial filters, right-click the demand-dial interface under Routing Interfaces in the Routing and Remote Access snap-in, and then click Set IP Demand-dial Filters.

Unable to establish tunnel

  • Verify that packet filtering on a router interface between the calling router and the answering router 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 router, 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 router. 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.