Troubleshooting demand-dial routing

Artigo
10/08/2009

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

Troubleshooting demand-dial routing

What problem are you having?

On-demand connection is not made automatically.
Unable to make a demand-dial connection.
Unable to reach locations beyond the calling router or answering router.
Auto-static updates are not working.

On-demand connection is not made automatically.

Cause: IP routing is not enabled.

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

Cause: Static routes are configured incorrectly.

Solution: Verify that the correct static routes exist and are configured with the appropriate demand-dial interface.

See also: Add a static route

Cause: A static route cannot initiate a demand-dial connection.

Solution: For the static routes that use a demand-dial interface, verify that the Use this route to initiate demand-dial connections check box is selected.

See also: Add a static route

Cause: The demand-dial interface is disabled.

Solution: Verify that the demand-dial interface is not in a disabled state. To enable, under Network Interfaces, right-click the demand-dial interface, and then click Enable.

Cause: Dial-out hours are preventing the connection from initiating.

Solution: Verify that the dial-out hours for the demand-dial interface on the calling router are not preventing the connection attempt.

See also: Configure dial-out hours

Cause: Demand-dial filters are preventing the connection from initiating.

Solution: Verify that the demand-dial filters for the demand-dial interface on the calling router are not preventing the connection attempt.

See also: Configure demand-dial filters

Unable to make a demand-dial connection.

Cause: The Routing and Remote Access service is not started on the calling router and the answering router.

Solution: Verify the state of the Routing and Remote Access service on the calling router and the answering router.

Cause: The demand-dial interface is in an unreachable state.

Solution: Determine the unreachability reason. If a demand-dial connection fails, the demand-dial interface is in an unreachable state. The Routing and Remote Access service records the reason why the connection failed through the unreachability reason. Based on the information in the unreachability reason, you can perform further troubleshooting.

See also: Check the unreachability reason

Cause: LAN and WAN routing is not enabled on the calling router and the answering router.

Solution: Enable LAN and demand-dial routing on the calling router and the answering router.

See also: Enable LAN and WAN routing

Cause: Demand-dial connections for the protocols being routed are not allowed.

Solution: Verify that IP-based remote access and demand-dial connections are allowed (on the IP tab on the properties of the server).

Cause: Dial-up, PPTP, or L2TP ports are not enabled for inbound and outbound demand-dial routing connections.

Solution: Enable dial-up, PPTP, or L2TP ports for inbound and outbound demand-dial routing connections.

See also: Enable routing on ports

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

Solution: Verify that not all of the ports are already being used by clicking Ports in Routing and Remote Access. For VPN connections, if necessary, change the number of PPTP or L2TP ports to allow more concurrent connections.

See also: Add PPTP or L2TP ports

Cause: For VPN connections, the tunneling protocol of the calling router is not supported by the answering router.

By default, VPN-based demand-dial interfaces use the Automatic server type option, which means that they try to establish a PPTP-based VPN connection first, and then they try an L2TP/IPSec VPN connection. If calling routers use either the Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the answering router.

By default, a server running Routing and Remote Access is a PPTP and L2TP-capable demand-dial router. To create a PPTP-only router, set the number of L2TP ports to zero. To create an L2TP-only router, set the number of PPTP ports to one.

Solution: Verify that the appropriate number of PPTP or L2TP ports is configured on the calling router and answering router.

See also: Add PPTP or L2TP ports

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

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

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

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

See also: Configure encryption

Cause: The account option on the Account tab on the properties of the user account of the calling router is configured to change the password at the next logon attempt.

Solution: Clear the User must change password at next logon check box on the Account tab on the properties of the user account of the calling router.

Cause: The password of the user account of the calling router has expired.

Solution: Reset the password and select the Password never expires check box on the Account tab on the properties of the user account of the calling router.

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

Solution: Verify that the demand-dial connection has the appropriate permissions through dial-in properties of the user account 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 an 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 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 answering router.

Solution: 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, 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 answering router, the connection attempt is rejected.

Cause: The credentials of the calling router (user name, password, and domain name) are incorrect and cannot be validated by the answering router.

Solution: Verify that the credentials of the calling router (user name, password, and domain name) are correct and can be validated by the answering router.

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

Solution: 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 remote access clients or demand-dial routers, the answering router 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 answering router is improperly configured.

Solution: Verify the configuration of the authentication provider. You can configure the answering router to use either the security features of the Windows Server 2003 family or RADIUS to authenticate the credentials of the VPN client.

See also: Use RADIUS authentication

Cause: The answering router cannot access Active Directory.

Solution: For an answering router 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 answering router 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 answering router computer to the RAS and IAS Servers security group, the change will not take effect immediately (due to the way that the Windows Server 2003 family caches Active Directory information). For the change to take effect immediately, you need to restart the answering router computer.
The answering router has joined the domain.

Cause: An answering router running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) cannot validate connection requests.

Solution: If calling routers are dialing in to an answering router running Windows NT 4.0 with RRAS that is a member of a 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.

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

Solution: Verify that if the 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 the Fax Service on the modem to receive incoming demand-dial or remote access connections.

Cause: The calling router is not correctly configured for certificate-based demand-dial routing.

Solution: Verify that EAP is enabled as an authentication protocol. Verify that the correct certificate for the root certification authority certificate of the answering router is selected. Verify that the correct router (offline request) certificate is selected when configuring the credentials of the demand-dial interface.

Cause: The answering router is not correctly configured for certificate-based demand-dial routing.

Solution: Verify that EAP is enabled as an authentication protocol. Verify that the correct computer certificate for the root certification authority of the answering router is selected.

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 reach locations beyond the calling router or answering router.

Cause: IP routing is not enabled.

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

Cause: The appropriate demand-dial interface has not been added to the protocol being routed.

Solution: Add the appropriate demand-dial interface to the protocol being routed.

See also: Add a routing interface

Cause: There are no routes on both sides of the demand-dial connection that support the two-way exchange of traffic.

Solution: Unlike a remote access connection, a demand-dial connection does not automatically create a default route. You need to create routes on both sides of the demand-dial connection so that traffic can be routed to and from the other side of the demand-dial connection.

You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent demand-dial connections, you can enable Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the demand-dial connection. OSPF is not available on Windows XP 64-bit Edition (Itanium) and the 64-bit versions of the Windows Server 2003 family. For on-demand demand-dial connections, you can automatically update routes through an auto-static RIP update.

Cause: There are no routes on the calling router and answering router's intranet that support the forwarding of packets between hosts on the intranets.

Solution: Verify that there are routes in the intranet routers on the calling router and answering router's intranet so that all locations on both networks are reachable. You can add routes 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.

Cause: A two-way initiated, demand-dial connection is being interpreted by the answering router as a remote access connection.

Solution: 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 credentials for the calling router must match the name of a demand-dial interface that is 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 user name credential for the calling router appears under Remote Access Clients in Routing and Remote Access, 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 answering router. The user names and demand-dial interface names must be properly matched. For example, two-way initiated connections would 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.

Cause: Static routes on the user account of the calling router for a one-way initiated demand-dial connection are not configured correctly.

Solution: 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.

Cause: Packet filters on the demand-dial interfaces of the calling router or answering router are preventing the flow of traffic.

Solution: Verify that there are no IP packet filters on the demand-dial interfaces of the calling router or the answering router that prevent the sending or receiving of TCP/IP traffic.

You can configure each demand-dial interface with IP input and output filters to control the exact nature of TCP/IP traffic that is allowed into and out of the demand-dial interface.

See also: Manage Packet Filters

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 policy being used by the demand-dial connection (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 demand-dial connection.

See also: Configure IP options

Auto-static updates are not working.

Cause: For IP auto-static updates, each demand-dial interface is not configured for RIP v2 multicast.

Solution: Verify on both routers that the demand-dial interface is added to the RIP routing protocol, that its operation mode is set to Auto-static update mode, the outgoing packet protocol is RIP version 2 multicast, and that the incoming packet protocol is set to RIP version 1 and 2.

Note

On Windows Server 2003, Web Edition, and Windows Server 2003, Standard Edition, you can create up to 1,000 Point-to-Point Tunneling protocol (PPTP) ports, and you can create up to 1,000 Layer Two Tunneling protocol (L2TP) ports. However, Windows Server 2003, Web Edition, can accept only one virtual private network (VPN) connection at a time. Windows Server 2003, Standard Edition, can accept up to 1,000 concurrent VPN connections. If 1,000 VPN clients are connected, further connection attempts are denied until the number of connections falls below 1,000.

Partilhar via

Troubleshooting demand-dial routing