Remote Access Problems and Solutions

Applies To: Windows 7, Windows Server 2008 R2

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

What problem are you having?

• I received error 800, which says the VPN server is unreachable

• I received error 721, which says the remote computer is not responding

• I cannot connect when my user name contains Unicode characters

• I received error 741/742, which says there is an encryption mismatch error

• I am unable to establish a remote access VPN connection

• L2TP/IPsec authentication issues

• EAP-TLS authentication issues

• Connection attempt is accepted when it should be rejected

• VPN clients are unable to access resources beyond the RRAS server

• Unable to establish tunnel

I received error 800, which says the VPN server is unreachable

• Cause: Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), Secure Socket Tunneling Protocol (SSTP), or Internet Key Exchange version 2 (IKEv2) packets from the virtual private network (VPN) client cannot reach the VPN server.

• Solution:

  • Assuming ping 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 RRAS for the VPN server role, only PPTP, L2TP/Internet Protocol security (IPsec), SSTP, and IKEv2 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 IP protocol 50.

  • To allow SSTP traffic, configure the network firewall to open TCP port 443.

  • To allow IKEv2 traffic, configure the network firewall to open UDP ports 500 and 4500, and to allow IP protocol 50.

  • To check that the VPN server is listening for VPN traffic on the appropriate port numbers, on the RRAS server, from the command line, type:

    netstat -aon

    For example, if PPTP is listening for network traffic, the following appears in the output:

    Proto	Local Address	Foreign Address	State
    TCP	0.0.0.0:1723	0.0.0.0:0	LISTENING
    TCP	[::]:1723	0.0.0.0:0	LISTENING

    The other tunnel protocols display similar entries with appropriate port numbers.

  • You can use the Portqry command-line tool to determine if PPTP, L2TP, SSTP, or IKEv2 packets are being dropped between the VPN client and VPN server. For example:

    • 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

    For more information, see Description of the Portqry.exe command-line utility (https://go.microsoft.com/fwlink/?linkid=71609).

    The other tunnel protocols can be similarly queried for their port numbers. If the query output includes "NOT LISTENING/FILTERED," check the port configuration on the RRAS server.

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 (https://go.microsoft.com/fwlink/?linkid=71610).

Note

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 encryption level that is not valid or if the VPN server does not support an encryption type requested by the client.

• Solution:

  • From the Security tab, check the properties 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 enabled on the VPN server.

I cannot connect when my user name contains Unicode characters

• Cause: This error can occur if a remote access client is authenticating a user name that contains extended characters (in the 128 to 255 range) and either of the following conditions is true:

  • The client is running a version of Windows older than Windows 7, is using Extensible Authentication Protocol (EAP), and is connecting to a remote network that uses an authenticating NPS server that is running Windows Server 2008 R2. Because NPS on Windows Server 2008 R2 expects Unicode and the client is sending ANSI, if there are any extended characters in the user name, authentication fails.

  • The client is running any version of Windows, is using a non-EAP authentication protocol and is connecting to a remote network that uses an authenticating NPS server that is running Windows Server 2008 R2. Because non-EAP protocols only send ANSI and the NPS server expects Unicode, if there are any extended characters in the user name, authentication fails.

  By default, the Windows 7 remote access client supports only Unicode when negotiating Extensible Authentication Protocol (EAP), but supports only ANSI for all non-EAP based authentication. Earlier versions of Windows support only ANSI for all authentication methods.

  By default, Network Policy Server (NPS) on Windows Server 2008 R2 supports Unicode for all authentication methods.

• Solution: Configure the NPS server to support ANSI instead of Unicode. To do this, perform the following steps:

  1. Click Start, click Run, type regedit, and then click OK.

  2. Locate the following registry key:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\Configuration

  3. Click Edit, click New, and then click DWord Value.

  4. Type IdentityEncodingFormat, and then press ENTER.

  5. Click Edit, click Modify, type the value 0x1, and then click OK.

  6. Exit the Registry Editor.

Important

This configuration change causes the NPS server to accept only ANSI and no longer accept Unicode-based user names, so EAP-based authentication from a Windows 7 client will now fail. To fix this case, you can set the same registry key shown in the previous procedure on the Windows 7 client to configure EAP to use ANSI. If you have a mix of remote access clients, you can use this registry setting to configure all servers and clients to use ANSI until you upgrade all of the clients to a version of Windows that supports Unicode for the authentication methods you need to use.

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 Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2). MS-CHAP v2 is the only authentication protocol 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 RRAS is running on the VPN server.

• From the General tab on the properties of a VPN server in the RRAS MMC snap-in, verify that the VPN server is enabled for remote access.

• From the properties of the Ports object in the RRAS MMC snap-in, verify that the WAN Miniport (PPTP), WAN Miniport (L2TP), WAN Miniport (SSTP), and WAN Miniport (IKEv2) devices are enabled for inbound remote access.

• 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). 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 RRAS Setup Wizard, the wizard automatically adds the computer account of the RAS and IAS Servers domain-local security group. This group membership allows the RRAS server computer to access user account information. If the RRAS server is unable to access user account information, verify that:

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

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

• For an RRAS server that is a member server in an 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 RRAS server.

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

• Verify that the RRAS 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, and 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 RRAS 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 RRAS Setup Wizard, a Windows Server computer running RRAS supports 128 L2TP ports, 128 PPTP ports, 128 SSTP ports, and 128 IKEv2 ports. To create a PPTP-only, IKEv2-only, or SSTP-only server, set the number of all other port types to 0. To create an L2TP-only server, set the number of PPTP ports to 1, the number of all other port types to 0, and then from the properties of the Ports object in the RRAS snap-in, disable remote access inbound connections and demand-dial connections for the WAN Miniport (PPTP) device.

• For L2TP/IPsec, SSTP, and IKEv2 connections, verify that computer certificates, also known as machine certificates, are installed on the RRAS server and the VPN client where appropriate.

• If the RRAS 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 RRAS 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 RRAS server can be configured to use either Windows or RADIUS to authenticate the credentials of the VPN client.

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

  • For an RRAS server that is a member of a native-mode domain, verify that the RRAS server has joined the domain.

• For PPTP connections using MS-CHAP and attempting to negotiate 40-bit Microsoft Point-to-Point Encryption (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 CA1 and CA2, it notifies its IPsec peer during main mode negotiation that it will accept certificates for authentication from CA1 and CA2 only. If the IPsec peer, Computer B, does not have a valid computer certificate issued from either CA1 or CA2, 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 RRAS server trusts. Additionally, the RRAS 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 RRAS server and VPN client exchange computer certificates for IPsec peer authentication. Check the Local Computer certificate stores of both the VPN client and RRAS server using the Certificates snap-in to ensure that a suitable certificate exists.

• A NAT between the VPN client and RRAS server

  If there is a NAT between an L2TP/IPsec client and an RRAS L2TP/IPsec server, you cannot establish an L2TP/IPsec connection unless both the client and server support IPsec NAT-T.

• A firewall between the VPN client and RRAS server

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

EAP-TLS authentication issues

When Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is used for authentication, the VPN client submits a user certificate and the authenticating server (the RRAS 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 fully qualified domain name (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 user different 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.

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 access through 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 RRAS 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 RRAS server.

  If the RRAS 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 RRAS 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 the routing protocol of your routed infrastructure on the RRAS server must be enabled. 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 RRAS server is configured to use DHCP for IP address allocation and no DHCP server is available, the RRAS 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 VPN clients works only if the network to which the RRAS server is attached is also using APIPA addresses.

  If the RRAS 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 RRAS 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 RRAS server in the RRAS MMC 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 RRAS 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 an RRAS VPN server, IP packet filtering can be separately configured from the Windows Firewall with Advanced Security MMC snap-in and from the RRAS MMC 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 an RRAS server (for authorized Internet users) to facilitate both exchanges of information.

Additional references

• Troubleshooting Remote Acccess