Common Remote Access Problems

Article
10/28/2014

Users cannot connect Users can connect but cannot authenticate L2TP/IPSec authentication issues EAP-TLS authentication issues Users can connect and authenticate but cannot reach locations beyond the remote access server Users can connect, authenticate and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing). Miscellaneous remote access solutions

Remote access problems can typically be categorized into the following types of issues:

Users cannot connect.
Users can connect but cannot authenticate.
Users can connect and authenticate but cannot reach locations beyond the remote access server.
Users can connect, authenticate, and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing).

Users cannot connect

If the connection attempt is rejected and all configuration properties indicate that it should have been accepted, try to verify configuration details in the areas listed below.

Fax and modem troubleshooting:

If the Windows 2000 Fax service and the RRAS are sharing the same modem, verify that the modem supports adaptive answer. If the modem does not support adaptive answer, you must disable fax on the modem to receive incoming remote access connections.
If you are using an external modem, verify that your modem is turned on.
Lower the modem speed.
Replace the existing modem with a different one.
Run modem diagnostics to ensure that the COM port is configured correctly and that the modem is functioning properly.
Dial a different phone number if your ISP or the corporate RAS server that you are connecting to allows you to do so.
Use a different phone cable.

Service:

Ensure that the RRAS is enabled and running on the remote access server.
Verify the dial-up or VPN ports on the remote access server are configured to allow inbound remote access connections.
Ensure that your dial-up equipment is working properly.
Verify all of the dial-up ports on the remote access server are already connected. If they are, the connection will fail.

Protocols:

Ensure that the protocols being used by the remote access clients are enabled for routing.

IP address pool:

If your remote access server is configured with a static IP address pool, verify that there are enough addresses in the pool. In this case, the remote access server will be unable to allocate an IP address to the remote access client. In this situation, if the remote access client is only configured to use TCP/IP as a LAN protocol, the connection attempt is denied.

IPX settings:

If the remote access client is configured to request its own IPX node number, verify that the server is configured to allow IPX clients to request their own IPX node number on the IPX tab of the properties of a remote access server in the Routing and Remote Access snap-in.
If the remote access server is configured with a range of IPX network numbers, verify that the IPX network numbers in that range are not being used elsewhere on your IPX internetwork.

Domain settings:

For a remote access server that is a member of a Windows 2000 native-mode domain, verify that the remote access server has actually joined the 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 for:

  - A Windows NT version 4.0 Service Pack 4 and later remote access server that is a member of a Windows 2000 mixed mode domain.

  - A Windows 2000 remote access server that is a member of a Windows NT 4.0 domain that is accessing user account properties for a user account in a trusted Windows 2000 domain.

    If not, issue the

    <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">net localgroup "Pre-Windows 2000 Compatible Access" everyone /add</pre>

command on a domain controller computer and then restart it.

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

User account:

On the properties of the user account, verify that the user account has not been disabled or is not locked out due to remote access account lockout.
Verify that the password on the user account has not expired.

For an administrator-level account with an expired password, use another administrator-level account to reset the password.

Remote access policies:

It is possible that the connection properties of the remote access client are in conflict with the remote access policy settings on the remote access server, thereby preventing the users from connecting. Make sure that the parameters of the connection have appropriate permissions through remote access policies.
For the connection to be accepted, the settings of the connection attempt must:
- Match the conditions of at least one remote access policy.
- Be granted remote access permission through the user account (set to Allow access), or through the user account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission).
- Match the settings of the profile.
- Match the settings of the dial-in properties of the user account.

Remote access server settings:

Make sure that the settings of the remote access policy profile are not in conflict with the properties of the remote access server. The properties of the remote access policy profile and the properties of the remote access server both contain settings for:
- Multilink
- Bandwidth allocation protocol
- Authentication protocols

If the profile settings of the matching remote access policy are in conflict with the settings of the remote access router, then the connection attempt is denied. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP-TLS is not enabled through the properties of the remote access server, then the remote access server denies the connection attempt.

Possible error messages The following common Windows 2000 remote access client errors occur when users are not able to connect to the remote access server.

Error 651 This error is a sign that the modem or any other connecting device has reported an error.

The remote access server stops responding while connections are in progress. It could also be that the remote access server is not responding because its PPTP ports are busy in active calls. The connection fails when the PPTP server sends a TCP disconnect to the client. If all the ports available on the server are busy, the server waits for 30 seconds before sending a TCP disconnect to the client.

When using PPTP, this error can also occur if GRE is not being forwarded between the remote access client and the remote access server. When GRE sends a packet with data, it sends the packet with a sequence number for tracking purposes. The type of GRE response is based on whether data is included in the response packet or if the packet is an acknowledgement only. If the response packet includes data, then you see a sequence number and an acknowledgement number towards the bottom of the packet.

If the GRE packet is an acknowledgement only however, you may have some difficulty figuring out whether an acknowledgment has ever been sent. This however relates to a different issue of parsing inconsistencies with Microsoft Network Monitor. For more information, see the KB article Q241251.

Error 692 If you see this error, complete the checklist on Fax and Modem Settings earlier in this section.

Error 678 For PPTP/L2TP connections, this error represents a lack of response from the remote access server and is referred to as the ‘no answer’ error.

Make sure you are connected to the Internet and use the checklist provided earlier in this section to ensure that you are connecting to the correct server name or IP address

Error 734 The above errors cover issues ranging from a bad phone line or a modem dropping PPP packets to multiple configuration problems on the remote access server. Please read the checklist above to assist troubleshooting.

Users can connect but cannot authenticate

This is a situation where remote access clients can connect to the remote access server but fail to authenticate. If authentication fails, verify settings in the following areas:

Authentication:

Verify that the remote access client and the remote access server in conjunction with a remote access policy are enabled to use at least one common authentication method and at least one common encryption method.
If you are using MS-CHAP, verify that you are not using a user password over 14 characters long. If so, either use a different authentication protocol or change the password so that it is 14 characters or less in length.
Check the configuration of the authentication provider. The remote access server can be configured to use either Windows or RADIUS to authenticate the credentials of the remote access client.
- If you are using Windows authentication for a remote access server that is a member of a mixed-mode or a native-mode Windows 2000 domain, verify that the remote access server computer account is a member of the RAS and IAS Servers security group. You can use the
```
netsh ras show registeredserver
```

command at the Windows 2000 command prompt to view the current registration. If your server is not registered, use the

netsh ras add registeredserver

command to register the server in a specified domain.

  - If you are using RADIUS authentication, verify that the remote access server computer can communicate with the RADIUS server.

If you are using RADIUS authentication for a remote access server and the RADIUS server is a computer running Windows 2000 and the Internet Authentication Service (IAS) that is a member of a mixed-mode or a native-mode Windows 2000 domain, verify that the IAS server computer account is a member of the RAS and IAS Servers security group. You can use the
```
netsh ras show registeredserver
```

command at the Windows 2000 command prompt to view the current registration. If your server is not registered, use the

netsh ras add registeredserver

command to register the server in a specified domain.

Note: If you add or remove the remote access server computer to the RAS and IAS Servers security group, the change does not take effect immediately because of how Windows 2000 caches Active Directory directory service information. For the change to take effect immediately, you need to restart the remote access server

Client credentials:

Incorrect client credentials may prevent successful authentication. Check to see if the remote access client's credentials consisting of user name, password, and domain name are correct and can be validated by the remote access server.

L2TP/IPSec authentication issues

The following list shows the most common problems that cause L2TP/IPSec connections to 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 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 is not configurable. 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 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 L2TP/IPSec client and a Windows 2000 L2TP/IPSec server, you cannot establish an L2TP/IPSec connection. IPSec NAT-T is not yet available for Windows 2000 from Microsoft.
Firewall between the remote access client and remote access server

If there is a firewall between a Windows 2000 L2TP/IPSec client and a Windows 2000 L2TP/IPSec server, you cannot establish an L2TP/IPSec connection, verify that the firewall is allow L2TP/IPSec traffic to be forwarded. For more information, see "Integrating VPN Servers and Firewalls" in this article.

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

EAP-TLS authentication issues

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

For the authenticating server to validate the certificate of the remote access client, the following must be true for each certificate in the certificate chain sent by the remote access 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 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 remote access client’s certificate chain (the series of certificates from the remote access 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 certificate’s issuing CA and mathematically validating the digital signature.

The remote access client certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) (OID 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 remote access client, the authenticating server must have the root CA certificate of the issuing CA of the remote access 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 that specified in the EAP-Response/Identity message.

If the authenticating server is 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, IAS allows EAP-TLS clients to connect even when it does not perform or cannot complete a revocation check of the client's certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate does not 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, IAS 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. IAS 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, IAS prevents EAP-TLS from performing a revocation check of the remote access client's certificate. The revocation check verifies that the remote access client’s certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.
NoRootRevocationCheck

When set to 1, IAS prevents EAP-TLS from performing a revocation check of the remote access client'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 remote access client'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 remote access client does not use these settings.

For the remote access 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 remote access 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 certificate’s issuing CA and mathematically validating the digital signature.

Additionally, the authenticating server computer certificate must have the Server Authentication EKU (OID 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 remote access 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 remote access 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 remote access client does not yet have a physical connection to the network, and therefore cannot access a Web page or other resource to check for certificate revocation.

Possible error messages Listed below are some of the most common remote access client errors that occur when users are not able to authenticate.

Error 766 Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate. You will see this error message when such a certificate is not available.

Typically, this error is generated on a remote access server that has active L2TP ports configured, the remote access service started but there is no certificate in the computer certificate store. This generates an event log message that tells the administrator that L2TP ports will not be able to accept calls until a certificate is acquired and RRAS is restarted.

Error 781 This error message appears when the connection requires a certificate, and no valid certificate was found on the client while trying to make an L2TP call. However, this error is quite similar to Error 766 and troubleshooting methods for both these error messages will follow the same path.

Users can connect and authenticate but cannot reach locations beyond the remote access server

You may encounter situations where users can connect and authenticate but are not able to connect to any computer on the network to which the remote access server is attached. In such a situation, the following configuration details may help:

LAN protocols

Verify that the protocols being used by the remote access clients are either enabled for routing on the remote access server.

TCP/IP packet filters

You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic allowed on the remote access connection. Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the remote access server (or the RADIUS server if IAS is used) that are preventing the sending or receiving of TCP/IP traffic.

IP address allocation settings

In a situation where a static IP address pool is configured but there are no routes back to the remote access clients, you could try one of the following solutions:
- If the remote access server is configured to use a static IP address pool and the pool has one or more off-subnet address ranges, verify that the routes for the off-subnet address ranges of the static IP address pool are reachable by the hosts and routers of the intranet. If not, then IP routes consisting of the address ranges of the static IP address pool, as defined by the IP address and mask of each range, must be added to the routers of the intranet. Otherwise, the routing protocol of your routed infrastructure on the remote access server must be enabled. If the routes to the remote access client subnets are not present, remote access clients cannot receive traffic from locations on the intranet. A route for the network is 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 static IP address pool consists of ranges of IP addresses that are a subset of the range of IP addresses for the network to which the remote access server is attached, verify that the ranges of IP addresses of the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.
If the remote access server is configured to use DHCP for IP address allocation and no DHCP server is available, the remote access server allocates 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 remote access server is attached is also using APIPA addresses.
If the remote access 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. You can manually choose a LAN adapter from the IP tab on the properties of a remote access server in the Routing and Remote Access snap-in.

IPX settings

If Microsoft remote access clients using only the IPX protocol are unable to create file and print sharing connections to servers located beyond the remote access server, then NetBIOS over IPX broadcast forwarding must be enabled on the Internal interface and the appropriate LAN interfaces. For IP-based remote access clients, IP routing should be enabled. Verify that IP routing is enabled on the IP tab on the properties page of the server.
If network access is denied for IPX or AppleTalk-based remote access clients, verify that network access is allowed on the IPX or AppleTalk tabs on the properties of a server. If you do not have one or more of these tabs, then the corresponding network protocol is not installed on the server.

Users can connect, authenticate and reach locations beyond the remote access server but cannot see all the workgroups, domains, and computers in My Network Places (browsing).

In this situation, remote access clients will not be able to see all the workgroups, domains, and computers in My Network Places, also known as browsing (not to be confused with Internet browsing). However, using \\servername allows remote access clients to view the shared resources of all computers. Given below are some possible troubleshooting options:

General routing problems could be preventing the remote access clients from accessing the browse masters through the remote access server.
Faulty name resolution could also cause browsing problems. Name resolution (using WINS, DNS, or LMHOSTS files) between all browsing clients and browse masters is critical and must be working properly throughout the network for browsing to operate correctly. Verify that name resolution is working correctly.
Check for NetBIOS broadcasts on the network. These broadcasts typically do not propagate across a router and the information received by browse masters is very sensitive to the configuration of routers on an IP internetwork. Since the browser roles are determined by broadcast elections, NetBIOS broadcasts must not be forwarded. Unpredictable behavior can occur if NetBIOS broadcast traffic is forwarded in one direction but not the other. This can cause a continuous cycle of browser elections.
If you have implemented full domain browsing by using only entries in LMHOSTS files on all computers, you are limiting browsing to the local domain. This could be preventing remote access clients from browsing the network through the remote access server. It is recommended that you implement WINS for name resolution and better browsing support. Even if WINS has been implemented in the domain, non-WINS clients will still need entries in their LMHOSTS files to browse across an IP router.
Another step that can be taken to resolve browser problems is to capture network traffic with a protocol analyzer such as Microsoft Network Monitor. To directly view the communication between browsers, the Computer Browser service can be stopped and then restarted using the Service snap-in. Unfortunately, there is no guarantee that a computer assumes the same role that it had before the Computer Browser service is restarted.
You can monitor the master and backup browsers within a workgroup or domain using the command-line tool Browstat.exe. This tool is a powerful command-line browser monitoring and querying tool that ships as a Resource kit utility. For more information, see Folder Listing of the Support Tools Included in Windows 2000. To check the procedure for installation, see Install Windows 2000 support tools.
Verify the client is connected to a master browser. If the remote access server that the client is connecting to is not a master browser, then for browsing to function properly, the client should either get the broadcast messages from the other side of the remote access server or be able to reach the master browser that is receiving the broadcast messages. You can approach this problem in the following two ways:
- Verify it is possible to configure the remote access server to forward NetBIOS broadcast messages.
- If broadcast cannot be enabled, try to make the remote access server the master browser. This way it will receive all broadcast messages and have lists that can be sent in response to a browse request sent by the remote access client.

Note: To troubleshoot problems with the browser service, the Administrator must have full knowledge of the network subnet boundaries and router configurations on the network.

Miscellaneous remote access solutions

Anytime you encounter a failed remote access connection, here are a few simple things you can do to understand the nature of the error:

Server system event log: Open the system event log and look for errors that relate to a failed connection attempt.
Client tracing logs: Review all client logs to get as much information as you can on events that failed on the client side.
Server tracing logs: Review all server logs to get as much information as you can on events that failed on the server side.

If you are not getting the correct name server configuration on client, try the following:
- Verify configuration of the DHCP Relay Agent: The DHCP Relay Agent should be configured with the IP address of at least one DHCP server on your network and have the Internal interface added and enabled for relaying DHCP packets.
- If you are not using the DHCP Relay Agent, verify the name server configuration of the remote access server.