Appendix C: Troubleshooting

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting Tools

Windows Server 2003 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

  • Oakley Logging

  • 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 Server 2003 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 site-to-site 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 Server 2003 and IAS, the authentication and accounting logs are stored in the SystemRoot\System32\LogFiles folder on the IAS server computer.

The Routing and Remote Access service and IAS for Windows Server 2003 can also send authentication and accounting information to a Structured Query Language (SQL) server database.

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 Network Interfaces. In the details pane, right-click the demand-dial interface, and then click Unreachability Reason.

Event Logging

On the 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 all events, 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 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 Server 2003 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 about 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 Log additional Routing and Remote Access information option on the Logging 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 Server 2003 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 Server 2003 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 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

You can also configure the tracing function by changing settings in the 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 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.

Oakley Logging

You can use the Oakley log to view details about the IPSec security association (SA) negotiation 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 Routing and Remote Access service 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 Routing and Remote Access service using the net start remoteaccess command.

Network Monitor

Use Network Monitor, a packet capture and analysis tool supplied with Windows Server 2003, 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 or 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 Site-to-Site VPN Connections

Site-to-site VPN problems typically fall into the following categories:

  • Connection attempt is rejected when it should be accepted.

  • L2TP/IPSec authentication issues.

  • EAP-TLS authentication issues.

  • 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 Server 2003 Help and Support.

  • 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 site-to-site VPN connections are configured to use at least one common authentication method.

  • Verify that the calling router and the remote access policy corresponding to site-to-site 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 site-to-site 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 Server 2003 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 advanced 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 method 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 remote access policy for site-to-site VPN connections.

    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 Server 2003 Help and Support. 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 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 IP is 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 answering router supports the tunneling protocol of the calling router.

    By default, a Windows Server 2003 demand-dial interface with the VPN type set to Automatic will try to establish a PPTP-based VPN connection first, then try an L2TP/IPSec-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 Server 2003based 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.

  • 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 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 mixed mode domain or a Windows Server 2003 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 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 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.

L2TP/IPSec Authentication Issues

The most common problems that cause site-to-site L2TP/IPSec connections to fail are the following:

  • No certificate

    By default, site-to-site L2TP/IPSec connections require that the calling and answering router exchange computer certificates for IPSec peer authentication. Check the Local Computer certificate stores of both the calling and answering router 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 router in the L2TP/IPSec 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 Router 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, Router B, does not have a valid computer certificate issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.

    The calling 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 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.

    By default, L2TP/IPSec connections require that the calling and answering routers exchange computer certificates for IPSec peer authentication. Check the Local Computer certificate stores of both the calling and answering routers using the Certificates snap-in to ensure that a suitable certificate exists.

  • A NAT between the calling and answering routers

    If either the calling or answering router is behind a NAT, then both the calling and answering routers must support IPSec NAT-T. However, Microsoft recommends that answering routers, such as VPN routers running Windows Server 2003, not be placed behind NATs.

  • A firewall between the calling and answering routers

    If there is a firewall between the calling and answering router and you cannot establish an L2TP/IPSec connection, verify that the firewall allows L2TP/IPSec traffic to be forwarded. For more information, see Appendix A.

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

EAP-TLS Authentication Issues

When EAP-TLS is used for authentication, the calling router submits a Router (Offline request) user certificate and the authenticating server (the answering router or the RADIUS server) submits a computer certificate.

In order for the authenticating server to validate the certificate of the calling router, the following must be true for each certificate in the certificate chain sent by the calling router:

  • 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 calling routers certificate chain (the series of certificates from the calling router 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 certificates issuing CA and mathematically validating the digital signature.

The calling router certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) (object identifier 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 calling router, the authenticating server must have the root CA certificate of the issuing CA of the calling router 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 a Windows Server 2003 answering router or 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, the authenticating server allows EAP-TLS clients to connect even when it does not perform or cannot complete a revocation check of the calling router's certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate doesn't 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, the authenticating server 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. The authenticating server 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, the authenticating server prevents EAP-TLS from performing a revocation check of the calling router's certificate. The revocation check verifies that the calling routers certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

  • NoRootRevocationCheck

    When set to 1, the authenticating server prevents EAP-TLS from performing a revocation check of the calling router'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 calling router'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 calling router does not use these settings.

In order for the calling router 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 calling router 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 certificates issuing CA and mathematically validating the digital signature.

Additionally, the authenticating server computer certificate must have the Server Authentication EKU (object identifier 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 calling router 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 calling router 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 calling router does not yet have a connection to the network, and therefore might not have access to a Web page or other resource in order to check for certificate revocation.

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 Server 2003 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 Server 2003 Help and Support.

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 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 site-to-site VPN connections, verify that the answering router is not interpreting the site-to-site VPN connection 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 that is configured to use SEATTLE as the user name when sending authentication credentials.

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

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

    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 answering router has interpreted the calling 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 packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of TCP/IP.

    You can configure each demand-dial interface with IP input and output filters to control the exact nature of TCP/IP 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 Adapter 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 Network 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 Network 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 Network 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 about the types of traffic that must be allowed for PPTP and L2TP/IPSec traffic.

    On a Windows Server 2003based 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.