In Chapter 5, we reviewed components of remote access virtual private networks (VPNs)—that is, VPNs that have many remote users connecting to a VPN gateway to access internal resources. The other type of VPN connection is site-to-site, where two routers create a tunnel over the Internet that acts as a wide area network (WAN) link between the two sites. The users on either side of the link do not need to know about the VPN connection because the link is transparent to them. Site-to- site VPNs allow companies to use the Internet to connect their offices together by using VPN tunneling and encryption technology, thus saving costs on expensive private WAN links. To make wise decisions when deploying Microsoft Windows site-to-site (also known as router-to-router) VPN connections, you must understand all the components involved. In order to understand all of the functionality for site- to-site VPNs, we need to start off with an overview of demand-dial routing technology, which allows VPN routers the ability to enable and disable VPN tunnels automatically based on traffic that the routers are seeing.
As Chapter 5 did with remote access solutions, this chapter provides an overview of demand-dial routing and describes the components of site-to-site VPN connections and their associated design points.
The Microsoft Windows Server 2003 Routing And Remote Access service includes support for demand-dial routing (also known as dial-on-demand routing) over dial- up connections (such as analog phone lines or Integrated Services Digital Network [ISDN]), VPN connections, and Point-to-Point Protocol (PPP) over Ethernet (PPPoE) connections. Demand-dial routing allows the forwarding of packets across a Point- to-Point Protocol (PPP) link. The PPP link is represented inside the Windows Server 2003 Routing and Remote Access service as a demand-dial interface, which can be used to create on-demand connections across dial-up, non-permanent, or persistent media. Demand-dial connections allow you to use dial-up telephone lines instead of leased lines for low-traffic situations and to leverage the connectivity of the Internet to connect branch offices with VPN connections. When the link is always “on,” it is known as a persistent connection. If the link is only “on” when needed—that is, a connection is established only when “interesting” traffic is present and that connection is torn down when the transfer is completed—it will minimize phone costs and high-latency routing issues. This configuration is known as on-demand connection.
Demand-dial routing is not the same as remote access. While remote access connects a single computer to a network, demand-dial routing connects entire networks. However, both use PPP as the protocol with which to negotiate and authenticate the connection and encapsulate the data sent over it. As implemented in the Windows Server 2003 Routing And Remote Access service, both remote access and demand-dial connections can be enabled separately. However, they still share the same features and characteristics, including:
Dial-in properties behavior of user accounts
Security (authentication protocols and encryption)
Remote access policies usage
Windows or Remote Authentication Dial-In User Service (RADIUS) usage (for authentication, authorization, and accounting)
Internet Protocol (IP) address assignment and configuration
PPP features usage, such as Microsoft Point-to-Point Compression (MPPC), Multilink PPP, and Bandwidth Allocation Protocol (BAP)
Troubleshooting facilities, including event logging, Windows or RADIUS authentication and accounting logging, and tracing
While the concept of demand-dial routing is fairly simple, configuration of demand- dial routing is relatively complex. This complexity is due to the following factors:
Connection endpoint addressing. The connection must be made over public data networks, such as the analog phone system or the Internet. A phone number for dial-up connections and either a fully qualified host name or IP address for VPN connections must identify the endpoint of the connection.
Authentication and authorization of the caller. Anyone calling the router must be authenticated and authorized. Authentication is based on the caller’s set of credentials that are passed during the connection establishment process. The credentials that are passed must correspond to an account. Authorization is granted based on the dial-in properties of the account and remote access policies.
Differentiation between remote access clients and calling routers. Both routing and remote access services coexist on the same computer running Windows Server 2003. Both remote access clients and demand-dial routers can initiate a connection. The computer running Windows Server 2003 that answers a connection attempt must be able to distinguish a remote access client from a demand-dial router.
If the user name, which is included in the authentication credentials sent by the router that initiates the connection (the calling router), matches the name of a demand-dial interface on the Windows Server 2003 that answers the connection attempt (the answering router), the connection is a demand-dial connection. Otherwise, the incoming connection is a remote access connection. When it is identified as a demand-dial connection as opposed to a remote access connection, different operations and control sets apply.
Configuration of both ends of the connection. Both ends of the connection must be configured, even if only one end of the connection is initiating a demand-dial connection. Configuring only one side of the connection means that packets are successfully routed in only one direction. Communication typically requires that information travel in both directions. Therefore, each side of the connection needs to have routing information about the other side to understand what traffic should traverse the link. Without this information, routing will not work properly. It would seem at first glance that this is an ideal situation for dynamic routing protocols, but it is not.
Configuration of static routes. You should not use dynamic routing protocols over temporary demand-dial connections. The reason for this is because if routing updates are occurring constantly or there is a large amount of convergence traffic occurring on either side of the link, routing updates will trigger an on-demand connection needlessly. At the same time, when using demand-dial connections, an inherent problem is that a link is going up and down on the network, and this will cause needless routing updates. Therefore, routes for network IDs that are available across the demand-dial interface must be added, as static routes, to the routing tables of the demand-dial routers. By using static routing, the demand-dial links will not be part of the dynamic routing functionality and will not cause update traffic to occur. You can add static routes manually or by using auto- static updates.
While demand-dial routing can save connection costs, typical dynamic routing protocols rely on a periodic advertising process to communicate routing information. For example, Routing Information Protocol (RIP) for IP advertises the contents of its routing table every 30 seconds on all interfaces. This behavior is not a problem for permanently connected local area network (LAN) or WAN lines. For usage-sensitive dial-up WAN lines, this type of periodic behavior could cause the router to call another router every 30 seconds, which could result in an undesirable phone bill. Therefore, you should not run dynamic routing protocols across temporary dial-up WAN lines.
If you do not use dynamic routing protocols to update the routing tables, you must enter the routes as static routes. The static routes that correspond to the network
IDs available across the interface are entered manually or automatically. The automatic entering of static routes for demand-dial interfaces is known as auto-static updates and is supported by the Windows Server 2003 Routing And Remote Access service. Auto-static updates are supported when you use RIP for IP, but not when you use Open Shortest Path First (OSPF).
When instructed, a demand-dial interface that is configured for auto-static updates sends a request across an active connection to request all the routes of the router on the other side of the connection. In response to the request, all the routes of the requested router are automatically entered as static routes in the routing table of the requesting router. The static routes are persistent; they are kept in the routing table even if the interface becomes disconnected or the router is restarted. An auto-static update is a one-time, one-way exchange of routing information.
You can automate and schedule auto-static updates by executing the update as a Windows Server 2003 scheduled task. For more information, see the topic titled “Scheduling auto-static updates” in Windows Server 2003 Help And Support.
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: either through the Routing And Remote Access snap-in or the Netsh utility 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.
A site-to-site VPN connection is a demand-dial connection that uses a VPN tunneling protocol such as Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol with Internet Protocol Security (L2TP/IPSec) to connect two portions of a private network. Each VPN router provides a routed connection to the network to which that VPN router is attached. On a site-to-site VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.
The calling router (the VPN client) initiates the connection. The answering router (the VPN server) listens for connection attempts, receives the connection attempt from the calling router, and responds to the request to create a connection. The calling router authenticates itself to the answering router. When using a mutual authentication protocol such as Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2) or Extensible Authentication Protocol-Transport
Layer Security (EAP-TLS), the answering router also authenticates itself to the calling router.
Table 8-1 lists the site-to-site VPN-capable Microsoft operating systems.
VPN Tunneling Protocol
Microsoft Operating System
Windows Server 2003, Microsoft Windows 2000 Server, and Microsoft Windows NT 4.0 with the Routing And Remote Access Service (RRAS)
Windows Server 2003 and Windows 2000 Server
VPN routers can also be any computer that is capable of creating a routed PPTP connection using Microsoft Point-to-Point Encryption (MPPE) or a routed L2TP connection using IPSec encryption.
A site-to-site VPN connection can be one of two different types: on-demand or persistent. On-demand happens on an “as needed” basis and turns off when it’s no longer needed. Persistent connections stay on even after the initial traffic is forwarded that caused the connection to initiate. Further details about the two types are as follows:
An on-demand site-to-site connection is a connection that is made when traffic must be forwarded across the connection. When “interesting” traffic is seen by the router, the connection is made, the traffic is forwarded, and the connection is terminated after a configured amount of idle time. “Interesting” traffic is determined by using on-demand filter sets to identify specific traffic. You can configure idle disconnect behavior for the answering router by setting an idle disconnect on the Dial-In Constraints tab on the profile properties of the remote access policy that is used for the site-to-site VPN connection. You can configure idle disconnect behavior for the calling router on the Options tab on the properties of the demand-dial interface in the Routing And Remote Access snap-in.
A persistent site-to-site connection is always connected. If the connection is dropped, it is immediately retried. To configure the answering router for connection persistence, clear the Minutes Server Can Remain Idle Before It Is Disconnected and the Minutes Client Can Be Connected check boxes on the Dial-In Constraints tab on the profile properties of the remote access policy that is used for the site-to-site VPN connection. (These settings are disabled by default.) To configure the calling router for connection persistence, select Persistent Connection on the Options tab from the properties of the demand-dial interface.
If the calling router connects to the Internet by using a dial-up link such as an analog phone line or ISDN, you need to configure a dial-up on-demand site-to-site VPN connection consisting of a single demand-dial interface at the answering router and two demand-dial interfaces at the calling router: one to connect to a local Internet service provider (ISP) and one for the site-to-site VPN connection. Dial-up on-demand site-to-site VPN connections also require an additional host route in the IP routing table of the calling router so that the VPN router will initiate the connection to the ISP when traffic for the remote site is received. Without the inclusion of the extra route entry, the VPN router will always get a “destination unreachable” error to the sending host. For more information, see the topic titled “A dial-up router-to-router VPN connection” in Windows Server 2003 Help And Support.
For either on-demand or persistent site-to-site VPN connections, the answering router is permanently connected to the Internet so that it can always be ready to accept calls. This concept is important to understand because you cannot have both sides of the link using dial-up links to the Internet. If this was done, the connection would only if established if by chance the answering router was connected to the Internet.
In most cases, you do not want just any traffic to launch a site-to-site VPN connection. You want only “real” traffic to activate the site-to-site connection. To prevent the calling router from making unnecessary connections, you can restrict the calling router from making on-demand site-to-site VPN connections in the following ways:
Demand-dial filtering. You can use demand-dial filtering to configure either the types of IP traffic that do not cause a demand-dial connection to be made or the types of IP traffic that cause a connection to be made. To configure demand-dial filtering, right-click the demand-dial interface in the Network Interfaces node in the Routing And Remote Access snap-in, and then click Set IP Demand-Dial Filters. You can then set filters that will identify “interesting” traffic that can initiate or prevent the initiation of the link.
Dial-out hours. You can use dial-out hours to configure the hours that a calling router is either permitted or denied permission to make a site-to-site VPN connection. To configure dial-out hours, right-click the demand-dial interface in the Network Interfaces node in the Routing And Remote Access snap-in, and then click Dial-Out Hours. This setting can be useful if you do not want particular operations happening outside of a set of designated hours. For instance, if you only want e-mail traffic to activate a link, and you only want the traffic during off-hours in the night, you can use the Dial-Out Hours settings to restrict tunnel activation.
At the same time, on the answering router, you can use remote access policies to configure the times when incoming demand-dial routing connections are allowed if that makes more sense for your environment.
If you only want the remote site to initiate the VPN as needed, you want to use one-way connection setups. With one-way initiated connections, one VPN router is always the calling router and one VPN router is always the answering router. One- way initiated connections are well suited to a permanent connection spoke-and- hub topology, where the branch office router is the only router that initiates the connection. The one-way setup allows for more granular control, especially when the remote site is in another time-zone that would make high-traffic times difficult to manage for the corporate office. The big difference between one-way vs. two- way is that the calling router does not need to have an always-on Internet link. One-way initiated connections require the following configuration details:
The answering router is configured as a LAN and demand-dial router.
A user account is added to the answering router’s user directory to store 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. This demand-dial interface is not used to dial out, therefore it is not configured with the host name or IP address of the calling router or with valid user credentials.
With two-way initiated connections, either VPN router can be the calling router or answering router, depending on who is initiating the connection. Because of this, both sides have to be always-on, which adds extra costs to the configurations. Both VPN routers must be configured to both initiate and accept a site-to-site VPN connection. You can use two-way initiated connections when the site-to-site VPN connection is not active 24 hours a day and traffic from either router is used to create an on-demand connection. Two-way initiated site-to-site VPN connections require the following:
Both routers must be connected to the Internet by using a permanent WAN link.
Both routers must be configured as LAN and demand-dial routers.
User accounts must be added for both routers on the opposite side of the link so that the authentication credentials for the calling router are accessed and validated by the answering router whichever way the call is established.
Demand-dial interfaces, with the same name as the user account that is used by the calling router, must be fully configured at both routers, including settings for the host name or IP address of the answering router and user account credentials.
Table 8-2 lists a sample configuration for two-way initiated demand-dial routing between Router 1, a demand-dial router in the Seattle site, and Router 2, a demand- dial router in the New York site.
Demand-Dial Interface Name
User Account Name in User Credentials
Notice how the user account name in the user credentials of the demand-dial interface of one router matches the name of a demand-dial interface of the other router. This concept is absolutely crucial and is a concept with which many network administrators have problems.