Troubleshooting Demand-Dial Routing

Remote access problems typically include the following:

• On-demand connection not being made automatically.
• Unable to make demand-dial connection.
• Unable to reach locations beyond the calling router or answering router.
• Autostatic updates not working.

The following sections give troubleshooting tips to isolate the configuration or infrastructure problem causing the demand-dial routing problem.

On-demand connection not being made automatically

• Verify that the correct static routes exist and are configured with the appropriate demand-dial interface.
• For the static routes using a demand-dial interface, verify that the Use this route to initiate demand-dial connections check box is selected.
• Verify that the demand-dial interface is not in a disabled state. To enable, right-click the demand-dial interface and select Enable.
• Verify that the dial-out hours for the demand-dial interface on the calling router are not preventing the connection attempt.
• Verify that the demand-dial filters for the demand-dial interface on the calling router are not preventing the connection attempt.

Unable to make a demand-dial connection

• Verify that the Routing and Remote Access service is running on both the calling router and the answering router.
• Verify that routing is enabled with local and remote routing (LAN and WAN routers) on both the calling router and the answering router.
• Verify that the dial-up ports being used on both the calling router and answering router are configured to allow demand-dial routing (inbound and outbound).
• Verify that all of the dial-up ports on both the calling router and answering router are not already connected.
• Verify that the calling router and the answering router in conjunction with a remote access policy are enabled to use at least one common authentication method.
• Verify that the calling router and the answering router in conjunction with a remote access policy are enabled to use at least one common encryption method.
• Verify that the calling router's credentials consisting of user name, password, and domain name are correct and can be validated by the answering router.
• For demand-dial connections using MS-CHAP v1 and attempting to negotiate 40-bit MPPE encryption, verify that the user's password is not larger than 14 characters.
• Verify that the user account of the calling router 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 of the calling router has not been locked out due to remote access account lockout. For more information, see "Remote Access Server" in this book.
• Verify that account options on the Account tab on the properties sheet of the user account of the calling router are configured to not change the password at the next logon attempt, so that the password never expires.
• Verify that the parameters of the connection attempt are accepted by the currently configured dial-in properties of the user account of the calling router and remote access policies. If the answering router is configured to use Windows authentication, the remote access policies stored on the answering router are used. If the answering router is configured to use RADIUS authentication and the RADIUS server being used is a Windows 2000 Internet Authentication Service (IAS) server, then the remote access policies of the IAS server are used.

  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 answering router.

  The properties of the remote access policy profile and the properties of the answering 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 answering 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 answering router, then the answering router denies the connection attempt.

• If the answering router 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 demand-dial routers or remote access clients, then the answering router is unable to allocate an IP address. If the calling router is only configured to route IP packets, the connection attempt is aborted.

• Verify the configuration of the authentication provider of the answering router.

  The answering router can be configured to use either Windows authentication or RADIUS to authenticate the credentials of the calling router. If RADIUS is selected, verify the RADIUS configuration of the answering router.

• For an answering router that is a member server in 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 in the Active Directory^™ directory service. 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 answering router 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 the answering router computer to the RAS and IAS Servers security group, the answering router might not immediately authenticate the credentials of incoming connections (due to the way that Windows 2000 caches authentication information). For immediate authentication ability, you need to restart the answering router.

• For an answering router that is a member of a Windows 2000 native-mode domain, verify that the answering router has joined the domain.
• For a Windows NT version 4.0 Service Pack 4 and later answering router that is a member of a Windows 2000 mixed-mode domain or a Windows 2000 answering router 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 answering router 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 answering router computer can communicate with the RADIUS server.
• If the answering router is using Windows authentication and is a member of Windows 2000 mixed-mode domain, when the mixed-mode domain is upgraded to a native mode domain, you must restart the answering router computer before the answering router can successfully authenticate calling router and remote access credentials.
• Verify that if 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 demand-dial routing and remote access connections.
• For certificate-based demand-dial routing, verify the following on the calling router:
  • EAP is enabled as an authentication protocol.
  • The correct certificate for the root certificate authority certificate of the answering router is selected.
  • The correct router (offline request) certificate is selected when configuring the credentials of the demand-dial interface.
• For certificate-based demand-dial routing, verify the following on the answering router:
  • EAP is enabled as an authentication protocol.
  • The correct machine certificate for the root certificate authority of the answering router is selected.

Unable to reach locations beyond the calling router or answering router

• For a two-way initiated demand-dial connection, verify that the demand-dial connection is not being interpreted as a remote access connection. In order for the answering router to determine that the incoming call is a router rather than remote access client, the user name of the calling router's credentials must match the name of a demand-dial interface configured on the answering router.

  If the incoming caller is a router, the port on which the call was received shows a status of Active, and the corresponding demand-dial interface is in a Connected state. If the name of the calling router's user name credential appears under Remote Access Clients, then the calling router has been interpreted by the answering router as a remote access client.

  For two-way initiated connections, either router can be the calling router or the called router. The user names and demand-dial interface names must be properly matched. For example, two-way initiated connections should work under the following configuration:

  Router 1 has a demand-dial interface called NEW-YORK, which is configured to use SEATTLE as the user name when sending authentication credentials.

  Router 2 has a demand-dial interface called SEATTLE, which is configured to use NEW-YORK as the user name when sending authentication credentials.

  This example assumes that the SEATTLE user name can be validated by Router 2 and the NEW-YORK user name can be validated by Router 1.

• For a one-way initiated demand-dial connection, verify that the appropriate static routes are enabled on the user account of the calling router and that the answering router is configured with a routing protocol so that when a connection is made, the static routes of the user account of the calling router are advertised to neighboring routers.
• Verify that there are routes on both sides of the demand-dial connection that support the two-way exchange of traffic. Unlike a remote access client connection, a demand-dial connection does not automatically create a default IP route. Routes on both sides of the demand-dial connection have to be created so that traffic can be routed to and from the other side of the demand-dial connection.
• Verify that there are routes in the intranet routers on the calling router and answering router's intranet that support the forwarding of packets between hosts on the intranets. Routes can be added to the routers of each intranet through static routes or by enabling a routing protocol on the intranet interface of the calling and answering routers.
• Verify that there are no IP or IPX packet filters on the demand-dial interfaces that are preventing the flow of wanted traffic. Each demand-dial interface can be configured with IP and IPX input and output filters that allow you to control the exact nature of TCP/IP and IPX traffic allowed in to and out of the demand-dial interface.
• Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the answering router (or the RADIUS server if IAS is used) that are preventing the sending or receiving of TCP/IP traffic.

Autostatic updates not working

• For IP autostatic updates, verify on both routers that the appropriate demand-dial interface is added to the RIP routing protocol, that its operation mode is set to Autostatic update mode, and that the outgoing packet protocol is RIP version 2 multicast.
• For IPX autostatic updates, verify that the desired demand-dial on both routers is added to the RIP for IPX and SAP for IPX routing protocols and that for each routing protocol, the update mode is set to Autostatic.

© 1985-2000 Microsoft Corporation. All rights reserved.