Remote Access Troubleshooting

Article
10/08/2009

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

Troubleshooting

What problem are you having?

Unable to establish a remote access connection.
Unable to access resources beyond the remote access server.
Callback is not working.
Not sure how to configure the remote access server to make as well as receive remote access connections (dial out and dial in).

Unable to establish a remote access connection.

Cause: Your modem is not working properly.

Solution: Verify that your modem is working properly.

See also: Troubleshooting modems

Cause: The Routing and Remote Access service is not started on the remote access server.

Solution: Verify the state of the Routing and Remote Access service on the remote access server.

Cause: Remote access is not enabled on the remote access server.

Solution: Enable remote access on the remote access server.

See also: Enable the remote access server

Cause: Dial-in, PPTP, or L2TP ports are not enabled for inbound remote access connections.

Solution: Enable PPTP, L2TP, or dial-in ports for inbound remote access connections, as needed.

Cause: The LAN protocols being used by the remote access clients are not configured on the remote access server to allow remote access connections.

Solution: Verify that remote access connections are allowed on the IP 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.

Cause: All of the remote access ports on the remote access server are already being used by currently connected remote access clients or demand-dial routers.

Solution: You can verify whether all of the remote access ports on the remote access server are not already being used by clicking Ports in Routing and Remote Access. If all ports are busy, disconnect any inactive connections, or consider adding more ports.

Cause: The remote access client and the remote access server in conjunction with a remote access policy are not configured to use at least one common authentication method.

Solution: Configure the remote access client and the remote access server in conjunction with a remote access policy to use at least one common authentication method.

If a remote access client running Windows 95 is attempting a dial-up connection, verify that the remote access server is not requiring only MS-CHAP v2 authentication. A remote access client running Windows 95 supports the use of MS-CHAP v2 over virtual private network (VPN) connections, not the use of MS-CHAP v2 over dial-up connections.

Cause: The remote access client and the remote access server in conjunction with a remote access policy are not configured to use at least one common encryption strength.

Solution: Configure the remote access client and the remote access server in conjunction with a remote access policy to use at least one common encryption strength.

See also: Configure encryption

Cause: The remote access connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies.

Solution: Verify that the remote access connection has the appropriate permissions through dial-in properties of the user account and remote access policies.

In order for the connection to be established, the settings of the connection attempt must:

Match all of the conditions of at least one remote access policy.
Be granted remote access permission through the local user account (set to Allow access), or through the domain 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 all the settings of the profile.
Match all the settings of the dial-in properties of the user account.

Cause: The settings of the remote access policy profile are in conflict with properties of the remote access server.

Solution: Verify that the settings of the remote access policy profile are not in conflict with 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 settings of the profile of the matching remote access policy are in conflict with the settings of the remote access server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP is not enabled on the remote access server, the connection attempt is rejected.

Cause: The credentials of the remote access client (user name, password, and domain name) are incorrect and cannot be validated by the remote access server.

Solution: Verify that the credentials of the remote access client (user name, password, and domain name) are correct and can be validated by the remote access server.

Cause: There are not enough addresses in the static IP address pool.

Solution: 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, the remote access server is unable to allocate an IP address, and the connection attempt is rejected. Modify the static IP address pool if needed.

See also: Create a static IP address pool

Cause: The authentication provider of the remote access server is improperly configured.

Solution: Verify the configuration of the authentication provider. You can configure the remote access server to use either Windows Authentication or Remote Authentication Dial-In User Service (RADIUS) to authenticate the credentials of the remote access client.

See also: Use RADIUS authentication

Cause: The remote access server cannot access Active Directory.

Solution: For a remote access server that is a member server of a 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.
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 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 to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Active Directory information is cached). For the change to take effect immediately, you need to restart the remote access server computer.
The remote access server has joined the domain.

Cause: A remote access server running Windows NT 4.0 cannot validate connection requests.

Solution: If remote access clients are dialing in to a remote access server running Windows NT 4.0 that is a member of a Windows 2000 mixed 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, type net localgroup "Pre-Windows 2000 Compatible Access" everyone /add at the command prompt on a domain controller computer and then restart the domain controller computer.

See also: Member server in a domain

Cause: The Windows Fax service is enabled and your modem does not support adaptive answer.

Solution: If the Windows Fax service and the Routing and Remote Access service 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.

Cause: You are using MS-CHAP v1 and a user password over 14 characters long.

Solution: Either use a different authentication protocol such as MS-CHAP v2 or change your password so that it is 14 characters or less.

Unable to access resources beyond the remote access server.

Cause: For IP-based remote access clients, IP routing is not enabled.

Solution: Verify that IP routing is enabled on the IP tab on the properties of the server.

Cause: For AppleTalk-based remote access clients, network access is not allowed.

Solution: Verify that network access is allowed on the AppleTalk tab on the properties of a server. If you do not have the AppleTalk tab, then AppleTalk is not installed on the server.

Cause: A static IP address pool is configured but there are no routes back to the remote access clients.

Solution: If the remote access server is configured to use a static IP address pool, verify that the routes to the ranges of addresses 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 or 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). OSPF is not available on Windows XP 64-bit Edition (Itanium) and the 64-bit versions of the Windows Server 2003 family.

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.

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.

See also: Create a static IP address pool

Cause: Packet filters on the remote access policy profile are preventing the flow of IP traffic.

Solution: 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 Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic.

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 the profile TCP/IP packet filters are not preventing the flow of needed traffic.

See also: Configure IP options

Callback is not working.

Cause: Callback is improperly configured on the dial-in properties of the user account.

Solution: Verify the callback configuration on the dial-in properties of the user account.

See also: Configure caller ID and callback

Cause: Link control protocol (LCP) extensions is disabled on the PPP tab for the properties of the remote access server.

Solution: Enable Link control protocol (LCP) extensions on the PPP tab for the properties of the remote access server.

Cause: 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 or Windows Server 2003 domain.

Solution: Reconfigure callback numbers on the dial-in properties of the user account.

See also: Configure caller ID and callback

For more information on troubleshooting remote access VPN connections, see Troubleshooting remote access VPNs.

To reset Routing and Remote Access back to default values, see Reset the Routing and Remote Access service.

Not sure how to configure the remote access server to make as well as receive remote access connections (dial out and dial in).

Cause: The remote access server is either not configured as a remote access server (dial in) or not configured for demand-dial routing (dial out).

Solution: In the console tree, right-click the remote access server, and click Properties. On the General tab, make sure that both the Router and the Remote access server check boxes are selected, and make sure that the LAN and demand-dial routing option is selected under Router. If these options are not configured, configure them, and click OK. In the console tree, click Network Interfaces and make sure that you have configured demand-dial interfaces for dialing out to the servers or services to which you want to connect. If no demand-dial interfaces exist, right-click Network Interfaces, and click New Demand-dial Interface.

Partager via