Introduction (Virtual Private Networking with Windows Server 2003: Deploying Site-to-Site VPNs)
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. With a VPN, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point private link (such as a long haul T-Carrier-based wide area network [WAN] link). Virtual private networking is the act of creating and configuring a virtual private network.
To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information, which allows the data to traverse the shared or public network to reach its endpoint. To emulate a private link, the data is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The logical link over which the private data is encapsulated and encrypted is a VPN connection.
Figure 1 shows the logical equivalent of a VPN connection.
Figure 1: The logical equivalent of a VPN connection
Users working at home or on the road can use VPN connections to establish a remote access connection to an organization server by using the infrastructure provided by a public network such as the Internet. From the user's perspective, the VPN connection is a point-to-point connection between the computer (the VPN client) and an organization server (the VPN server). The exact infrastructure of the shared or public network is irrelevant because it appears logically as if the data is sent over a dedicated private link.
Organizations can also use VPN connections to establish site-to-site connections with geographically separate offices or with other organizations over a public network such as the Internet while maintaining secure communications. A site-to-site VPN connection across the Internet logically operates as a dedicated WAN link.
With both remote access and site-to-site connections, an organization can use VPN connections to trade long-distance dial-up or leased lines for local dial-up or leased lines to an Internet service provider (ISP).
There are two types of PPP-based site-to-site VPN technology in the Windows Server 2003 operating system:
Point-to-Point Tunneling Protocol (PPTP)
PPTP uses user-level Point-to-Point Protocol (PPP) authentication methods and Microsoft Point-to-Point Encryption (MPPE) for data encryption.
Layer Two Tunneling Protocol (L2TP) with Internet Protocol security (IPSec)
L2TP with IPSec (L2TP/IPSec) uses user-level PPP authentication methods and IPSec for computer-level authentication using certificates and data authentication, integrity, and encryption.
Using IPSec tunnel mode for site-to-site VPN connections is possible using computers running Windows Server 2003. Because the IPSec tunnel is not represented as a logical interface over which packets can be forwarded and received, routing protocols do not operate over IPSec tunnels. Because the configuration of IPSec tunnels for site-to-site VPN connections is vastly different, it is not discussed here. For more information, see article 252735, "How to Configure IPSec Tunneling in Windows 2000," in the Microsoft Knowledge Base.
For encryption, you can use either link encryption or end-to-end encryption in addition to link encryption:
Link encryption encrypts the data only on the link between the routers. For PPTP connections, you must use MPPE in conjunction with MS-CHAP, MS-CHAP v2, or EAP-TLS authentication. For L2TP/IPSec connections, IPSec provides encryption on the link between the routers.
End-to-end encryption encrypts the data between the source host and its final destination. You can use IPSec after the site-to-site VPN connection is made to encrypt data from the source host to the destination host.
Overview of Demand-Dial Routing in Windows Server 2003
The 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 ISDN), VPN connections, and PPP over Ethernet (PPPoE) connections. Demand-dial routing is 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.
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 through 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:
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).
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. The endpoint of the connection must be identified by a phone number for dial-up connections, and either a fully qualified host name or IP address for VPN connections.
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.
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.
Configuration of static routes. You should not use dynamic routing protocols over temporary demand-dial connections. 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. You can add static routes manually or by using auto-static updates.
Demand-dial Routing Updates
While demand-dial routing can save connection costs, typical routing protocols rely on a periodic advertising process to communicate routing information. For example, 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 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 may result in an undesirable phone bill. Therefore, you should not run routing protocols across temporary dial-up WAN lines.
If you do not use routing protocols to update the routing tables, then 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 OSPF.
When instructed, a demand-dial interface that is configured for auto-static updates sends a request across an active connection to request all of the routes of the router on the other side of the connection. In response to the request, all of 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.
Introduction to Site-to-Site VPN connections
A site-to-site VPN connection is a demand-dial connection that uses a VPN tunneling protocol such as PPTP or L2TP/IPSec to connect two portions of a private network. Each VPN router provides a routed connection to the network to which the 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 MS-CHAP v2 or EAP-TLS, the answering router also authenticates itself to the calling router.
Table 1 lists the site-to-site VPN-capable Microsoft operating systems.
Table 1 Site-to-Site VPN-Capable Microsoft Operating Systems
|VPN Tunneling Protocol||Microsoft Operating System|
Windows Server 2003, Windows 2000 Server, Windows NT version 4.0 with the Routing and Remote Access Service (RRAS)
Windows Server 2003, Windows 2000 Server
VPN routers can also be any computer that is capable of creating a routed PPTP connection using MPPE or a routed L2TP connection using IPSec encryption.
On-demand vs. Persistent Connections
A site-to-site VPN connection can be on-demand or persistent:
An on-demand site-to-site connection is a connection that is made when traffic must be forwarded across the connection. The connection is made, the traffic is forwarded, and the connection is terminated after a configured amount of idle time. 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 connected and 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, then 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. 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.
Restricting the Initiation of Demand-dial Connections
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. You can configure demand-dial filtering by right-clicking the demand-dial interface in the Network Interfaces node in the Routing and Remote Access snap-in, and then clicking Set IP 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 site-to-site VPN connection. You can configure dial-out hours by right-clicking the demand-dial interface in the Network Interfaces node in the Routing and Remote Access snap-in, and then clicking Dial-out Hours.
You can use remote access policies to configure the times when incoming demand-dial routing connections are allowed.
One-way vs. Two-way Initiated Connections
With one-way initiated connections, one VPN router is always the calling router and one VPN router is the 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. 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. This demand-dial interface is not used to dial out, therefore it does 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. 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 are connected to the Internet by using a permanent WAN link.
Both routers are configured as LAN and demand-dial routers.
User accounts are added for both routers so that the authentication credentials for 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, 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 2 lists a correct example 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.
Table 2 Correct example configuration for two-way initiated demand-dial routing
|Router||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 on the other router.