What Is Demand Dial Routing?
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
In this section
Types of Demand-Dial Connections
Components of a Demand-Dial Connection
Demand-Dial Routing vs. Remote Access
Components of Secure Demand-Dial Connections
Related Information
Demand-dial routing is available as part of Routing and Remote Access that is included in Microsoft Windows Server 2003.
Demand-dial routing is the forwarding of packets over Point-to-Point Protocol (PPP) links within a wide-area network (WAN) infrastructure of dial-up telecommunications technologies, including Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), X.25, and Asynchronous Transfer Mode (ATM) over asymmetric digital subscriber line (ADSL). Demand-dial routing allows you to connect branch offices through the Internet and to implement dial-up site-to-site virtual private network (VPN) connections.
For more information about dial-up telecommunications technologies, see “Dial-up Remote Access Technical Reference.”
Types of Demand-Dial Connections
Demand-dial connections are characterized as either on-demand or persistent and as either two-way initiated or one-way initiated.
These characteristics determine the configuration of the demand-dial interface.
On-Demand and Persistent Connections
Demand-dial connections are either on-demand or persistent.
On-Demand Connections
On-demand connections are used when the cost of using the communications link is time-sensitive. For example, the charges for long distance analog phone calls are on a per-minute basis. On-demand connections make the connection when traffic is forwarded and terminate the connection after a configured amount of idle time.
Idle disconnect behavior is configured on the calling router and the answering router.
On the calling router, the idle disconnect time is set on the General tab of the properties of the demand-dial interface.
On the answering router, the idle disconnect time is set on the Dial-In Constraints tab of the profile properties of the remote access policy being used by the demand-dial connection.
Persistent Connections
Persistent connections use a dial-up WAN technology when the cost of the link is fixed and the connection can be active 24 hours a day. Examples of WAN technologies for persistent demand-dial connections include local calls that use analog phone lines, leased analog lines, and flat-rate ISDN. If a persistent connection is lost, the calling router immediately attempts to reestablish the connection.
Persistent connection behavior must be configured on the calling router and the answering router.
Two-Way and One-Way Initiated Connections
Demand-dial connections are either two-way initiated or one-way initiated.
Two-Way Initiated Connections
With two-way initiated connections, either router can be the answering router or the calling router, depending on which router initiates the connection. Both routers must be configured to initiate and accept a demand-dial connection. You use two-way initiated connections when traffic from either router can create the demand-dial connection. Two-way initiated demand-dial connections require that:
Both routers are configured as local area network (LAN) and WAN 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 are fully configured on both routers and include the phone number of the answering router and user account credentials to authenticate the calling router.
Static routes are configured on both routers.
For two-way initiated demand-dial routing to work properly, the user account names of the calling routers on both sides of the connection must match the name of a demand-dial interface. The following table shows an example of this configuration.
Example of Two-Way Initiated Connection Configuration
| Router | User Account Name | Demand-Dial Interface Name |
|---|---|---|
Corporate office router |
CorpHub |
NewYorkRouter |
Branch office router |
NewYorkRouter |
CorpHub |
For a description of the two-way connection process, see “How Demand Dial Routing Works.”
One-Way Initiated Connections
With one-way initiated connections, one router is always the answering router and the other router is always the calling router. In one-way initiated connections, the routing configuration is simplified because user accounts, demand-dial interfaces, and static IP routes do not need to be fully configured on both sides of the connection. Instead of configuring a demand-dial interface and static routes on the answering router, static routes are added to the dial-in properties of the user account of the calling router.
If your answering router is in a Windows Server 2003 or Windows 2000 Server mixed-mode domain or in a Microsoft Windows NT version 4.0 domain, static routes on the user account are not available. In this case, one-way initiated connections require that:
Both routers are configured as LAN and WAN routers.
A user account is added for the authentication credentials of the calling router.
A demand-dial interface is configured at the calling router with the user credentials of the user account. 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. Because the demand-dial interface of the answering router is not used to dial out, it is not configured with the phone number of the calling router or with valid user credentials.
For a description of the one-way connection process, see “How Demand Dial Routing Works.”
Components of a Demand-Dial Connection
A demand-dial connection contains the following components:
Calling router, which initiates the demand-dial connection.
Answering router, which accepts the demand-dial connection initiated by the calling router.
Connection medium, which is either a physical medium or a tunnel medium. For more information about connection media, see “Connection Medium” later in this section.
Components of a Demand-Dial Connection
.gif "Components of a Demand-Dial Connection")
Common Components for Routers
The following components are common to both the calling router and the answering router:
Routing and Remote Access
Port
Routing and Remote Access
Routing and Remote Access on the calling router must be configured as a LAN and WAN router and configured for IP address allocation and authentication methods. IP addresses can be allocated either by using Dynamic Host Configuration Protocol (DHCP) or a static address pool.
Port
A port is a logical or physical communications channel that can support a single PPP connection. Physical ports are based on equipment installed in the calling router. VPN ports are logical ports.
Calling Router Components
In addition to Routing and Remote Access and a port, the calling router contains the following components:
Demand-dial interface
Route
Demand-Dial Interface
A demand-dial interface configured on the calling router represents the PPP connection and contains configuration information such as the port to use, the addressing used to create the connection (such as a phone number), authentication and encryption methods, and authentication credentials.
Route
An IP route in the routing tables of the calling router is configured to use a demand-dial interface to forward traffic.
Answering Router Components
In addition to Routing and Remote Access and a port, the answering router contains the following components:
User account
Demand-dial interface
Route
Remote access policy
Note
- Two-way initiated and one-way initiated connections require different configurations for the answering router. For more information about two-way initiated and one-way initiated connections, see “Types of Demand-Dial Connections” in this section.
User Account
To authenticate the calling router, the credentials of the calling router must be verified by the properties of a corresponding user account. A user account for the calling router must be either locally present or available through Windows Server 2003 security. If the answering router is configured for RADIUS authentication, then the RADIUS server must have access to the user account of the calling router.
The user account must have the following settings:
On the Dial-in tab, remote access permission is set to either Allow access or Control access through Remote Access Policy.
On the General or Account tab, User must change password at next logon is disabled and Password never expires is enabled.
For a one-way initiated connection, configure static IP routes that are added to the answering router’s routing table when the demand-dial connection is made.
Demand-Dial Interface
For two-way initiated connections, a demand-dial interface configured on the answering router represents the PPP connection to the calling router. For a one-way initiated connection using static routes on the user account of the calling router, a demand-dial interface on the answering router does not need to be configured.
Route
For two-way initiated connections, an IP route in the routing tables of the calling router is configured to use a demand-dial interface to forward traffic.
For one-way initiated connections, you can configure the user account of the calling router with static IP routes.
Remote Access Policy
To specify connection parameters that are specific to demand-dial connections, create a separate remote access policy that uses the Windows-Groups attribute set to the group, which has all of the user accounts for calling routers as members. A separate remote access policy for demand-dial connections is not required.
Connection Medium
The PPP link is established over either a physical medium or a tunnel medium. Physical media includes PSTN, ISDN, X.25, and ATM over ADSL. Tunnel media includes Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). For more information about PPP, see “Dial-up Remote Access Technical Reference.”
PPPoE
PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet network. Using PPPoE and a broadband modem, LAN clients can gain individual authenticated access to high-speed data networks. For more information about PPPoE, see “Dial-up Remote Access Technical Reference.”
Demand-Dial Routing vs. Remote Access
Remote access is not the same as demand-dial routing. Remote access connects a single user to a network. Demand-dial routing connects networks together. However, both remote access and demand-dial routing use PPP to negotiate and authenticate the connection and encapsulate data sent on the connection. As implemented in Routing and Remote Access for Windows Server 2003, both remote access and demand-dial connections can be enabled separately but share the same:
Behavior of the dial-in properties of user accounts.
Security, including authentication protocols and encryption.
Use of remote access policies.
Use of Windows or Remote Authentication Dial-In User Service (RADIUS) as authentication providers.
IP address allocation configuration.
Use of PPP features, such as Microsoft Point-to-Point Compression (MPPC), Multilink Protocol (MP), and Bandwidth Allocation Protocol (BAP).
Troubleshooting facilities, including event logging, Windows or RADIUS authentication and accounting, logging, and tracing.
Remote Access Clients and Routers
Because the routing service and the remote access service coexist on a server running Routing and Remote Access, both routers and remote access clients can call the same phone number. The server running Routing and Remote Access that answers the call must be able to distinguish a remote access client from a router that is calling to create a demand-dial connection. To differentiate a remote access client from a demand-dial router, the user name in the authentication credentials sent by the calling router must exactly match the name of a demand-dial interface on the answering router. Otherwise, the incoming connection is assumed to be a remote access connection.
Components of Secure Demand-Dial Connections
Security for demand-dial connections uses the following security methods:
Remote access permission
User-level and computer-level authentication
One-way and mutual authentication
Encryption
Packet filtering
For information about callback and caller ID, see “Dial-up Remote Access Technical Reference.” For information about remote access account lockout, see “IAS Technical Reference.”
Remote Access Permission
The user account of the calling router must be a valid account in the security database of the answering router or RADIUS server (if RADIUS authentication is being used); it must be granted remote access permission either explicitly in the user account (remote access permission of the dial-in properties of the user account is set to Allow access) or implicitly through the remote access permission setting on a remote access policy (the remote access permission of the dial-in properties of the user account is set to Control access through Remote Access Policy and a matching remote access policy remote access permission is set to Grant remote access).
User-Level and Computer-Level Authentication
The calling router can be authenticated at the user level and the computer level.
User-Level Authentication
As part of the PPP connection establishment process, the calling router’s credentials must be authenticated. User-level authentication occurs through one of the following PPP authentication methods:
Password Authentication Protocol (PAP)
Shiva Password Authentication Protocol (SPAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP)
Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2)
Extensible Authentication Protocol-Message Digest 5 Challenge (EAP-MD5)
Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)
For all of the authentication methods except EAP-TLS, the calling router’s credentials consist of a user name, a domain, and a password. For all of the authentication methods except PAP, the password is sent over the connection in an encrypted or hashed form.
In the case of EAP-TLS, the calling router’s credentials consist of a user certificate that is validated by the answering router. EAP-TLS requires a public key infrastructure (PKI) to issue and validate certificates.
For more information about PPP authentication protocols, see “Dial-up Remote Access Technical Reference.”
Computer-Level Authentication
Computer-level authentication for demand-dial routing occurs in the following cases:
When Internet Protocol security (IPSec) is used for a L2TP over IPSec demand-dial connection, computer-level authentication is performed through the exchange of computer certificates (also known as machine certificates) during the establishment of the IPSec security association.
When EAP-TLS is used for user-level authentication, the answering router authenticates itself to the calling router by sending its computer certificate.
Computer certificates require a PKI to issue and validate certificates.
One-Way and Mutual Authentication
Authentication of the demand-dial routing connection can be one-way or mutual.
One-Way Authentication
With one-way authentication, the calling router authenticates itself to the answering router. PAP, SPAP, CHAP, MS-CHAP v1, and EAP-MD5 authentication methods provide for the passing of credentials from the calling router to the answering router only. With one-way authentication, the calling router does not receive any verification that the answering router is the authorized router. One-way authentication does not provide protection from unauthorized or masquerading answering routers.
Mutual Authentication
With mutual authentication, the calling router authenticates itself to the answering router and the answering router authenticates itself to the calling router. Both ends of the connection verify the identity of the other end of the connection. MS-CHAP v2 and EAP-TLS authentication methods provide mutual authentication.
With MS-CHAP v2, both sides of the connection send a hash of a challenge string and the user password. If successful, both ends of the connection receive verification that the other end of the connection has access to the user account’s password.
With EAP-TLS, the calling router sends a user certificate that is validated by the answering router and the answering router sends a computer certificate that is validated by the calling router. EAP-TLS is the most secure form of mutual authentication; however, it requires a PKI.
Windows NT 4.0 with the Routing and Remote Access Service (RRAS) supports a feature called two-way authentication. Two-way authentication uses one-way authentication methods to perform mutual authentication. When two-way authentication is enabled on a demand-dial interface, the calling router forces the answering router to authenticate itself after the calling router authenticates itself to the answering router. A Windows 2000 calling router never requests to authenticate a Windows NT 4.0 RRAS answering router. However, a Windows 2000 answering router authenticates itself when requested by a Windows NT 4.0 RRAS calling router.
Encryption
There are two forms of encryption available for demand-dial connections: Microsoft Point-to-Point Encryption (MPPE) and IPSec.
MPPE
All PPP connections, including PPTP but not including L2TP, can use MPPE. MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and is used only when the EAP-TLS, MS-CHAP, or MS-CHAP v2 authentication methods are used.
MPPE can use 40-bit, 56-bit, or 128-bit encryption keys — the higher the number of bits, the higher the key strength. The 40-bit key is designed for backward compatibility and international use. The 56-bit key is designed for international use and adheres to United States encryption export laws. The 128-bit key is designed for North American use. By default, the highest key strength supported by the calling router and answering router is negotiated during the connection-establishment process. If the answering router requires a higher key strength than is supported by the calling router, the connection attempt is rejected.
IPSec
For demand-dial connections using L2TP over IPSec, encryption is determined by the establishment of the IPSec security association (SA). The available encryption algorithms include:
Data Encryption Standard (DES) with a 56-bit key.
Triple DES (3DES), which uses three 56-bit keys and is designed for high-security environments.
The initial encryption keys are derived from the IPSec authentication process. For more information, see “VPN Technical Reference.”
Packet Filtering
Routing and Remote Access supports IP packet filtering, which prevents certain types of network packets from either being sent or received. IP packet filtering specifies the type of traffic that is allowed into (input filters) and out of (output filters) the router.
Demand-Dial Interface Packet Filtering
You can set packet filters for each demand-dial interface and configure the filters to do one of the following:
Pass through all traffic except packets prohibited by the filters.
Discard all traffic except packets allowed by the filters.
IP packet filtering only occurs when the demand-dial interface is in a connected state.
Packet filtering is especially useful for an extranet, a portion of your private intranet that is accessible to business partners over demand-dial connections. For example, when a business partner makes a demand-dial connection, packet filters on the demand-dial interface can restrict the TCP/IP traffic to specific network segments or specific resources, as identified by IP address and TCP or UDP port number.
Remote Access Policy Profile Packet Filtering
In addition to demand-dial interface packet filtering, IP packet filters can be configured on the profile of the remote access policy configured for calling routers. While primarily designed to restrict the traffic of remote access connections, remote access policy profile-based IP packet filters can be used for demand-dial routing. Rather than configure the same IP packet filters on many demand-dial interfaces, if all the demand-dial connections share the same IP packet filters and remote access policy, then remote access policy profile packet filters allow you to configure the IP packet filters once for all of the demand-dial connections.
Related Information
The following Technical References contain additional information that is relevant to this section.