Troubleshoot Remote Access

Applies To: Windows Server 2008

This topic lists a few common issues you might encounter when using Windows Server® 2008 remote access. For the most up-to-date troubleshooting information, see http://go.microsoft.com/fwlink/?LinkId=89011.

What problem are you having?

I received error 800, which says the VPN server is unreachable.
  • Cause: PPTP/L2TP packets from the VPN client cannot reach the VPN server.

  • Solution:

    • Assuming ping is allowed (that is, not blocked) between the VPN client and the VPN server, ping the VPN server. Confirm that you have network connectivity and that packet filters configured on the VPN server are not preventing communication.

    • By default, when you configure the Routing and Remote Access service for the VPN server role, only PPTP and L2TP/IPsec packets are allowed on the Internet interface of the VPN server. Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping on the VPN server, add an input filter and an output filter that allow ICMP traffic.

    • To allow PPTP traffic, configure the network firewall to open TCP port 1723 and to forward IP protocol 47 for Generic Routing Encapsulation (GRE) traffic to the VPN server. Some firewalls refer to IP protocol 47 as VPN or PPTP pass-through. Not all firewalls support IP protocol 47. You might need to upgrade the firmware.

    • To allow L2TP traffic, configure the network firewall to open UDP port 1701 and to allow Internet Protocol security (IPsec) ESP formatted packets (IP protocol 50).

    • Check that the VPN server is listening for PPTP traffic on TCP port 1723 and is listening for L2TP traffic on UDP port 1701. On the VPN server, from the command line, type:

      netstat -aon

      You should see the following:

       

      TCP

      0.0.0.0:1723

      0.0.0.0:0

      LISTENING

      UDP

      0.0.0.0:1701

      *:*

    • You can use the Portqry command-line tool to determine if PPTP and L2TP packets are being dropped between the VPN client and VPN server. For more information, see Description of the Portqry.exe command-line utility (http://go.microsoft.com/fwlink/?LinkId=71609).

      To query the PPTP port, use the following command: portqry.exe -n <server_IP_address> -e 1723

      To query the L2TP port, use the following command: portqry.exe -n <server_IP_address> -e 1701 -p UDP

      If the query output includes "NOT LISTENING/FILTERED," check the port configuration on the server running Routing and Remote Access.

I received error 721, which says the remote computer is not responding.
  • Cause: This issue can occur if the network firewall does not permit GRE traffic (IP protocol 47). PPTP uses GRE for tunneled data.

  • Solution: Configure the network firewall between the VPN client and the server to permit GRE. In addition, make sure that the network firewall permits TCP traffic on port 1723. Both of these conditions must be met to establish VPN connectivity by using PPTP. For more information, see article 888201, "You receive an "Error 721" error message when you try to establish a VPN connection through your Windows Server-based remote access server" (http://go.microsoft.com/fwlink/?LinkId=71610).

noteNote
The firewall might be on or in front of the VPN client or in front of the VPN server.

I received error 741/742, which says there is an encryption mismatch error.
  • Cause: These errors occur if the VPN client requests an invalid encryption level or if the VPN server does not support an encryption type requested by the client.

  • Solution:

    • Check the properties (Security tab) of the VPN connection on the VPN client. If Require data encryption (disconnect if none) is selected, clear the selection and retry the connection.

    • If you are using Network Policy Server (NPS), check the encryption level in the network policy in the NPS console or policies on other RADIUS servers. Ensure that the encryption level requested by the VPN client is selected on the VPN server.

I am unable to establish a remote access VPN connection
  • 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 credentials of the VPN client, which consist 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 v2. MS-CHAP v2 is the only authentication protocol provided with Windows Server 2008 that allows 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 network policy corresponding to VPN connections are configured to use at least one common authentication method.

  • Verify that the VPN client and the network 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 network policies.

    In order for the connection to be accepted, the parameters of the connection attempt must:

    • Match all of the conditions of at least one network policy.

    • Be granted network access permission through the user account (set to Allow access), or if the user account has the Control access through NPS Network Policy option selected, the network access permission of the matching network policy must have the Grant network 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 network policy that rejected the connection attempt, scan the accounting log for the entry corresponding to the connection attempt for the policy name. If NPS is being used as a RADIUS server, check the System event log for an entry for the connection attempt.

  • 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. Alternatively, 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 in which Windows Server 2008 caches Active Directory information). For the change to take effect immediately, you must restart the VPN server computer.

  • For a VPN server that is a member server in a mixed-mode or native-mode Active Directory® 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 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 VPN server supports the tunneling protocol of the VPN client.

    By default, Windows 2000 remote access VPN clients have the Automatic server type option selected, which means that they try to establish an 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, and then they try an L2TP/IPsec-based VPN connection. If either the PPTP VPNor L2TP IPsec VPN type is selected, verify that the VPN server supports the selected tunneling protocol.

    Depending on your selections when running the Routing and Remote Access Server Setup Wizard, a Windows Server 2008 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.

  • 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 native-mode domain, verify that the VPN server has joined the domain.

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

L2TP/IPsec authentication issues

The following are the most common reasons that L2TP/IPsec connections fail:

  • No certificate

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

  • Incorrect certificate

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

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

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

  • A NAT between the remote access client and remote access server

    If there is a NAT between a Windows 2000, Windows Server 2003, or Windows XP-based L2TP/IPsec client and a Windows Server 2008 L2TP/IPsec server, you cannot establish an L2TP/IPsec connection unless both the client and server support IPsec NAT-T.

  • A firewall between the remote access client and remote access server

    If there is a firewall between a Windows L2TP/IPsec client and a Windows Server 2008 L2TP/IPsec server and you cannot establish an L2TP/IPsec connection, verify that the firewall allows L2TP/IPsec traffic to be forwarded.

One of the best tools for troubleshooting IPsec authentication issues is the Oakley log. For more information, see VPN Troubleshooting Tools.

EAP-TLS authentication issues

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

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

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

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

  • The certificate has not 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 certificate chain of the VPN clients (the series of certificates from the VPN client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this topic.

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

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

  • The certificate has a valid digital signature.

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

The VPN client 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, 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, click the Details tab, and then click the Subject Alternative Name field.

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

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

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

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

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

  • The certificate has a valid digital signature.

    CAs digitally sign certificates they issue. The VPN client verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the 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, click the Details tab, and then click the Enhanced Key Usage field.

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

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

Connection attempt is accepted when it should be rejected
  • Verify that the network access permission on the user account is set to either Deny access or Control accessthrough NPS Network Policy. If set to the latter, verify that the first matching network policy's network access permission is set to Deny Access. Deny access if the connection request matches this policy To obtain the name of the network 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 network policy to explicitly reject all connections, verify the policy conditions, network access permission, and profile settings.

VPN clients are unable to access resources 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 can be reached by the hosts and routers of the intranet. If not, then an 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 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. The Routing and Remote Access Server Setup Wizard assigns the default adapter automatically. You can manually choose a LAN adapter from the Adapter 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 network 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.

    On a VPN server running Windows Server 2008, 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.

Additional references

Community Additions

ADD
Show: