Step-by-Step Guide to Building a Site-to-Site Virtual Private Network Connection

From : Microsoft
Step-by-Step Guide to Building a Site-to-Site Virtual Private Network Connection
This step-by-step guide provides guidance for building a Routing and Remote Access Services (RRAS) infrastructure supporting Site-to-Site Virtual Private Network (VPN) through demand-dial connections.
On This Page

Introduction

Overview

Configuring the Routing and Remote Access Service

Configuring Demand-Dial Interfaces

Extending Site-to-Site Security Through Remote Access Policies

Configuring for IPSec Shared Key and Testing the Connection

Additional Resources
Introduction
Step-by-Step Guides
The Windows Server 2003 Deployment step-by-step guides provide hands-on experience for many common operating system configurations. The guides begin by establishing a common network infrastructure through the installation of Windows Server 2003, the configuration of Active Directory®, the installation of a Windows XP Professional workstation, and finally the addition of this workstation to a domain. Subsequent step-by-step guides assume that you have this common network infrastructure in place. If you do not want to follow this common network infrastructure, you will need to make appropriate modifications while using these guides.
The common network infrastructure requires the completion of the following guides.
•
Part I: Installing Windows Server 2003 as a Domain Controller
•
Part II: Installing a Windows XP Professional Workstation and Connecting It to a Domain
Once the common network infrastructure is configured, any of the additional step-by-step guides may be employed. Note that some step-by-step guides may have additional prerequisites above and beyond the common network infrastructure requirements. Any additional requirements will be noted in the specific step-by-step guide.
Microsoft Virtual PC
The Windows Server 2003 Deployment step-by-step guides may be implemented within a physical lab environment or through virtualization technologies like Microsoft Virtual PC 2004 or Microsoft Virtual Server 2005. Virtual machine technology enables customers to run multiple operating systems concurrently on a single physical server. Virtual PC 2004 and Virtual Server 2005 are designed to increase operational efficiency in software testing and development, legacy application migration, and server consolidation scenarios.
The Windows Server 2003 Deployment step-by-step guides assume that all configurations will occur within a physical lab environment, although most configurations can be applied to a virtual environment without modification.
Applying the concepts provided in these step-by-step guides to a virtual environment is beyond the scope of this document.
Important Notes
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, places, or events is intended or should be inferred.
This common infrastructure is designed for use on a private network. The fictitious company name and Domain Name System (DNS) name used in the common infrastructure are not registered for use on the Internet. You should not use this name on a public network or Internet.
The Active Directory service structure for this common infrastructure is designed to show how Windows Server 2003 Change and Configuration Management works and functions with Active Directory. It was not designed as a model for configuring Active Directory for any organization.
Top of page
Overview
Many organizations have offices located in different geographical locations, requiring remote-site connectivity. You can use the Windows Server 2003 Routing and Remote Access Service (RRAS) to deploy a cost-effective and secure site-to-site solution.
Traditionally, organizations have used wide area network (WAN) site-to-site connection technologies, such as T-Carrier or Frame Relay, to connect remote sites across a private data network. However, these private lines are expensive. For example, the cost of T-Carrier services are based on both bandwidth and distance, which makes the connections relatively expensive. In addition, T-Carrier typically requires a dedicated infrastructure, including a Channel Service Unit/Data Service Unit (CSU/DSU) and line-specific routers at each end of the connection.
In contrast, you can integrate the Windows Server 2003 RRAS solution into your organization’s current network by using existing servers. With the site-to-site connections provided by the RRAS, you have two alternatives to conventional WAN links: a site-to-site dial-up connection or a site-to-site VPN connection. If you deploy a RRAS solution to replace an existing WAN connection, or to implement a new connection, you can optimize cost savings by tailoring your connection type to your traffic volume. You can also customize security to fit your organization’s requirements.
In a site-to-site deployment, RRAS allows demand-dial routing (also known as dial-on-demand routing). By using a demand-dial interface, the router can initiate a connection to a remote site when the packet to be routed is received by the router. The connection becomes active only when data is sent to the remote site. When no data has been sent over the link for a specified amount of time, the link is disconnected.
RRAS also includes support for demand-dial filters and dial-out hours. You can use demand-dial filters to specify what types of traffic are allowed to create the connection. Demand-dial filters are separate from Internet Protocol (IP) packet filters, which you configure to specify what traffic is allowed into and out of an interface once the connection is made. You can set dial-out hours to specify the hours that a router is allowed to dial out to make demand-dial connections. You can configure when the router accepts incoming connections through remote access policies.
Note: RRAS supports both site-to-site connections between remote offices and remote access connections for individual computers. This step-by-step guide focuses on the deployment of a site-to-site VPN connection using Internet Protocol Security (IPSec) with a shared key.
Prerequisites
•
Part 1: Installing Windows Server 2003 as a Domain Controller
•
Step by Step Guide to Setting Up Additional Domain Controllers
•
Step-by-Step Guide to Managing Active Directory
Guide Requirements
•
For the configuration of a site-to-site VPN solution, both the calling and answering routers must be configured as multi-homed servers. Accordingly, each server should have a secondary network interface card (NIC) available for use. For the procedures in this guide, the following settings are used for the secondary NIC.
•
HQ-CON-DC-01 - IP Address: 20.0.0.1, IP MASK: 255.0.0.0, Default Gateway: Blank, DNS Server: 127.0.0.1
•
HQ-CON-DC-02 - IP Address: 20.0.0.2, IP MASK: 255.0.0.0, Default Gateway: Blank, DNS Server: 127.0.0.1
•
To correctly simulate a site-to-site demand-dial connection, all machines under the child domain, vancouver, should be moved to a separate network, or, have a third network interface available for use. In the sections that follow, each machine in the vancouver child domain has been configured with a third network interface. Each interface is configured with a 30.0.0.0 network address. If you decide to physically segment the Vancouver domain, you should install and configure DNS on HQ-CON-DC-02.
Warning: The steps detailed in this guide provide a general overview of the configurations necessary to create a demand-dial site-to-site VPN connection using an IPSec shared key. Accordingly, this guide should only be implemented within a test environment. For more information about the planning and deployment of Windows Server 2003 VPNs, see Virtual Private Networks for Windows Server 2003.
Top of page
Configuring the Routing and Remote Access Service
When you run the Routing and Remote Access Server Setup Wizard, the wizard prompts you to choose the configuration path that most closely resembles the remote access solution that you want to deploy. If none of the wizard configuration paths meets your needs exactly, you can further configure your server after the wizard finishes, or you can choose the custom configuration path.
Although the immediate goal is the configuration of a secure connection between two private networks, additional guides in this series expand on the core functionality of RRAS through the inclusion of dial-up. Accordingly, in the sections that follow, RRAS will initially be configured as a VPN server while the site-to-site VPN will be configured manually.
Note: With a basic installation of Windows Server 2003, the components for RRAS are actually installed by default but not enabled or configured.
To enable and configure Routing and Remote Access Service on HQ-CON-DC-01
1.
Click the Start button, point to All Programs, select Administrative Tools, and then click Routing and Remote Access.
2.
On the Routing and Remote Access console, right-click HQ-CON-DC-01, and then click Configure and Enable Routing and Remote Access.
3.
On the Routing and Remote Access Server Setup Wizard screen, click Next.
4.
Click the Remote access (dial-up or VPN) radio button (default), and then click Next.
5.
Select the VPN check box as shown in Figure 1, and then click Next.
Figure 1. Selecting a Remote Access Method
6.
Under Network Interfaces, click to highlight the adapter representing the Internet connection on which this site-to-site VPN will operate. Leave the default selection of Enable Security, and then click Next.
7.
On the IP Address Assignment screen, leave the default setting of Automatically, and then click Next to continue.
Note: When configuring an RRAS server, you need to determine whether the remote access server will use Dynamic Host Configuration Protocol (DHCP) or a static IP address pool to obtain addresses for dial-up clients. If you use a static IP address pool, determine whether the pool will be ranges of addresses that are a subset of addresses from the IP network to which the server is attached, or a separate subnet. If the static IP address pool address ranges represent a different subnet, ensure that routes to the address ranges exist in the routers of your intranet so that traffic to connected remote access clients is forwarded to the remote access server.
8.
On the Managing Multiple Remote Access Servers screen, leave the default setting of No, use RRAS to authenticate authentication request, and then click Next.
Note: If you have more than one remote access server, rather than administer the remote access policies of all the remote access servers separately, you can configure a single server with the Internet Authentication Service (IAS) as a Remote Authentication Dial-In User Service (RADIUS) server and configure the remote access servers as RADIUS clients. The IAS server provides centralized remote access authentication, authorization, accounting, and auditing.
9.
On the Completing the Routing and Remote Access Server Setup Wizard screen, click Finish to complete the configuration of RRAS.
10.
In the Routing and Remote Access dialog box, shown in Figure 2, click OK to acknowledge DHCP Relay requirements.
Note: By default, the DHCP services provided by RRAS automatically handle all DHCP Relay requirements. In a scenario that includes a different DHCP server, you must ensure that the server is configured to relay DHCP requests.
Figure 2. DHCP RelaySee full-sized image
To enable and configure Routing and Remote Access Service on HQ-CON-DC-02
1.
Click the Start button, point to All Programs, select Administrative Tools, and then click Routing and Remote Access.
2.
On the Routing and Remote Access console, right-click HQ-CON-DC-02, and then click Configure and Enable Routing and Remote Access.
3.
On the Routing and Remote Access Server Setup Wizard screen, click Next.
4.
Click the Custom Configuration radio button, and then click Next.
5.
Click the Demand-dial connections (used for branch office routing) radio button, and then click Next.
6.
On the Completing the Routing and Remote Access Server Setup Wizard screen, click Finish to complete the configuration of RRAS.
7.
In the Routing and Remote Access dialog box, click Yes to start the RRAS service.
Top of page
Configuring Demand-Dial Interfaces
Network interfaces enable any server running RRAS to communicate with other computers over private or public networks. Network interfaces have two aspects that relate to Routing and Remote Access: the physical hardware, such as a network adapter, and the network interface configuration.
In Routing and Remote Access, network interfaces fall into the following categories.
•
Private interface A private interface is a network adapter that is physically connected to a private network. Most private networks are configured with a private network IP address range, and the private interface is also configured with a private address. Because a private network is, in theory, composed of known users and computers, you generally have fewer security considerations for a private interface than for a public interface.
•
Public interface A public interface is a network adapter that is physically connected to a public network, such as the Internet. The public interface is configured with a public IP address. You can configure a public interface to perform network address translation (NAT). Because a public interface is theoretically accessible by anyone on the public network, security considerations are generally higher for a public interface than for a private interface.
•
Demand-dial interface Demand-dial interfaces connect specific routers on either public or private networks. A demand-dial interface can be either on-demand (activated only when needed) or persistent (always connected).
In addition to configuring each network interface as a public, private, or demand-dial interface, you can configure packet filters, addresses, and other options for network interfaces. Some options for public interfaces, such as Basic Firewall, are not available for private interfaces.
To configure a demand-dial interface on the Answering Server (HQ-CON-DC-01)
1.
On the Routing and Remote Access console, click the plus sign (+) next to HQ-CON-DC-01 to expand the tree.
2.
Under the HQ-CON-DC-01 tree, right-click Network Interfaces, and then click New Demand-dial Interface.
3.
On the Welcome to the Demand-Dial Interface Wizard, click Next to begin the configuration.
4.
For the Interface Name, type VPN_Vancouver, and then click Next.
5.
For the Connection Type, leave the default setting of Connect using virtual private networking, and then click Next.
6.
On the VPN Type screen, select Layer 2 Tunneling Protocol (L2TP) as shown in Figure 3, and then click Next.
Figure 3. Selecting the VPN Type
7.
On the Destination Address screen, type 20.0.0.2 for Host name or IP address, and then click Next.
8.
On the Protocols and Security screen, select both Route IP packets on this interface and Add a user account so a remote router can dial-in, and then click Next.
9.
On the Static Routes for Remote Networks screen, click Add. Type 30.0.0.0 for Destination and 255.0.0.0 for Network Mask, click OK, and then click Next.
Note: The previous step assumes that the vancouver domain has been reconfigured to reside on a 30.0.0.0 network.
10.
On the Dial-in Credentials screen, type pass#word1 for both Password and Confirm Password, and then click Next.
11.
On the Dial-Out Credentials screen, type VPN_HQ for the User name, type VANCOUVER for the Domain, and type pass#word1 for both Password and Confirm Password. When completed, configurations should appear as shown in Figure 4. Click Next to continue.
Figure 4. Setting Dial-Out Credentials on HQ-CON-DC-01
12.
On the Completing the Demand–Dial Interface Wizard, click Finish.
To configure a demand-dial interface on the Calling Server (HQ-CON-DC-02)
1.
On the Routing and Remote Access console, click the plus sign (+) next to HQ-CON-DC-02 to expand the tree.
2.
Under the HQ-CON-DC-02 tree, right-click Network Interfaces, and then click New Demand-dial Interface.
3.
On the Welcome to the Demand-Dial Interface Wizard, click Next to begin the configuration.
4.
For the Interface Name, type VPN_HQ, and then click Next.
5.
For the Connection Type, leave the default setting of Connect using virtual private networking, and then click Next.
6.
On the VPN Type screen, select Layer 2 Tunneling Protocol (L2TP) as shown in Figure 3, and then click Next.
7.
On the Destination Address screen, type 20.0.0.1 for Host name or IP address, and then click Next.
8.
On the Protocols and Security screen, select both Route IP packets on this interface and Add a user account so a remote router can dial-in, and then click Next.
9.
On the Static Routes for Remote Networks screen, click Add. Type 10.0.0.0 for Destination and 255.0.0.0 for Network Mask, click OK, and then click Next.
Note: The previous step assumes that the contoso root domain still resides on the 10.0.0.0 network.
10.
On the Dial-in Credentials screen, type pass#word1 for both Password and Confirm Password, and then click Next.
11.
On the Dial-Out Credentials screen, type VPN_Vancouver for the User name, type CONTOSO for the Domain, and type pass#word1 for both Password and Confirm password. When completed, configurations should appear as shown in Figure 5.
Figure 5. Setting the Dial-Out Credentials on HQ-CON-DC-02
12.
Click Next to continue.
13.
On the Completing the Demand–Dial Interface Wizard, click Finish.
Top of page
Extending Site-to-Site Security Through Remote Access Policies
For RRAS in Windows Server 2003, network access authorization is granted on the basis of user account dial-in properties and remote access policies.
Remote access policies are an ordered set of rules that define how connections are either authorized or rejected. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. If a connection is authorized, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.
There are two ways to use remote access policies to grant authorization.
•
By user If you are managing authorization by user, set the remote access permission on the user or computer account to either Grant access or Deny access and, optionally, create different remote access policies based on different types of connections. For example, you might want to have one remote access policy that is used for dial-up connections and a different remote access policy that is used for wireless connections. Managing authorization by user is recommended only when you have a small number of user or computer accounts to manage.
•
By group If you are managing authorization by group, set the remote access permission on the user account to Control access through Remote Access Policy and create remote access policies that are based on different types of connections and group membership. For example, you might want to have one remote access policy for dial-up connections for employees (members of the Employees group) and a different remote access policy for dial-up connections for contractors (members of the Contractors group).
Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If multiple conditions exist, all the conditions must match the settings of the connection attempt for it to match the policy. If all conditions of a remote access policy are met, remote access permission is either granted or denied. You can use either the Grant remote access permission option or the Deny remote access permission option to set remote access permission for a policy.
In the following sections, remote access policies will be configured to grant authorization by group.
To prepare remote access policies to grant authorization by group
1.
On server HQ-CON-DC-01, open the Active Directory Users and Computers console.
2.
On the Active Directory Users and Computers console, click the plus sign (+) next to contoso.com to expand the tree.
3.
Under the contoso.com tree, click the Users Organization Unit (OU). In the results pane, double-click VPN_Vancouver.
4.
On the VPN_Vancouver Properties sheet, click the Dial-in tab.
5.
In the Remote Access Permissions section, click Control access through Remote Access Policy as shown in Figure 6.
Figure 6. Forcing Remote Access Permissions Through RRAS Policies
6.
On the VPN_Vancouver Properties sheet, click OK.
7.
Under the contoso.com tree, click the Groups OU, right-click the Groups OU, select New, and then click Group.
8.
On the New Object – Group screen, type Branch Office VPN for Group name, and then click OK.
9.
In the results pane, double-click Branch Office VPN. On the Branch Office VPN Properties screen, click the Members tab. Click Add, type VPN_Vancouver, and then click OK twice.
10.
Close the Active Directory Users and Computers console.
To configure a remote access policy to grant authorization by group
1.
In the Routing and Remote Access console, click Remote Access Policies.
2.
In the results pane, double-click Connection to Microsoft Routing and Remote Access server.
3.
Under Policy Conditions, click Add. Double-click Windows-Groups, click Add, type Branch Office VPN, and then click OK twice.
4.
On the bottom of the Properties sheet, click Grant remote access permission, and then click OK.
Top of page
Configuring for IPSec Shared Key and Testing the Connection
By default, both the L2TP client and L2TP server for Windows Server 2003 are pre-configured for certificate-based IPSec authentication. When you make an L2TP over IPSec connection, an IPSec policy is automatically created to specify that the Internet Key Exchange (IKE) will use certificate-based authentication during the negotiation of security settings for L2TP. This means that both the L2TP client and L2TP server must have a computer certificate (also known as a machine certificate) installed before a successful L2TP over IPSec connection can be established. Both computer certificates must be from the same certificate authority (CA) or the root certificate of each computer's CA must be installed as a trusted root CA in each other's trusted root certificate store.
In some cases, a certificate-based IPSec authentication method is not desired for L2TP-based router-to-router VPN connections. In these cases, you can manually configure IPSec policy to use pre-shared keys when creating router-to-router VPN connections. This pre-shared authentication key acts like a simple password in the IKE negotiation. If both sides can prove they know the same password, then they trust each other and will continue to negotiate private, symmetric encryption keys, and specific security settings for L2TP traffic.
Using an IKE pre-shared key is generally considered not as secure as using certificates because the IKE authentication (and implicit trust) is dependent on the key value only, which is stored in plain-text format in the IPSec policy. Anyone who views the policy can see the pre-shared key value. If a malicious user views the pre-shared key, then they could configure their system to successfully establish IPSec security with your system. However, the L2TP connection requires user-level authentication using a Point-to-Point Protocol (PPP). Therefore, a malicious user would have to know both the pre-shared key and the proper user credentials to successfully establish the L2TP over IPSec connection.
To configure an IPSec shared key on the answering server (HQ-CON-DC-01)
1.
On the Routing and Remote Access console, right-click HQ-CON-DC-01 (local), and the click Properties.
2.
On the HQ-CON-DC-01 (local) Properties sheet, click the Security tab. Select Allow custom IPSec policy for L2TP connection, type 12345 for Pre-shared Key as shown in Figure 7, and then click OK.
Figure 7. Setting a Pre-Shared Key on the Answering Router
To configure an IPSec shared key on the calling server (HQ-CON-DC-02)
1.
On the Routing and Remote Access console, under the HQ-CON-DC-02 (local) tree, click Network Interfaces, and then double-click VPN_HQ.
2.
On the VPN_HQ Properties page, click the Security tab, and then click the IPSec Settings button.
3.
In the IPSec Settings dialog box, select Use pre-shared key for authentication, type 12345 for Key as shown in Figure 8, and then click OK twice.
Figure 8. Setting a Pre-Shared Key on the Calling Router
To test the Site-to-Site VPN connection
•
On the Routing and Remote Access console, right-click VPN_HQ, and then click Connect