Deploying a PPTP-based Site-to-Site VPN Connection

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The deployment of PPTP-based site-to-site VPN connections using Windows Server 2003 consists of the following:

  • Deploy certificate infrastructure

  • Deploy Internet infrastructure

  • Deploy the answering router

  • Deploy the calling router

  • Deploy AAA infrastructure

  • Deploy site network infrastructure

  • Deploy intersite network infrastructure

Deploying Certificate Infrastructure

For PPTP-based VPN connections, a certificate infrastructure is needed only when you are using EAP-TLS authentication. If you are only using a password-based authentication protocol such as MS-CHAP v2, a certificate infrastructure is not required and is not used for the authentication of the VPN connection.

To use EAP-TLS authentication for site-to-site VPN connections, you must:

  • Install a user certificate on each calling router computer.

  • Configure EAP-TLS on the calling router.

  • Install a computer certificate on the authenticating server (the answering router or the RADIUS server).

  • Configure EAP-TLS on the answering router and for the remote access policy for site-to-site connections.

Installing a User Certificate on a Calling Router

If you are using a Windows Server 2003 CA, a Router (Offline request) certificate is created and mapped to an Active Directory user account. To deploy a Router (Offline request) certificates for a calling router, the network administrator must:

  1. Configure the Windows Server 2003 CA to issue Router (Offline request) certificates.

  2. Request a Router (Offline request) certificate.

  3. Export the Router (Offline request) certificate.

  4. Map the certificate to the appropriate user account.

  5. Send the Router (Offline request) certificate to the network administrator of the calling router.

  6. Import the Router (Offline request) certificate on the calling router.

For more information about deploying Router (Offline request) certificates for demand-dial routing, see the topic titled Branch office demand-dial connection in Windows Server 2003 Help and Support.

For a third-party CA, see the documentation for the CA software for instructions about how to create a user certificate with the Client Authentication enhanced key usage (object identifier "1.3.6.1.5.5.7.3.2") and export it so that it can be mapped to an Active Directory user account and sent to the network administrator of the calling router. You must also export the root CA certificate, the certificate of the issuing CA, and the certificates of any intermediate CAs and import them to the proper folder of the computer certificate store of the answering router using the Certificate Manager snap-in. For more information, see Appendix E of the Microsoft white paper titled "Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs".

Configuring EAP-TLS on a Calling Router

To configure EAP-TLS for user certificates on the calling router:

  • The demand-dial interface must be configured to use EAP with the Smart Card or other certificate EAP type by configuring advanced settings on the Security tab on the properties of a demand-dial interface. For the properties of the Smart Card or other certificate EAP type, select Use a certificate on this computer. If you want to validate the computer certificate of the VPN or IAS server, select Validate server certificate. If you want to configure the names of the authenticating servers, select Connect to these servers and type the server names. To require the servers computer certificate to have been issued a certificate from a specific trusted root CA, select the CA in the list of Trusted Root Certification Authorities.

  • Right-click the demand-dial interface and click Set credentials. In the Connect dialog box, select the correct user or Router (Offline request) certificate in User name on certificate, and then click OK.

Installing a Computer Certificate on the Authenticating Server

To install a computer certificate, a certification authority must be present to issue certificates. If the CA is a Windows Server 2003 CA and the authenticating server is either the answering router or a Windows Server 2003 Internet Authentication Service (IAS) RADIUS server, you can install a certificate in the computer certificate store of the authenticating server in the following different ways:

  1. By configuring the automatic allocation of computer certificates to computers in an Active Directory domain.

    This method allows a single point of configuration for the entire domain. All members of the domain automatically receive a computer certificate through Group Policy.

  2. By using the Certificate Manager snap-in to request a certificate to store in the Certificates (Local Computer)\Personal folder.

    In this method, each computer must separately request a computer certificate from the CA. You must have administrator permissions to install a certificate using the Certificate Manager snap-in.

  3. By using Internet Explorer and web enrollment to request a certificate and store it in local machine store.

    In this method, each computer must separately request a computer certificate from the CA. You must have administrator permissions to install a certificate using Web enrollment.

Based on the certificate policies in your organization, you only need to perform one of these methods.

For more information about using the Windows Server 2003 CA to obtain computer certificates, see the topics titled "Computer certificates for L2TP/IPSec VPN connections" and "Submit an advanced certificate request via the Web" in Windows Server 2003 Help and Support.

For a third-party CA, see the documentation for the CA software for instructions about how to create a certificate with the Server Authentication enhanced key usage (object identifier "1.3.6.1.5.5.7.3.1") and export it so that it can be imported using the Certificate Manager snap-in by an administrator on the answering router. Additionally, the root CA certificate, the certificate of the issuing CA, and the certificates of any intermediate CAs must be exported and imported on the calling router. For additional information, see Appendix E of the Microsoft white paper titled "Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs".

Configuring EAP-TLS on the Answering Router and Remote Access Policy

To configure EAP-TLS authentication on the answering router:

  • EAP must be enabled as an authentication type on the Authentication Methods dialog box available from the Security tab in the properties of the answering router in the Routing and Remote Access snap-in.

To configure EAP-TLS authentication on the remote access policy for either the answering router or IAS server:

  • On the remote access policy that is being used for site-to-site VPN connections, the Smart Card or other certificate EAP type must be added to the selected EAP methods from the Authentication tab on the policy's profile settings. If the computer on which the remote access policy is being configured has multiple computer certificates installed, configure the properties of the Smart Card or other certificate EAP type and select the correct computer certificate to submit during the EAP-TLS authentication process.

If you are using a third-party RADIUS server, see the RADIUS server documentation for information about how to enable EAP-TLS and configure EAP-TLS to use the correct computer certificate.

Deploying Internet Infrastructure

Deploying the Internet infrastructure for site-to-site VPN connections consists of the following:

  • Place VPN routers in the perimeter network or on the Internet.

  • Install Windows Server 2003 on VPN router computers and configure Internet interfaces.

Placing VPN Routers on the Perimeter Network or on the Internet

Decide where to place the VPN routers in relation to your Internet firewall. In the most common configuration, the VPN routers are placed behind the firewall on the perimeter network between your site and the Internet. If so, configure packet filters on the firewall to allow PPTP traffic to and from the IP address of the VPN routers' perimeter network interfaces. For more information, see Appendix A.

Installing Windows Server 2003 on VPN Routers and Configuring Internet Interfaces

Install Windows Server 2003 on VPN router computers and connect it to either the Internet or to perimeter network with one network adapter and connect it to the site with another network adapter. Without running the Routing and Remote Access Server Setup Wizard, the VPN router computer will not forward IP packets between the Internet and the site. For the connection connected to the Internet or the perimeter network, configure the TCP/IP protocol with a public IP address, a subnet mask, and the default gateway of either the firewall (if the router is connected to a perimeter network) or an ISP router (if the router is directly connected to the Internet). Do not configure the connection with DNS server or WINS server IP addresses.

Deploying the Answering Router

Deploying the answering router for a site-to-site VPN connection consists of the following:

  • Configure the answering router's connection to the site.

  • Run the Routing and Remote Access Server Setup Wizard.

  • Configure a demand-dial interface.

Configuring the Answering Router's Connection to the Site

Configure the connection connected to the site with a manual TCP/IP configuration consisting of IP address, subnet mask, site DNS servers, and site WINS servers. Note that you must not configure the default gateway on the site connection to prevent default route conflicts with the default route pointing to the Internet.

Running the Routing and Remote Access Server Setup Wizard

Run the Routing and Remote Access Server Setup Wizard to configure the Windows Server 2003 answering router using the following steps:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Routing and Remote Access.

  2. Right-click the answering name, and then click Configure and Enable Routing and Remote Access. Click Next.

  3. In Configuration, click Remote access (dial-up or VPN) and then click Next. If you additionally want to use the answering router as a network address translator (NAT), Web server, or other function, see Appendix B.

  4. In Remote Access, select VPN. If you also want the answering router to support dial-up site-to-site connections, click Dial-up. Click Next.

  5. In VPN Connection, click the connection that corresponds to the interface connected to the Internet or your perimeter network, and then click Next.

  6. In IP Address Assignment, click Automatically if the answering router should use DHCP to obtain IP addresses for remote access VPN clients and calling routers. Or, click From a specified range of addresses to use one or more static ranges of addresses. If any of the static address ranges is an off-subnet address range, routes must be added to the routing infrastructure in order for the virtual interfaces of calling routers to be reachable. When IP address assignment is complete, click Next.

  7. In Managing Multiple Remote Access Servers, if you are using RADIUS for authentication and authorization, click Yes, set up this server to work with a RADIUS server, and then click Next.

    • In RADIUS Server Selection, configure the primary (mandatory) and alternate (optional) RADIUS servers and the shared secret, and then click Next.
  8. Click Finish.

By default, only 128 PPTP ports are configured on the WAN Miniport (PPTP) device. If you need more PPTP ports, configure the WAN Miniport (PPTP) device from the properties of the Ports object in the Routing and Remote Access snap-in. By default, 128 L2TP ports are also configured.

By default, the MS-CHAP, MS-CHAP v2, and EAP authentication methods are enabled.

Configuring a Demand-dial Interface

From the Routing and Remote Access snap-in on the answering router, perform the following steps:

  1. In the console tree, right-click Network Interfaces, and then click New Demand-dial Interface.

  2. On the Welcome to the Demand-Dial Interface Wizard page, click Next.

  3. On the Interface Name page, type the name of the demand-dial interface, and then click Next.

  4. On the Connection Type page, click Connect using virtual private networking (VPN), and then click Next.

  5. On the VPN Type page, click Point to Point Tunneling Protocol (PPTP), and then click Next.

  6. On the Destination Address page, type the IP address of the calling router.

    For a two-way-initiated router to-router VPN connection, configure the IP address of the calling router. For a one-way initiated site-to-site VPN connection, you can skip this step because the answering router never uses this interface to initiate a connection to the calling router.

  7. On the Protocols and Security page, select the Route IP packets on this interface and Add a user account so that a remote router can dial in check boxes, and then click Next.

  8. On the Static Routes for Remote Networks page, click Add to add static routes assigned to the demand-dial interface (as needed).

  9. On the Dial In Credentials page, type the password of the user account used by the calling router in Password and Confirm password, and then click Next. This step automatically creates a user account with the same name as the demand-dial interface that is being created. This is done so that when the calling router initiates a connection to the answering router, it is using a user account name that matches the name of a demand-dial interface. Therefore, the answering router can determine that the incoming connection from the calling router is a demand-dial connection rather than a remote access connection.

  10. On the Dial Out Credentials page, type the user name in User name, the user account domain name in Domain, and the user account password in both Password and Confirm password.

    For a two-way-initiated router to-router VPN connection, configure the name, domain, and password when this router is acting as the calling router. For a one-way initiated site-to-site VPN connection, you can type any name in User name and skip the rest of the fields because this router never uses this interface to initiate a connection to the calling router.

  11. On the Completing the Demand-Dial Interface Wizard page, click Finish.

The result of this configuration is a PPTP-based demand-dial interface over which IP routing is enabled. A user account with the same name as the demand-dial interface is automatically added with correct account and dial-in settings.

Deploying the Calling Router

Deploying the calling router for a site-to-site VPN connection consists of the following:

  • Configure the calling router's connection to the site.

  • Run the Routing and Remote Access Server Setup Wizard.

  • Configure a demand-dial interface.

Configuring the Calling Router's Connection to the Site

Configure the connection connected to the site with a manual TCP/IP configuration consisting of IP address, subnet mask, site DNS servers, and site WINS servers. Note that you must not configure the default gateway on the site connection to prevent default route conflicts with the default route pointing to the Internet.

Running the Routing and Remote Access Server Setup Wizard

Run the Routing and Remote Access Server Setup Wizard to configure the Windows Server 2003 calling router using the following steps:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Routing and Remote Access.

  2. Right-click your server name, and then click Configure and Enable Routing and Remote Access. Click Next.

  3. In Configuration, click Remote access (dial-up or VPN) and then click Next. If you additionally want to use the calling router as a network address translator (NAT), Web server, or other function, see Appendix B.

  4. In Remote Access, select VPN. If you also want the VPN router to support dial-up site-to-site connections, click Dial-up. Click Next.

  5. In VPN Connection, click the connection that corresponds to the interface connected to the Internet or your perimeter network, and then click Next.

  6. In IP Address Assignment, click Automatic if the calling router should use DHCP to obtain IP addresses for other calling routers when it is acting as an answering router. Or, click From a specified range of addresses to use one or more static ranges of addresses. If any of the static address ranges is an off-subnet address range, routes must be added to the routing infrastructure in order for the virtual interfaces of routers calling this router to be reachable. When IP address assignment is complete, click Next.

  7. In Managing Multiple Remote Access Servers, if you are using RADIUS for authentication and authorization, click Yes, set up this server to work with a RADIUS server, and then click Next.

    • In RADIUS Server Selection, configure the primary (mandatory) and alternate (optional) RADIUS servers and the shared secret, and then click Next.
  8. Click Finish.

Configuring a Demand-dial Interface

From the Routing and Remote Access snap-in on the calling router, perform the following steps:

  1. In the console tree, right-click Network Interfaces, and then click New Demand-dial Interface.

  2. On the Welcome to the Demand-Dial Interface Wizard page, click Next.

  3. On the Interface Name page, type the name of the demand-dial interface. For a two-way initiated connection, this is the same name as the user name in the user credentials used by the answering router when it is acting as a calling router. Click Next.

  4. On the Connection Type page, click Connect using virtual private networking (VPN), and then click Next.

  5. On the VPN Type page, click Point to Point Tunneling Protocol (PPTP), and then click Next.

  6. On the Destination Address page, type the IP address of the answering router.

  7. On the Protocols and Security page, select the Route IP packets on this interface check box. For a two-way initiated connection, select the Add a user account so that a remote router can dial in check box. Click Next.

  8. On the Static Routes for Remote Networks page, click Add to add static routes assigned to the demand-dial interface (as needed).

  9. For a two-way initiated connection, in the Dial In Credentials page, type the password of the user account used by the answering router acting as a calling router in Password and Confirm password, and then click Next. This step automatically creates a user account with the same name as the demand-dial interface that is being created. This is done so that when the answering router acting as a calling router initiates a connection to this router, it is using a user account name that matches the name of a demand-dial interface. Therefore, this router can determine that the incoming connection from the answering router acting as a calling router is a demand-dial connection rather than a remote access connection.

  10. On the Dial Out Credentials page, type the user name in User name, the user account domain name in Domain, and the user account password in both Password and Confirm password.

  11. On the Completing the demand-dial interface wizard page, click Finish.

The result of this configuration is a PPTP-based demand-dial interface over which IP routing is enabled. A user account with the same name as the demand-dial interface is automatically added with correct account and dial-in settings (if needed).

Deploying AAA Infrastructure

Deploying the AAA infrastructure for site-to-site VPN connections consists of the following:

  • Configure Active Directory for user accounts and groups.

  • Configure the primary IAS server on a domain controller.

  • Configure the secondary IAS server on a different domain controller.

This configuration must be done at each site containing an answering router. For branch offices with few computers and a single answering router, it is easier to configure the Routing and Remote Access service for Windows authentication and use locally configured remote access policies than configuring a separate IAS server computer.

Configuring Active Directory for User Accounts and Groups

To configure Active Directory for user accounts and groups, do the following:

  1. Ensure that all calling routers have a corresponding user account with the correct account and dial-in settings. This includes calling routers for branch offices and business partners. User accounts with the correct account and dial-in settings are automatically created when you select the Add a user account so that a remote router can dial in check box on the Protocols and Security page of the Demand-Dial Interface Wizard.

  2. Organize user accounts used by calling routers into the appropriate universal and nested groups to take advantage of group-based remote access policies. For more information, see the topic titled "Nesting groups" in Windows Server 2003 Help and Support.

Configuring the Primary IAS Server on a Domain Controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see the topic titled "Install IAS" in Windows Server 2003 Help and Support.

  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see the topic titled "Enable the IAS server to read user objects in Active Directory" in Windows Server 2003 Help and Support.

    If the IAS server authenticates connection attempts for user accounts in other domains, verify that these domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see the topic titled "Enable the IAS server to read user objects in Active Directory" in Windows Server 2003 Help and Support. For more information about trust relationships, see the topic titled "Understanding Domains and Forests" in Windows Server 2003 Help and Support.

  3. If the IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, you must configure a RADIUS proxy between the two untrusted domains.

  4. Enable file logging for accounting and authentication events. For more information, see the topic titled "Configure log file properties" in Windows Server 2003 Help and Support.

  5. Add the VPN router(s) as RADIUS clients of the IAS server. For more information, see the topic titled "Add RADIUS clients" in Windows Server 2003 Help and Support. For the IP address of each VPN router, use the site IP address assigned to the VPN router. If you are using names, use the internal name of the VPN router. Use strong shared secrets.

  6. Create remote access policies that reflect your remote access usage scenarios.

    For example, to configure a remote access policy that requires PPTP-based site-to-site VPN connections for members of the VPNRouters group to use MS-CHAP v2 authentication and 128-bit encryption, use the New Remote Access Policy Wizard to create a typical remote access policy with the following settings:

    Policy name: Site-to-Site VPN connections (example)

    Access method: VPN

    Group access: VPNRouters group (example)

    Authentication methods: Enable only Microsoft Encrypted Authentication version 2 (MS-CHAP v2)

    Policy encryption level: Select only Strongest encryption

If IAS is not installed on a domain controller, you must configure the primary IAS server computer to read the properties of user accounts in the domain. For more information, see the "Enable the IAS server to read user accounts in Active Directory" in Windows Server 2003 Help and Support.

Configuring the Secondary IAS Server on a Different Domain Controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see the topic titled "Install IAS" in Windows Server 2003 Help and Support.

  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see the topic titled "Enable the IAS server to read user objects in Active Directory" in Windows Server 2003 Help and Support.

  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see the topic titled "Enable the IAS server to read user objects in Active Directory" in Windows Server 2003 Help and Support. For more information about trust relationships, see the topic titled "Understanding Domains and Forests" in Windows Server 2003 Help and Support.

    If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, you must configure a RADIUS proxy between the two untrusted domains.

  4. To copy the configuration of the primary IAS server to the secondary IAS server, type netsh aaaa show config >path\file.txt at a command prompt on the primary IAS server. This stores the configuration settings, including registry settings, in a text file. The path can be relative, absolute, or a network path.

  5. Copy the file created in step 4 to the secondary IAS server. At a command prompt on the secondary IAS server, type netsh execpath\file.txt. This imports all the settings configured on the primary IAS server to the secondary IAS server.

If IAS is not installed on a domain controller, you must configure the secondary IAS server computer to read the properties of user accounts in the domain. For more information, see the "Enable the IAS server to read user accounts in Active Directory" in Windows Server 2003 Help and Support.

Deploying Site Network Infrastructure

Deploying the network infrastructure of a site for site-to-site VPN connections consists of the following:

  • Configure routing on the VPN routers.

  • Verify reachability from each VPN router.

  • Configure routing for off-subnet address pools.

Configuring Routing on the VPN Routers

In order for your VPN routers to properly forward traffic to locations within the site in which they are located, you must configure them with either static routes that summarize all the possible addresses used on in the site or with routing protocols so that the VPN router can participate as a dynamic router and automatically add routes for site subnets to its routing table.

To add static routes, see the topic titled "Add a static route" in Windows Server 2003 Help and Support. To configure the VPN router as a RIP router, see the topic titled "Configure RIP for IP". To configure the VPN router as an OSPF router, see the topics titled "OSPF design considerations" and "Configure OSPF" in Windows Server 2003 Help and Support.

Verifying Reachability from each VPN Router

From each VPN router, verify that the VPN router computer can resolve names and successfully communicate with resources in the VPN router's site by using the Ping command, Internet Explorer, and making drive and printer connections to known servers within the site.

Configuring Routing for Off-subnet Address Pools

If you configured any of the VPN routers with a static address pool and any of the ranges within the pool are an off-subnet range, you must ensure that the route(s) representing the off-subnet address range(s) are present in your site routing infrastructure to reach the virtual interfaces of calling routers. You can ensure this by adding static route(s) representing the off-subnet address range(s) as static routes to the neighboring router(s) of the VPN router(s) and then using the routing protocol of your site to propagate the route to other routers. When you add the static route(s), you must specify that the gateway or next hop address is the site interface of the VPN router.

Alternately, if you are using RIP or OSPF, you can configure the VPN routers using off-subnet address pools as RIP or OSPF routers. For OSPF, you must configure the VPN router as an autonomous system boundary router (ASBR). For more information, see the topic titled "OSPF design considerations" in Windows Server 2003 Help and Support.

Deploying Intersite Network Infrastructure

Deploying the intersite network infrastructure consists of configuring each VPN router with the set of routes for subnets that are available in the other sites (across each site-to-site VPN connection). This can be done in the following ways:

  • Manually configure static routes on each VPN router.

  • Perform auto-static updates on each VPN router.

  • Configure routing protocols to operate over the site-to-site VPN connection.

Manually Configuring Static Routes on Each VPN Router

From the Routing and Remote Access snap-in, perform the following steps:

  1. In the console tree, click IP Routing, and then click Static Routes.

  2. Right-click Static Routes, and then click New Static Route.

  3. In the Static Route dialog box, select the appropriate demand-dial interface name, and type the destination, network mask, and metric.

  4. Click OK to add the route.

  5. For an additional route, go back to step 2.

Note

Because the demand-dial connection is a point-to-point connection, the Gateway IP address field is not configurable. The adding of static routes can also be done during the creation of the demand-dial interface with the New Demand-Dial Interface Wizard.

Performing Auto-static Updates on Each VPN Router

If RIP for IP is enabled on the demand-dial interfaces of both VPN routers, you can use auto-static updates to automatically configure static routes when the VPN connection is in a connected state. 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.

From the Routing and Remote Access snap-in on a VPN router (assuming the site-to-site VPN connection is active), perform the following steps:

  1. In the console tree, click IP Routing, and then click General.

  2. In the details pane, right-click the appropriate demand-dial interface, and then click Update Routes.

You can also use the netsh interface set interface command to perform an auto-static update. For more information, see the topic titled "Scheduling auto-static updates" in Windows Server 2003 Help and Support.

Configuring Routing Protocols

If the site-to-site VPN connection is persistent (always active), you can also configure IP routing protocols such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF) to operate over the VPN connection. For more information, see the topics titled "Setting up a RIP-for-IP routed internetwork" and "Setting up an OSPF routed internetwork" in Windows Server 2003 Help and Support.