Demand-dial routing design considerations

  • Article

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

Demand-dial routing design considerations

To prevent problems, you should consider the following design issues before you implement demand-dial routing.

On-demand or persistent connections

You must decide whether your demand-dial connections will be on-demand or persistent:

  • On-demand demand-dial connections are used when the cost of using the communications link is time-sensitive. For example, long distance analog phone calls are charged on a per-minute basis. With on-demand connections, the connection is made when traffic is forwarded, and the connection is terminated when the link is not used. You can configure idle disconnect behavior for the answering router by setting an idle disconnect through the profile properties of the remote access policy that is used for the demand-dial connection. You can configure idle disconnect behavior for the calling router on the Options tab on the properties of the demand-dial interface.

  • Persistent demand-dial connections use a dial-up link but can be left in a connected state 24 hours a day without incurring additional usage charges. Examples of persistent demand-dial connections include local calls that use analog phone lines and flat-rate ISDN.

One-way or two-way initiated connections

You must decide whether your demand-dial connections will be initiated by one router or by both routers:

  • With one-way initiated connections, one router is always the answering router and one router is always the calling router. The answering router accepts the connection and the calling router initiates the connection. One-way initiated connections are well suited to an on-demand spoke and hub topology where the branch office router is the only router that initiates the connection. One-way initiated connections require the following:

    • The answering router is configured as a LAN and demand-dial router.

    • A user account is added for the authentication credentials of the calling router that is accessed and validated by the answering router.

    • A demand-dial interface is configured at the answering router with the same name as the user account that is used by the calling router. The demand-dial interface is not used to dial out; therefore it is not configured with the phone number of the calling router or with valid user credentials.

    For an alternate configuration that does not require a demand-dial interface on the answering router, see One-way initiated demand-dial connections.

  • With two-way initiated connections, either router can be the answering router or the calling router depending on who is initiating the connection. Both routers must be configured to initiate and accept a demand-dial connection. You can use two-way initiated connections when traffic from either router can create the demand-dial connection. Two-way initiated demand-dial connections require the following:

    • Both routers are configured as LAN and demand-dial routers.

    • User accounts are added for both routers so that the authentication credentials of the calling router are accessed and validated by the answering router.

    • Demand-dial interfaces, with the same name as the user account that is used by the calling router, are fully configured at both routers, including the phone number of the answering router and user account credentials to authenticate the calling router.

Restricting the initiation of an on-demand connection

To prevent the calling router from making unnecessary on-demand dial-up connections, which may result in excessive phone charges, you can restrict the calling router from making connections in two ways:

  • Demand-dial filtering

    You can use demand-dial filtering to configure either the types of IP traffic that do not cause a connection to be made or the types of IP traffic that cause a connection to be made. For more information, see Configure demand-dial filters.

  • Dial-out hours

    You can use dial-out hours to configure the hours that a calling router is either permitted or denied to make a demand-dial connection. For more information, see Configure dial-out hours.

IP packet filters and demand-dial filters

Demand-dial filters are applied before the connection is made. IP packet filters are applied after the connection is made. To prevent the demand-dial connection from being established for traffic that is discarded by the IP packet filters:

  • If you have configured a set of output IP packet filters with the Receive all packets except those that meet the criteria listed below option, then configure the same set of filters as demand-dial filters with Initiate connection set to For all traffic except.

  • If you have configured a set of output IP packet filters with the Drop all packets except those that meet the criteria listed below option, then configure the same set of filters as demand-dial filters with Initiate connection set to Only for the following traffic.

Routing

Both routers on a demand-dial connection must have the appropriate routes in their routing tables to forward traffic across the connection. Additionally, routes in the routers of the intranets of both demand-dial routers must be present that support the two-way forwarding of traffic between any two destinations. Routes can be static or dynamic.

Static routing is recommended for on-demand connections. You can add static routes to the routing table either manually or through an auto-static update. For more information, see Add a static route or Demand-dial routing updates.

Dynamic routing is recommended for persistent connections by adding the demand-dial interface to an IP routing protocol.

Creating a remote access policy for demand-dial connections

By using remote access policies, you can create a policy that requires demand-dial connections to use a specific authentication method and encryption strength.

For example, you can create a user group account called Demand-Dial Routers whose members are the user accounts that are used by calling routers when a demand-dial connection is created. Then, you create a policy with one condition: the Windows-Group is set to Demand-Dial Routers. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength.

For more information, see Introduction to remote access policies.

User accounts for demand-dial connections

When you create a user account by using the Demand-Dial Interface wizard, the remote access permission is set to Allow access even though for a new account in a Windows 2000 or Windows Server 2003 domain or a stand-alone router, the default remote access permission for newly created accounts is set to Control access through Remote Access Policy. This behavior may cause some confusion if you are using the access-by-policy administrative model. In the access-by-policy administrative model, the remote access permission of all user accounts is set to Control access through Remote Access Policy and the remote access permission of individual policies are set to either Grant remote access permission or Deny remote access permission. For more information, see Remote Access Policies Examples.

When the user account is created, it is created with the current default password settings and policies set for your domain. Verify that the user accounts that are used by calling routers have the following settings on the General tab on the properties of the user account:

  • The User must change password at next logon check box is cleared.

    If the check box is selected, then you must manually clear this setting. Accounts created with the Demand-Dial Interface wizard automatically have this check box cleared. If you do not clear this setting, then a demand-dial router cannot connect by using this account. When the calling router sends its credentials, the calling router is prompted to change the password. Because the initiation of a demand-dial connection is not an interactive process involving a user, the calling router is unable to change the password and aborts the connection attempt.

  • The Password never expires check box is selected.

    Because the demand-dial connection process is not interactive, if the password expires, the calling router is prompted to change the expired password and the connection attempt is ended.