Remote Access Server

Common Remote Access Problems

Remote access problems typically include the following:

Connection attempt is rejected when it should be accepted.
Connection attempt is accepted when it should be rejected.
Unable to reach locations beyond the remote access server.
Miscellaneous remote access problems.

The following sections give troubleshooting tips to isolate the configuration or infrastructure problem causing the remote access problem.

Connection Attempt Is Rejected When It Should Be Accepted

Verify that the Routing and Remote Access Service is running on the remote access server.
Verify that remote access is enabled on the remote access server.
Verify that the dial-up ports on the remote access server are configured to allow inbound remote access connections.
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.
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 encryption method.
Verify that the parameters of the connection attempt are accepted by the currently configured dial-in properties of the user account and remote access policies.
In order for the connection to be established, the parameters of the connection attempt must:
1. Match all of the conditions of at least one remote access policy.
2. Be granted remote access permission, either through the remote access permission of the user account (set to Allow access), or the user account is set to Control access through Remote Access Policy and the remote access permission of the matching remote access policy is set to Grant remote access permission.
3. Match all the settings of the profile.
4. Match all the settings of the dial-in properties of the user account.
Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access router.
The properties of the remote access policy profile and the properties of the remote access router both contain settings for:
- Multilink
- Bandwidth allocation protocol
- Authentication protocols
If the settings of the profile 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 router, then the remote access server denies the connection attempt.
For a remote access server that is a member server in a mixed-mode or native-mode Windows 2000 domain that is configured for Windows 2000 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.
- The computer account of the remote access server computer 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. You can use the netsh ras add registeredserver command to register the server in a specified domain.
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 (due to the way that Windows 2000 caches Active Directory^™ directory service information). For the change to take effect immediately, you need to restart the remote access server computer.
Verify that your dial-up equipment is working properly.
Verify that all of the dial-up ports on the remote access server are not already connected.
Verify that the LAN protocols being used by the remote access clients are either enabled for routing or remote access.
Verify that 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.
For connections using MS-CHAP v1 and attampting to negotiate 40-bit MPPE encryption, verify that the user's password is not larger than 14 characters.
Verify that the user account has not been disabled or is not locked out on the properties of the user account. If the password on the account has expired, verify that the remote access client is using MS-CHAP v1 or MS-CHAP v2. MS-CHAP v1 and MS-CHAP v2 are the only authentication protocols provided with Windows 2000 that allow 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.
If the remote access server is configured with a static IP address pool, verify that there are enough addresses in the pool.
If all of the addresses in the static pool have been allocated to connected remote access clients, then the remote access server is unable to allocate an IP address. If the remote access client is only configured to use TCP/IP as a LAN protocol, the connection attempt is denied.
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.
If the remote access server is configured with a range of IPX network numbers, verify that the IPX network numbers in the range are not being used elsewhere on your IPX internetwork.
Verify the configuration of the authentication provider.
The remote access server can be configured to use either Windows 2000 or RADIUS to authenticate the credentials of the remote access client.
For a remote access server that is a member of a Windows 2000 native-mode domain, verify that the remote access server has joined the domain.
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 or 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, 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 computer.
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.
For RADIUS authentication, verify that the remote access server computer can communicate with the RADIUS server.
If you are using MS-CHAP v1, 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.
Verify that if the Windows 2000 Fax service and the Routing and Remote Access service are sharing the same modem, 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.

Connection Attempt Is Accepted When It Should Be Rejected

Verify that the parameters of the connection does not have permission through remote access policies.
In order for the connection to be rejected, the parameters of the connection attempt must be denied remote access permission one of two ways. Either set the remote access permission of the user account to Deny access or set the user account to Control access through Remote Access Policy, and then set the remote access permission of the first remote access policy that matches the parameters of the connection attempt to Deny remote access permission.

Unable to Reach Locations Beyond the Remote Access Server

Verify that the LAN protocols being used by the remote access clients are either enabled for routing or enabled to allow access to the network to which the remote access server is attached.
Verify the IP address allocation settings of the remote access server.
If the remote access server is configured to use a static IP address pool, verify that the destinations of the address ranges of the static IP address pool are reachable by the hosts and routers of the intranet. If not, then routes corresponding to the address ranges, 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 remote access server. If the routes to the remote access client address ranges are not present, remote access clients cannot receive traffic from locations on the intranet. Routes for the address ranges 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 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. By default, the remote access server randomly chooses the adapter to use to obtain IP addresses through DHCP. If there is more than one LAN adapter, then the Routing and Remote Access service may choose a LAN adapter for which there is no DHCP server available. 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.
If the address ranges of the static IP address pool are a subset of the range of IP addresses for the network to which the remote access server is attached, verify that the address ranges of the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.
Verify that packet filters on the remote access policy profile are not preventing the flow of needed IP traffic. TCP/IP packet filters can be configured on the profile properties of the remote access policies on the remote access server (or the RADIUS server if Internet Authentication Service is used) that are used to define traffic that is allowed on the remote access connection.
If Microsoft remote access clients using only the IPX protocol are unable to create file and print sharing connections to servers that are beyond the remote access server, then NetBIOS over IPX broadcast forwarding must be enabled on the Internal interface and the appropriate LAN interfaces. For more information on NetBIOS over IPX broadcasts, see "IPX Routing" in this book.

Callback Problems

Verify that callback is enabled on the dial-in properties of the user account.
Verify that Link Control Protocol (LCP) Extensions is enabled on the PPP tab on the properties of a remote access server in the Routing and Remote Access snap-in.
Verify that the callback numbers are not too long. Callback numbers may be truncated when a remote access server running Windows NT 4.0 requests dial-in properties of a user account in a Windows 2000 native-mode domain.