Routing and Remote Access VPN dial-on-demand failover mechanism (262990)

MORE INFORMATION

You can use Routing and Remote Access to route traffic to a remote network using a secured VPN. You may need to have a backup access path to a remote network for critical business applications. You can configure Routing and Remote Access with two or more VPN DOD interfaces to provide access to the same remote network through a different path (and possibly a different remote VPN server). Static routes for each interface and the remote network use different metrics to determine which is the preferred interface/path. For example, a VPN DOD interface provides connectivity to network A by establishing a VPN session to a VPN server on network A. You can configure another VPN DOD interface to use a different path (and possibly a different remote VPN server) to provide access to network A in case connectivity through the first VPN DOD interface is unsuccessful.

In the following section, the two example VPN DOD interfaces (DOD1 and DOD2) are configured in Routing and Remote Access to access network A, where the static route for DOD1 has a lower metric (preferred path). The times provided below are just an example. You can use them as a reference, but they actually depend on several factors (for example, the media and hardware platform you are using).

How a Broken VPN Link Is Detected and a Backup VPN DOD Interface Is Connected

1. After the DOD1 VPN link fails, Routing and Remote Access takes 2-3 minutes to discover the broken link (with default settings) and marks DOD1 as "disconnected."
2. Routing and Remote Access then tries to reconnect DOD1. The attempt is unsuccessful (takes 15-25 seconds) and DOD1 is marked as "unreachable."
3. The second static route (used by DOD2) is plumbed into the TCP/IP stack, and it takes 15-25 seconds for DOD2 to establish a connection.

How Routing and Remote Access Monitors Connectivity on the Preferred Broken VPN Link

Routing and Remote Access continuously attempts to connect the "unreachable" interface. The time interval between each attempt increments with each attempt; each consecutive attempt has a greater time interval than the previous attempt. The following time intervals between attempts are provided as an example.

Connection Attempt Number	Approximate Time Interval
1	5 minutes
2	15 minutes
3	25 minutes
4	50 minutes
5	2 hours
6	4 hours
7	7 hours
8	10 hours

How Routing and Remote Access Reconnects the Preferred VPN DOD Interface When the Link/VPN Server Is Back Up

1. The preferred VPN DOD interface (DOD1) reconnects (15-25 seconds) after a time interval that correlates to the time DOD1 remained in an "unreachable" state.
2. The static route with the lower metric is then plumbed into the TCP/IP stack.
3. Traffic is then routed through DOD1, and DOD2 is disconnected.

Reducing the Time it Takes for Routing and Remote Access to Detect a Broken VPN Link

Note Use caution when you modify these settings as they affect all Point to Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP) connections on the computer.

PPTP and L2TP use control messages to set up, maintain, and end the tunnels. To monitor the status of a VPN session, PPTP and L2TP use a "keep alive" type of control message (PPTP uses PPTP_ECHO_REQUEST and PPTP_ECHO_REPLY messages over TCP segments; L2TP uses the HELLO message over User Datagram Protocol (UDP) datagrams).

A VPN DOD interface is marked "disconnected" after a certain number of ECHO (default is 6) or HELLO (default is 5) messages do not receive a response. You can reduce the time interval between these packets by modifying the registry.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

PPTP

For PPTP, you can modify the InactivityIdleSeconds parameter located in the following registry key where instanceid is the 000x (x is a number) key that has the DriverDesc parameter set to a value of WAN Miniport (PPTP).

The default value for the InactivityIdleSeconds parameter is 60 (seconds). If this value is set to 1, Routing and Remote Access may detect a down PPTP link in as little as 30-45 seconds.

L2TP

For L2TP, you can modify the HelloMS parameter located in the following registry key where instanceid is the 000x (x is a number) key that has the DriverDesc parameter set to a value of WAN Miniport (L2TP).

The HelloMS parameter does not exist by default and needs to be created. It is a REG_DWORD type parameter that holds a value expressed in milliseconds; when the parameter does not exist, the default value of 60000 (1 minute) is used.

Setting the HelloMS value to 1 does not reduce the time it takes for Routing and Remote Access to detect a down L2TP link as much as the InactivityIdleSeconds parameter does for PPTP links (it may reduce this time to approximately 1.5 to 2 minutes). This is because the HelloMS value is used only after a reply to a HELLO message is received or a timeout has expired. This timeout value can be set by creating the MaxSendTimeoutMs REG_DWORD parameter in the same registry key where the HelloMS parameter is created. The default is 10 seconds but the standard states that it should not be less than 8 seconds so you can only decrease this value to 8.

Another option is to decrease the number of HELLO messages that Routing and Remote Access sends (without getting a response) before marking the L2TP DOD interface as "disconnected." To set this option, create the MaxRetransmits REG_DWORD registry parameter in the same location where the HelloMS parameter is located (for example, you can set it to 1).

For additional information, click the following article number to view the article in the Microsoft Knowledge Base: