How Demand Dial Routing Works
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
In this section
Demand-Dial Routing and Routing Protocols
Demand-Dial Routing Processes and Interactions
Related Information
Microsoft Windows Server 2003 provides extensive support for demand-dial routing, which is available as part of Routing and Remote Access.
With demand-dial routing, packets are forwarded between networks and over Point-to-Point Protocol (PPP) links. The PPP link is represented inside the Windows Server 2003 router as a demand-dial interface. Demand-dial interfaces are used to connect networks (for example, between branch offices and the corporate office) through the Internet or through dial-up site-to-site virtual private networks (VPNs).
For more information about dial-up site-to-site VPNs, see “Dial-up Site-to-Site VPN” later in this section.
With local area network (LAN) and permanent wide area network (WAN) links, the interface that is used to forward the packets is always in an active or connected state. The packets can be forwarded without having to create the physical or logical connection. However, the demand-dial interface can be either in a connected state or a disconnected state, depending on the type of connection. The demand-dial interface must be changed to a connected state before the packet can be forwarded.
For information about the types of demand-dial connections, see “What Is Demand Dial Routing?.”
Note
- Because demand-dial routing is an implementation of Routing and Remote Access technologies, including unicast routing and multicasting, it is integrated within the Routing and Remote Access architecture. For information about the architecture of Routing and Remote Access, see “Unicast IPv4 Routing Technical Reference” and “IPv4 Multicasting Technical Reference.”
Demand-Dial Routing and Routing Protocols
The method for updating the routing tables of demand-dial routers depends on the type of demand-dial connection. For on-demand connections, use static routing. For persistent connections, use dynamic routing with routing protocols.
For more information about on-demand and persistent connections, see “What Is Demand Dial Routing?”
Routing with On-Demand Connections
Static routing is recommended for on-demand connections for the following reasons:
The routing protocols that are provided with Routing and Remote Access—Open Shortest Path First (OSPF) and Routing Information Protocol (RIP) for Internet Protocol (IP)—can either cause the connection to be made each time routing tables are advertised or keep the connection open permanently if the advertising interval is less than the idle time-out.
To trigger an on-demand connection, it is necessary to add static routes to the route table. RIP and OSPF do not require static routes to operate. Rather, RIP and OSPF are designed to prevent an administrator from having to add static routes to a route table. RIP and OSPF simply listen for dynamic route updates and add new routes to the route table as appropriate.
RIP for IP and OSPF detect unsuccessful network connections and, through time-out mechanisms, report these problems to neighboring routers. This means that these protocols assume that network connections are permanent unless they are disconnected. This assumption is inaccurate for on-demand connections, which are connected only when needed and are disconnected when no traffic is being routed.
Because of the time, distance, and cost-sensitive nature of typical dial-up WAN links, the use of routing protocols for on-demand connections is not recommended.
For more information about OSPF and RIP for IP, see “Unicast IPv4 Routing Technical Reference.”
Manual Configuration of Static Routes
Manual configuration of static routes is the adding of static routes (for TCP/IP traffic, static IP routes) that are available across the demand-dial interface through the use of Routing and Remote Access.
Using a Default IP Route for an On-Demand Connection
The default IP route (0.0.0.0/0) summarizes all IP destinations and becomes the route used to forward IP packets when a more specific route is not found. Although the default IP route can be used to simplify static routing for on-demand connections, be sure to use the default IP route carefully.
Using the default IP route assumes that all other destinations are in the direction of the default route. The assumption is valid if you are using a demand-dial interface to connect to the Internet. However, if you are using a demand-dial interface to connect a branch office to a corporate office in a private intranet, using the default IP route can produce undesirable results for unreachable traffic.
If a default IP route is configured to use a demand-dial interface, then it is possible that a demand-dial connection can be initiated for IP traffic that is unreachable. For example, if an organization is using the private IP network 10.0.0.0/8 for its address space and a branch office uses 10.1.1.0/24 for the hosts of the branch office, then the static routing of the branch office router can be configured as follows:
Example 1: Configure a static route for 10.0.0.0/8 using the on-demand demand-dial interface.
If someone in the branch office attempts to send traffic to the destination IP address of 192.168.0.1, the router at the branch office does not have a route in its routing table for the packet. The packet is discarded and an ICMP (Internet Control Message Protocol) Destination Unreachable-Host Unreachable message is sent to the sending host.
Example 2: Configure a default route for 0.0.0.0/0 using the on-demand demand-dial interface.
If someone in the branch office attempts to send traffic to the destination IP address of 192.168.0.1, the router at the branch office initiates the connection and forwards the packet across the demand-dial connection to the corporate router. Neither the corporate router nor another router on the corporate intranet has a route in its routing table for the packet. The packet is discarded and an ICMP Destination Unreachable-Host Unreachable message is sent to the sending host.
In Example 1, the branch office immediately determines that the IP traffic destination is unreachable and does not initiate a connection to the corporate office.
In Example 2, the IP traffic destination is determined to be unreachable only after the branch office initiates the connection and the IP traffic reaches the corporate office.
For more information about default IP routes and routing tables, see “Unicast IPv4 Routing Technical Reference.”
Auto-Static Updates
When the number of routes is large or when routes change, manual configuration of static routes is no longer a viable administrative option. For this reason, Routing and Remote Access supports auto-static updates, the process of automatically adding static routes to the routing table.
When you configure an interface to use auto-static update mode, the router sends a request to other routers and inherits routes. The routes are saved in the routing table as auto-static routes and are kept even if the router is restarted or the interface becomes unavailable. Auto-static updates are supported in RIP for IP, but are not available for use with OSPF.
Note
- The “auto” in “auto”-static refers to the automatic adding of the requested routes as static routes in the routing table. The sending of the request for routes is performed through an explicit action while the demand-dial interface is in a connected state. Auto-static updates are not automatically performed every time a demand-dial connection is made.
An auto-static update requests all known routes or services from the router on the other side of the connection and adds them to the routing tables of the requesting router. An auto-static update is a one-time, one-way exchange of routing information. After the routes are sent, the two routers do not periodically advertise even though the connection remains in a connected state.
To use auto static updates for IP routes, the demand-dial interface must be added to the RIP routing protocol. The default operation mode for demand-dial interfaces for RIP is Autostatic update mode. The default outgoing packet protocol is RIP version 2 multicast. The default settings are correct when initiating a connection with another Windows Server 2003 router.
Note
- When an auto-static update is requested, the existing routes that were obtained through a previous auto-static update are deleted before the request for routes is sent. If there is no response to the request, then the router cannot replace the routes it has deleted. This might lead to a loss of connectivity to remote networks.
Auto-static updates can be scheduled or made manually.
Scheduled Auto-Static Updates
You can schedule auto-static updates to occur periodically by using a combination of Netsh utility scripts and Task Scheduler. For more information, see “Demand Dial Tools and Settings.”
Manual Auto-Static Updates
In the Routing and Remote Access snap-in, you can manually update static IP routes.
The transfer of IP routing information occurs through RIP for IP. The router on which the update was initiated sends a General RIP Request. The router on the other end of the connection responds with a RIP Response containing all of the appropriate routes in its IP routing table. The RIP routes received by the requesting router are automatically added as static routes to the requesting router’s IP routing table. For more information about RIP messages, see “Unicast IPv4 Routing Technical Reference.”
Routing with Persistent Connections
For persistent demand-dial connections, you can enable routing protocols to operate the same way as LAN interfaces to provide dynamic updates of routing tables. The following table describes the configuration of the routing protocol for a persistent demand-dial interface.
Routing Protocol Configuration for a Persistent Demand-Dial Connection
| Routing Protocol | Configuration Change |
|---|---|
RIP for IP |
Default operation mode is Periodic update mode and triggered updates are enabled. |
OSPF |
On the General tab on the properties of an OSPF interface, select the Point-to-Point network type. This is the default network type for demand-dial interfaces. For a persistent site-to-site VPN connection, on the Advanced tab on the properties of an OSPF interface, you might want to increase the values of the transit delay, the re-transmit interval, the hello interval, and the dead interval to account for the delay of forwarding OSPF packets across the Internet. |
Routing protocols provided by Windows Server 2003 Routing and Remote Access must run over numbered connections. Although unnumbered connections are supported by Routing and Remote Access, routing protocols cannot operate over them. For unnumbered connections, you must use static routing.
For more information about numbered and unnumbered connections, see “Address Allocation for TCP/IP-Based Connections” later in this section.
Using MP and BAP
Multilink Protocol (MP) and Bandwidth Allocation Protocol (BAP) can be used with demand-dial routing to automatically add physical connections to a Multilink PPP connection when network traffic increases and remove physical connections when the network traffic decreases.
Note
- If one of the physical links of the Multilink logical link is dropped, and BAP is not being used for the connection, then the dropped link will not be redialed.
For more information about Multilink PPP, see “Dial-up Remote Access Technical Reference.”
Demand-Dial Routing Processes and Interactions
This section describes the following processes that take place when establishing demand-dial-routing connections.
Connection establishment delay
Address allocation for TCP/IP-based connections
Two-way initiated and one-way initiated connections
Dial-up site-to-site VPN connection
Connection Establishment Delay
The connection establishment process, which consists of creating a physical or a logical connection and a PPP connection, introduces a delay in the forwarding of the packet called the connection establishment delay. The length of the connection establishment delay varies, depending on the type of physical or logical connection being established. For example, the connection establishment delay for analog phone lines or X.25 dialing in to a packet assembler-disassembler (PAD) can be 10 to 20 seconds or more. For Integrated Services Digital Network (ISDN) lines, the connection establishment delay can be as short as 3 to 5 seconds.
Because the connection establishment delay affects applications that are being used across a demand-dial connection, the following factors must be considered:
How long it takes for the application to abandon the attempt to establish network communications, also known as application time-out. If the application time-out is longer than the connection establishment delay, then the application fails to establish communications and presents an error message to the user.
How many times the application attempts to establish network communications. On the first attempt, network traffic is forwarded to the demand-dial router, which begins the connection establishment process. Due to the limited size of a buffer in the router, additional packets that arrive during the connection establishment process to be forwarded across the demand-dial connection might overwrite the initial application connection attempt packet. If the application tries to establish communications multiple times, then there is a better chance of forwarding an application connection attempt packet after the connection is established.
Applications that have long time-outs or multiple retries might not fail while waiting for the link to become available. Interactive applications, such as Web browsers and Telnet, might fail when first connecting. However, when the user retries, the connection attempt succeeds because the first connection attempt created the demand-dial connection.
After the connection is established, packets are forwarded across the demand-dial connection. Because the costs of demand-dial connections are typically time-sensitive, after a configured amount of idle time, the demand-dial link is terminated.
Address Allocation for TCP/IP-Based Connections
For a TCP/IP-based demand-dial connection, TCP/IP connection settings are negotiated. An important element of a TCP/IP-based PPP connection is the allocation of an IP address.
Numbered Connections
When a call is initiated between demand-dial routers (either servers running Windows Server 2003 Routing and Remote Access or servers running Windows NT 4.0 Routing and Remote Access Service [RRAS]), the calling router requests an IP address from the answering router; the answering router requests an IP address from the calling router. If both routers have an IP address to give each other, the logical interface on the PPP connection for each router is assigned an IP address from the other router. This is known as a numbered connection.
Windows NT 4.0 Connections
Windows NT 4.0 RRAS demand-dial connections require a numbered connection. If either the calling or the answering router does not have an IP address to assign to the other router, the connection establishment process fails. For both routers to assign IP addresses to each other, you must configure both routers for the proper IP address assignment behavior through the properties of RRAS.
Note
With RRAS, the default configuration for IP address assignment is to obtain an IP address through DHCP and no DHCP server is available on the network. Because no IP address is allocated to the other router, the connection establishment process fails.
This common configuration problem is resolved by the following features in Windows Server 2003 Routing and Remote Access:
Use of Automatic Private IP Addressing (APIPA) addresses.
Support for unnumbered connections.
APIPA Addresses
In Routing and Remote Access, the default IP address assignment configuration is still to obtain an IP address from a DHCP server. However, if a DHCP server is not available, APIPA addresses in the range 169.254.0.0 through 169.254.255.255 with subnet mask 255.255.0.0 are used. Therefore, the default configuration does not prevent two routers from establishing a numbered connection. For more information about APIPA, see “DHCP Technical Reference.”
Unnumbered Connections
By default, demand-dial connections do not require a numbered connection. The calling and answering routers request an IP address from each other during the connection establishment process. However, if one of the routers rejects the request, both routers continue the connection establishment process. The logical interface on the point-to-point connection does not have an assigned IP address. This is known as an unnumbered connection.
With unnumbered connections, servers running Routing and Remote Access can connect to other routers that do not assign an IP address during the connection establishment process. For example, some Internet service providers (ISPs) prefer to use an unnumbered connection to conserve IP addresses. The Internet connection can be unnumbered because you would typically configure a default static IP route rather than run a routing protocol.
Two-Way and One-Way Initiated Connections
This section illustrates the complexity and elegance of demand-dial routing through examples of the two-way initiated and the one-way initiated connections.
The following figure shows the basic configuration between two offices that use demand-dial IP routing.
Demand-Dial IPv4 Routing Between Two Offices
.gif "Demand-Dial IPv4 Routing Between Two Offices")
The Seattle office has a server running Routing and Remote Access that acts as a remote access server and demand-dial router. All computers in the Seattle office are connected to the 172.16.1.0 network (subnet mask 255.255.255.0). The Seattle router (hereafter referred to as Router 1) has a modem connected to its COM1 port; the phone number of the modem is 555-0111.
The New York office has a server running Routing and Remote Access that acts as a remote access server and demand-dial router. All computers in the New York office are connected to the 172.16.2.0 network (subnet mask 255.255.255.0). The New York router (hereafter referred to as Router 2) has a modem connected to its COM2 port; the phone number of the modem is 555-0122.
The user on the computer with the IP address of 172.16.1.10 must be able to connect to the user on the computer with the IP address of 172.16.2.20, and vice versa.
This section describes the process by which Router 1 and Router 2 are configured; it also provides examples of two-way and one way initiated connections that use those router configurations.
Router Configuration
The following describes the configuration of Router 1 and Router 2.
Configuring Router 1
The configuration for demand-dial routing on Router 1 consists of the following three steps:
Create a demand-dial interface.
Create a static route.
Create an account that Router 2 uses when calling Router 1.
Create a demand-dial interface
By using Routing and Remote Access with the Demand-Dial Interface Wizard, the administrator at Router 1 creates a demand-dial interface called DD_NewYork with the configuration shown in the following table.
Demand-Dial Interface Configuration for Router 1
| Configuration Information | Description |
|---|---|
Equipment |
Modem on COM1 |
Phone number |
555-0122 |
Protocols |
TCP/IP |
Authentication credentials |
DD_Seattle with a password |
Create a static route
By using Routing and Remote Access, the Demand-Dial Interface Wizard will already have the name and destination of the static route with the configuration shown in the following table.
Static Route Configuration for Router 1
| Static Route Information | Description |
|---|---|
Interface |
DD_NewYork |
Destination |
172.16.2.0 |
Network mask |
255.255.255.0 |
Metric |
1 |
Note
- Because the demand-dial connection is a point-to-point connection, the gateway IP address cannot be configured.
Create a user account with dial-in permissions
By using Active Directory Users and Computers or Local Users and Groups, the administrator at Router 1 creates a user account with the settings in the following table.
User Account with Dial-In Permissions for Router 1
| Account Information | Description |
|---|---|
Account name |
DD_NewYork with a password |
Account settings |
Clear the User must change password at next logon check box and select the Password never expires check box |
The DD_NewYork account is granted dial-in permissions either through the dial-in properties of the user account or through remote access policies. For more information about remote access policies, see “Dial-up Remote Access Technical Reference” and “IAS Technical Reference.”
Configuring Router 2
The configuration for demand-dial routing on Router 2 consists of the following three steps:
Create a demand-dial interface.
Create a static route.
Create an account that Router 2 uses when calling Router 1.
Create a demand-dial interface
By using Routing and Remote Access with the Demand-Dial Interface Wizard, the administrator at Router 2 creates a demand-dial interface called DD_Seattle with the configuration shown in the following table.
Demand-Dial Interface Configuration for Router 2
| Configuration Information | Description |
|---|---|
Equipment |
Modem on COM2 |
Phone number |
555-0111 |
Protocols |
TCP/IP |
Authentication credentials |
DD_NewYork with a password |
Create a static route
By using Routing and Remote Access, the Demand-Dial Interface Wizard will already have the name and destination of the static route with the configuration shown in the following table.
Static Route Configuration for Router 2
| Static Route Information | Description |
|---|---|
Interface |
DD_Seattle |
Destination |
172.16.1.0 |
Network mask |
255.255.255.0 |
Metric |
1 |
Note
- Because the demand-dial connection is a point-to-point connection, the gateway IP address cannot be configured.
Create a user account with dial-in permissions
By using Active Directory Users and Computers or Local Users and Groups, the administrator at Router 2 creates a user account with the settings in the following table.
User Account with Dial-In Permissions for Router 2
| Account Information | Description |
|---|---|
Account name |
DD_Seattle with a password |
Account settings |
Clear the User must change password at next logon check box and select the Password never expires check box |
The DD_Seattle account is granted dial-in permissions either through the dial-in properties of the user account or through remote access policies. For more information about remote access policies, see “Dial-up Remote Access Technical Reference” and “IAS Technical Reference.”
Resulting Configuration
The following figure shows the demand-dial routing configuration in terms of the demand-dial interfaces, static routes, and user accounts for the routers for the Seattle and New York offices.
Resulting Configuration for the Seattle and New York Offices
.gif "Resulting Configuration for Seattle and New York")
Example of a Two-Way Initiated Demand-Dial Connection
For two-way initiated demand-dial routing to work properly, authentication credentials (such as user account name) for the demand-dial interface must be created on both servers running Routing and Remote Access. This example shows a proper configuration and is summarized in the following table.
Resulting Demand-Dial Routing Configuration
| Router | Demand-Dial Interface Name | User Account Name |
|---|---|---|
Router 1 |
DD_NewYork |
DD_Seattle |
Router 2 |
DD_Seattle |
DD_NewYork |
The following is an example of the process by which a two-way initiated connection takes place. For more information about two-way initiated connections, see “What Is Demand Dial Routing?.”
When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:
Packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.
Router 1 receives the packet from 172.16.1.10 and checks its routing table. It finds a route to 172.16.2.20 that uses the DD_NewYork interface.
Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.
Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.
Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.
Router 2 answers the incoming call.
Router 2 requests authentication credentials from the incoming caller.
Router 1 sends the user name, DD_Seattle, with its associated password.
Upon receiving the authentication credentials, Router 2 checks the user name and password against the security features of Windows Server 2003 and verifies that Router 1 has dial-in permission through the dial-in properties of the DD_Seattle user account and the configured remote access policies.
Router 2 must now determine whether the incoming caller is a dial-up networking client or a router that is creating a demand-dial connection. Router 2 looks in its list of demand-dial interfaces to find one that matches the user name sent by Router 1 as part of the authentication credentials. Router 2 finds a demand-dial interface, DD_Seattle, that matches the user name credential.
Router 2 changes the state of the DD_Seattle demand-dial interface to a connected state.
Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.
Router 2 receives the packet and forwards it to the computer at 172.16.2.20.
The response to the connection request by the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.
Router 2 receives the packet destined for 172.16.1.10 and checks its routing table. It finds a route to 172.16.1.10 by using the DD_Seattle interface.
Router 2 checks the state of the DD_Seattle interface and finds it is in a connected state.
Router 2 forwards the packet to Router 1.
Router 1 forwards the packet to the computer at 172.16.1.10.
Router vs. Remote Access Client
If the user name credential does not match the name of an appropriate demand-dial interface, the calling entity is identified as a remote access client, which can result in routing problems.
For example, if Router 1 uses DialUpRouter1 as its user name credential, then Router 1 is identified as a remote access client rather than a router (assuming DialUpRouter1 is a valid account with dial-in permissions). Packets are routed from the user at 172.16.1.10 to the user at 172.16.2.20, as described earlier.
However, response packets from 172.16.2.20 to 172.16.1.10 are forwarded to Router 2 which, upon inspecting its routing table, determines that the interface to use is DD_Seattle. DD_Seattle is in a disconnected state. Based on the configuration for DD_Seattle, COM2 should be used. However, COM2 is currently being used for a remote access client (Router 2). Router 2 then tries to locate a modem that is not being used. If found, Router 2 dials Router 1 and forwards the packet after the connection has been established. If another modem cannot be found, the response packets from 172.16.2.20 to 172.16.1.10 are dropped.
Example of a One-Way Initiated Demand-Dial Connection
The following is an example of the process by which a one-way initiated connection takes place. For more information about one-way initiated connections, see “What Is Demand Dial Routing?”
When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:
Packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.
Router 1 receives the packet from 172.16.1.10 and checks its routing table. It finds a route to 172.16.2.20 by using the DD_NewYork interface.
Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.
Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.
Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.
Router 2 answers the incoming call.
Router 2 requests authentication credentials from the incoming caller.
Router 1 sends the user name, DD_Seattle, with its associated password.
Upon receiving the authentication credentials, Router 2 checks the user name and password against the security features of Windows Server 2003 and verifies that Router 1 has dial-in permission through the dial-in properties of the DD_Seattle user account and the configured remote access policies.
Router 2 retrieves the static route (172.16.1.0 with the subnet mask of 255.255.255.0) that is configured on the DD_Seattle user account and creates a corresponding static route in its routing table. If Router 2 is configured with routing protocols, Router 2 uses routing protocols to communicate with neighboring routers so that the route to the Seattle network is propagated to all of the routers in the New York office.
Router 2 must now determine whether the incoming caller is a dial-up networking client or a router creating a demand-dial connection. Router 2 looks in its list of demand-dial interfaces and does not find one called DD_Seattle. Therefore, Router 2 considers the connection to the Seattle office to be a remote access connection.
Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.
Router 2 receives the packet and forwards it to the computer at 172.16.2.20.
The response to the connection request by the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.
Router 2 receives the packet destined for 172.16.1.10 and checks its routing table. A route to 172.16.1.10 is found by using the connection to Router 1.
Router 2 forwards the packet to Router 1.
Router 1 forwards the packet to the computer at 172.16.1.10.
Note
- When the connection is made, the static routes on the user account of the calling router are added to the routing table of the answering router. If routing protocols are used to propagate the new static route, then there is a delay between the time the connection is made and the time when all of the routers on the intranet of the answering router are aware of the new route. Therefore, hosts on the intranet of the calling router might experience a delay between the time that the connection is made and the time when they begin to receive traffic from hosts on the intranet of the answering router.
Dial-up Site-to-Site VPN
A site-to-site VPN connection (also known as a router-to-router VPN connection) is typically used to connect remote offices together when both routers are connected to the Internet through permanent WAN links, such as T1 or Frame Relay. In this configuration, the VPN connection is always available. However, when a permanent WAN link is not possible or practical, you can configure a dial-up site-to-site VPN connection.
The following figure shows a dial-up site-to-site VPN connection.
Dial-up Site-to-Site VPN Connection
.gif "Dial-up Site-to-Site VPN Connection")
A dial-up site-to-site VPN connection consists of two demand-dial interfaces and two static routes that are configured on the VPN client (the calling router) as follows. In this discussion, the VPN client is the branch office router.
A demand-dial interface to dial in to a local ISP.
A demand-dial interface for the site-to-site VPN connection.
A static host route to dynamically connect to the Internet.
A static route to reach the locations of the corporate office.
A dial-up site-to-site VPN connection is automatically established when you route traffic. For example, in a branch office configuration, upon receipt of a packet to be routed to the corporate office, the branch office router uses a dial-up link to connect to a local ISP and then creates a site-to-site VPN connection with the corporate office router located on the Internet.
Note
- This discussion assumes that the corporate office router (the answering router) is connected to the Internet by using a permanent WAN link. It is possible to have both routers connected to the Internet by using a dial-up WAN link. However, this is feasible only if the ISP supports demand-dialing routing to customers; the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs.
Router Configuration
The branch office router and the corporate office router must be configured for the site-to-site VPN connection.
A dial-up site-to-site VPN connection at the branch office router is configured as follows:
A demand-dial interface for the Internet connection is configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password to gain Internet access.
A demand-dial interface for the VPN connection with the corporate office router is configured for a VPN port (a Point-to-Point Tunneling Protocol [PPTP] or Layer Two Tunneling Protocol [L2TP] port), the IP address of the interface on the Internet for the corporate office router, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand-dial interface on the corporate office router.
A static host route to the corporate office router is created that uses the ISP demand-dial interface.
A static route (or routes) for the IP network IDs of the corporate intranet is created that uses the VPN demand-dial interface.
The corporate office router is configured as follows:
A demand-dial interface for the VPN connection with the branch office router is configured for a VPN port (a PPTP or L2TP port). The demand-dial interface must have the same name as the user name in the authentication credential that is used by the branch office router to create the VPN connection.
A static route (or routes) for the IP network IDs of the branch office is created that uses the VPN demand-dial interface.
Dial-up Site-to-Site VPN Connection
The dial-up site-to-site VPN connection is automatically initiated by the branch office router through the following process:
Packets sent to a corporate hub network location from a computer in the branch office are forwarded to the branch office router.
The branch office router checks its routing table and finds a route to the corporate intranet network ID, which uses the VPN demand-dial interface.
The branch office router checks the state of the VPN demand-dial interface and finds that the demand-dial interface is in a disconnected state.
The branch office router retrieves the configuration of the VPN demand-dial interface.
Based on the VPN demand-dial interface configuration, the branch office router attempts to initialize a site-to-site VPN connection at the IP address of the corporate office router on the Internet.
To establish a VPN, either a Transmission Control Protocol (TCP) (by using PPTP) or User Datagram Protocol (UDP) (by using L2TP/Internet Protocol security [IPSec]) packet must be sent to the corporate office router that acts as the VPN server. The VPN establishment packet is created.
To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route that is using the ISP demand-dial interface.
The branch office router checks the state of the ISP demand-dial interface and finds that the demand-dial interface is in a disconnected state.
The branch office router retrieves the configuration of the ISP demand-dial interface.
Based on the ISP demand-dial interface configuration, the branch office router uses its modem to dial and establish a connection with its local ISP.
Immediately after the ISP connection is made, the VPN establishment packet is sent to the corporate office router.
A site-to-site VPN connection is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router.
The corporate office router checks its demand-dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state.
The branch office router forwards the routed packet across the VPN and the corporate office router forwards the packet to the appropriate intranet location.
When the intranet location responds to the packet sent to it by the user in the branch office, the packet is forwarded to the corporate office router.
The corporate office router checks its routing table and finds a route to the branch office network that uses the VPN demand-dial interface.
The corporate office router checks the state of the VPN demand-dial interface and finds that the interface it is in a connected state.
The response packet is forwarded across the Internet by using the VPN connection.
The response packet is received by the branch office router and is forwarded to the original user.
Related Information
The following resources contain additional information that is relevant to this section.