Chapter 9: Deploying Site-to-Site VPNs | Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)

In Chapter 8, “Site-to-Site VPN Components and Design Points,” we described the essential elements and considerations for site-to-site virtual private networks (VPNs) using Microsoft Windows Server 2003. The components of site-to-site VPNs have several differences from the remote access components in functional operations, but the deployment has many similarities. If you have read through the chapters on remote access, you’ll see many similarities between the deployment of site-to-site and remote access, but don’t take any steps for granted. Pay close attention to the procedures in this chapter to catch all the subtle differences.

In this chapter, we step through the deployment of Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol with Internet Protocol Security (L2TP/IPSec) site-to-site VPN solutions. Where there are identical methods for deploying both options, we will point them out and refer to the proper sections.

Deploying a Site-to-Site VPN Connection

In the remote access solutions section of the book, we described how to get remote access clients to connect to a VPN server. That process required the configuring of clients and and associated server settings such as Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Internet Protocol (IP) filters to maintain the operations and security. Much of the overhead involved with that process goes away in the site-to-site scenario, where the configuration stays static and is preconfigured for all connections. This is possible because all endpoints are already known at the time of deployment. Therefore, address configuration, multiple client authentication, and client dial-in scenarios are not issues, as they are with remote access solutions. The deployment of PPTP-based or L2TP/IPSec-based site- to-site VPN connections using Windows Server 2003 consists of the following steps, which we’ll explain in detail for you (L2TP/IPSec vs. PPTP procedures are specified):

Deploy the certificate infrastructure. Allows you to deploy certificates for both sides of the link
Deploy the Internet infrastructure. Allows you to connect to the Internet from both sides of the link
Deploy the answering router. Deploys the VPN server that will be accepting VPN connection requests
Deploy the calling router. Deploys the VPN server that will be initiating that request
Deploy the authentication, authorization, and accounting (AAA) infrastructure. Allows you to authenticate, authorize, and log connections for both sides of the link
Deploy the site network infrastructure. Allows you to forward packets to the attached site
Deploy the intersite network infrastructure. Allows you to forward packets to the site across the site-to-site VPN connection

Deploying the Certificate Infrastructure

You should use certificates for authentication whenever possible. For L2TP/IPSec connections, certificates are a requirement. For PPTP-based VPN connections, a certificate infrastructure is needed only when you are using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication. If you are using only a password-based authentication protocol such as Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2), a certificate infrastructure is not required and is not used for the authentication of the VPN connection.

The use of EAP-TLS might seem like a lot of overhead if you are looking for an easy VPN setup solution with PPTP. Most administrators use PPTP to avoid the issues of certification requirements, or more likely to cross network address translators (NATs) with a non-IPSec VPN protocol. Nevertheless, in site-to-site scenarios, use a certificate-based authentication method to attain the best security. Without certificates, you are susceptible to anyone who can discern the username/password combination. This kind of unauthorized intrusion is much more difficult when you use certificates, thus making the solution much more secure. Also, remember that with site-to-site connections, the username/password combination normally stays static, which increases the system’s vulnerability over time, unlike user-based remote access solutions, which are typically set up to require periodic password changes. To use EAP-TLS authentication for site-to-site VPN connections, you must perform the following steps:

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 Remote Authentication Dial-In User Service [RADIUS] server).
Configure EAP-TLS on the authenticating server and for the remote access policy for site-to-site connections.

Installing a User Certificate on a Calling Router

You use different certificate templates for various purposes on your network. If you are looking at a certification authority (CA) for the first time, the number and types of certificate templates can be overwhelming. We’re not going to examine the different templates in detail (a topic that is beyond the scope of this book), so if you are using a Windows Server 2003 CA, you will want to use a “Router (Offline request)” certificate template. The certificate created with this template is mapped to an Active Directory directory service user account.

To deploy a Router (Offline request) certificate for a calling router, you must do the following:

Create a user account for the answering router. This is normally done automatically by the Demand-Dial Interface Wizard.
Configure the Windows Server 2003 CA to issue Router (Offline request) certificates.
Request a Router (Offline request) certificate.
Export the Router (Offline request) certificate to a .cer file.
Map the .cer certificate file to the appropriate user account.
Export the Router (Offline request) certificate to a .pfx file.
Send the Router (Offline request) .pfx certificate file to the network administrator of the calling router.
Import the Router (Offline request) .pfx certificate file on the calling router.

These tasks are described in detail in the following sections.

Configuring the Windows Server 2003 CA to issue Router (Offline request) certificates

To install a computer certificate, an issuing CA must be present to issue certificates. See Appendix C, “Deploying a Certificate Infrastructure,” for information on how to set this up. Once this is done, you must get the router certificates issued for your deployment.

To get the router certificates issued for your deployment

Open the Certification Authority snap-in.
In the console tree, open the CA name.
Right-click Certificate Templates, point to New, and then click Certificate Template To Issue.
In Enable Certificate Templates, click Router (Offline Request). This is shown in the following figure.
Click OK.

Requesting a Router (Offline request) certificate

The first step after activating the certificate template is to request a certificate you can map to an Active Directory user account. We need to obtain the certificate, and then we’ll export that certificate to a .cer file that can be mapped to Active Directory.

To obtain the original certificate from Web enrollment

Run Microsoft Internet Explorer.
In Internet Explorer, in the Address text box, type the address of the CA that issues computer certificates. The address is the name of the server followed by /certsrv (for example, http://ca1/certsrv).
On the Welcome page, click Request A Certificate, click Advanced Certificate Request, and then click Create And Submit A Request To This CA.
In Certificate Template, select Router (Offline Request) or the name of the template that the CA administrator directed you to choose.
In the Name text box, type the user account name that is used by the calling router.
Under Key Options, select the Mark Keys As Exportable and Store Certificate In The Local Computer Certificate Store check boxes.
Confirm the other options you want, and then click Submit.
A message appears that asks you to confirm that you trust this Web site and that you want to request a certificate. Click Yes.
On the Certificate Issued page, click Install This Certificate.
A message informs you that a new certificate has been successfully installed.

Exporting the Router (Offline request) Certificate to a .cer File

Now we need to take the certificate we just obtained and export it for use in Active Directory. This requires going through a conversion process in the Microsoft Management Console (MMC) Certificate snap-in.

To convert your certificates to the .cer exported format

Open an MMC console containing Certificates (Local Computer).
In the tree pane, open Personal, and then open Certificates.
In the details pane, right-click the Router (Offline request) certificate obtained through Web enrollment, point to All Tasks, and then click Export.
In the Certificate Export Wizard, click No, Do Not Export The Private Key. Click Next.
Select DER Encoded Binary X.509 (.cer) as the export file format. This is shown in the following figure.
Click Next. Type the name for the certificate file, and click Next.
Click Finish.

Mapping the .cer Certificate File

Now that we have the .cer certificate file, we need to map the file to a user account in Active Directory.

To map the certificate to the appropriate account

Open the Active Directory Users And Computers snap-in.
On the View menu, click Advanced Features.
In the console tree, open the appropriate domain system container and folder that contains the user account for the calling router.
In the details pane, right-click the user account to which you want to map a certificate, and then click Name Mappings. This is shown in the following figure.
On the X.509 Certificates tab, click Add.
In the Add Certificate dialog box, select the .cer certificate file, click Open, and then click OK.

Exporting the Router (Offline Request) Certificate to a .pfx File

Now we need to have the matching certificate file exported with its corresponding private key to a file and sent to the calling router on the other side of the link. To accomplish this, we need to use the MMC snap-in again, and export the certificate to make a .pfx file.

To make a .pfx file out of your certificate and to export it

Open an MMC console containing Certificates (Local Computer).
In the tree pane, open Personal, and then open Certificates.
In the details pane, right-click the Router (Offline Request) certificate obtained through Web enrollment, point to All Tasks, and then click Export.
In the Certificate Export Wizard, click Yes, Export The Private Key. Click Next.
On the Export File Format page, select Personal Information Exchange – PKCS #12 (.pfx) as the export file format. Select Include All Certificates In the Certification Path If Possible option. This is shown in the following figure.
Click Next. On the Password page, in the Password and Confirm Password text boxes, type a password that encrypts the private key of the certificate. This same password will be required to import the certificate on the calling router. Click Next.
On the File To Export page, type the name of the certificate file. Click Next.
On the Completing The Certificate Export Wizard page, click Finish.

To import the Router (Offline request) .pfx certificate file on the calling router

Open an MMC console containing Certificates - Current User.
In the tree pane, right-click the Personal folder, point to All Tasks, and then click Import.
Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.) Click Next.
Type the password used to encrypt the private key, and then click Next.
Do one of the following:
- If the certificate should be automatically placed in a certificate store based on the type of certificate, select Automatically Select The Certificate Store Based On The Type Of Certificate. This is the best option if you are not sure. You should let Windows handle the certificate operations wherever possible. Certificate Services works under full Internet
- Engineering Task Force (IETF)–ratified specifications, so any other system requesting certificate information will be able to work with your server.
- If you want to specify where the certificate is stored, select Place All Certificates In The Following Store, click Browse, and select the certificate store to use.
Click Next, and then Click Finish.

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 [OID] “1.3.6.1.5.5.7.3.2”). After creating it, export it and its certification path so that it can be mapped to an Active Directory user account and sent to the network administrator of the calling router. For more information, see Appendix C.

Configuring EAP-TLS on a Calling Router

Both sides of the link need to be configured to use EAP-TLS or they will not be able to negotiate the authentication process properly.

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 authenticating 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 server’s 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

Previously, we described how to get the user certificates in place installed on the calling router and associated with the Active Directory user account for the site-to- site VPN connection. Now we need to install a server certificate on the authenticating server as well. To install a computer certificate, a CA 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 ways:

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. This auto-enrollment feature is available with Windows Server 2003, Windows 2000, and Microsoft Windows XP only.
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. This is the problem in managed environments and not scalable in a large enterprise designed for massive rollout, but it is useful for smaller deployments and helpdesk operations.
By using Internet Explorer and Web enrollment to request a certificate and store it in the local computer 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. This is the option that works best for mixed operating system environments.

Based on the certificate policies in your organization, you need to perform only one of these methods. However, depending on the operating system deployment of your organization and whether or not Windows XP is the primary desktop in your enterprise, a combination of these choices works best. Have auto-enrollment for Windows XP and Windows Server 2003 active through Active Directory, and for all other operating systems offer Web enrollment options. Make sure to properly authorize access to the Web enrollment site and use Secure Sockets Layer (SSL) encryption to keep the conversation private—even to keep it internal to your network. You don’t want a malicious user on your intranet obtaining someone else’s certificates and identity.

Configuring EAP-TLS on the Answering Router

Previously, we configured the calling router to use EAP-TLS in its negotiations. Now we have to configure the answering server with the matching option as well. 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.
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 on how to enable EAP-TLS and configure EAP-TLS to use the correct computer certificate.

Deploying the Internet Infrastructure

The whole idea of site-to-site VPN connections is to use the Internet as the intermediate network for your wide area network (WAN) communications, thus eliminating the need for expensive private leased-line circuits. The Internet infrastructure is the portion of the network that is directly attached to the public network that the VPN will be deployed over. In this section, we will examine all the steps for deploying the VPN routers on the Internet. Deploying the Internet infrastructure for site-to-site VPN connections consists of the following steps:

Place VPN routers in the perimeter network or on the Internet.
Install Windows Server 2003 on VPN router computers, and configure Internet interfaces.

Deploying Your VPN Routers

The first step in deploying your VPN routers is determining where to place them 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 you are using Microsoft Internet Security And Acceleration (ISA) Server as your firewall, Microsoft VPN services are part of the ISA product and you should be aware of the subtle differences from the standard Windows Server 2003 setup. Refer to the specific ISA server documentation to learn about the differences. One feature of ISA Server is that it automatically sets up the proper firewall filters for VPN traffic in the firewall rules. If you are using a non-ISA firewall, you will need to configure packet filters on the firewall to allow for either L2TP/IPSec or PPTP traffic (as appropriate) to and from the IP address of the VPN routers’ perimeter network interfaces. For more information, see Appendix B, “Configuring Firewalls for VPN.”

Installing Windows Server 2003 on VPN Routers, and Configuring Internet Interfaces

The critical component of the site-to-site VPN server connection is the VPN server that acts as a router between the Internet-connected traffic and the intranet traffic of the organization (the VPN router). In this section, we will:

Go through the process of setting up VPN servers with multiple interfaces.
Install Windows Server 2003 on VPN router computers.
Connect each to either the Internet or to a perimeter network with one network adapter, and then connect each to the site with another network adapter.

Later you will run the Routing And Remote Access Server Setup Wizard to enable multi-interface routing. 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.

On both servers, answering and calling, we need to set up Internet connectivity. For the network adapter connected to the Internet or the perimeter network, configure the Transmission Control Protocol/Internet Protocol (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 Internet service provider (ISP) router (if the router is directly connected to the Internet). Do not configure the connection with DNS server or Windows Internet Name Service (WINS) server IP addresses.

Deploying the Answering Router

Now that we have set up the computer running Windows Server 2003 and configured TCP/IP on the Internet interface, we need to set up the answering router with the proper configurations for a site-to-site VPN connection. The procedure 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

On the answering router’s second interface, configure the network adapter connected to the site with a manual TCP/IP configuration consisting of an IP address, a subnet mask, site DNS servers, and site WINS servers. Note that you must not configure the default gateway on the interfaces connected to the site. If you configure a default route on the site interfaces, it will create a conflicting default route entry in the routing table and routing to the Internet might not function properly.

To run the Routing And Remote Access Server Setup Wizard to configure the Windows Server 2003 answering router

Click Start, point to Administrative Tools, and then click Routing And Remote Access.
Right-click the answering router name, and then click Configure And Enable Routing And Remote Access. Click Next.
In Configuration, click Remote Access (Dial-up Or VPN) and then click Next.
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.
In VPN Connection, click the connection that corresponds to the interface connected to the Internet or your perimeter network, and then click Next.
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 for the virtual interfaces of calling routers to be reachable. When IP address assignment is complete, click Next.
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.
Click Finish.

If you are deploying PPTP as the tunneling protocol, 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.

If you are deploying L2TP/IPSec as the tunneling protocol, by default only 128 L2TP ports are configured on the WAN Miniport (L2TP) device. If you need more L2TP ports, configure the WAN Miniport (L2TP) device from the properties of the Ports object in the Routing And Remote Access snap-in. By default, 128 PPTP ports are also configured.

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

Configuring a Demand-Dial Interface

Now that we have the basics of the routing services and TCP/IP settings set on the server, we need to configure the actual demand-dial interface that will control activation of the site-to-site VPN connection.

To configure the demand-dial interface

Open the Routing And Remote Access snap-in on the answering router.
In the console tree, right-click Network Interfaces and then click New Demand-Dial Interface.
On the Welcome To The Demand-Dial Interface Wizard page, click Next.
On the Interface Name page, type the name of the demand-dial interface and then click Next.
On the Connection Type page, click Connect Using Virtual Private Networking (VPN) and then click Next.
If you are deploying PPTP as the tunneling protocol, on the VPN Type page, click Point To Point Tunneling Protocol (PPTP) and then click Next. If you are deploying L2TP/IPSec as the tunneling protocol, click Layer 2 Tunneling Protocol (L2TP) and then click Next.
On the Destination Address page, type the IP address of the calling router, and then click Next.

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.
On the Protocols And Security page, select the Route IP Packets On This Interface and Add A User Account So A Remote Router Can Dial In check boxes. This is shown in the following figure.
Click Next. On the Static Routes For Remote Networks page, click Add to add static routes assigned to the demand-dial interface (as needed). You need to add static routes that make all the locations reachable. Because many remote sites use a static set of addresses within the site, dynamic routing protocols are not usually needed. If you do want to use dynamic routing, consider using static routes on the VPN routers that summarize the addresses used on the other sites and add the static routes to a neighboring router on the intranet subnet to which the VPN router is attached. Then configure the intranet routers to do dynamic routing and advertise the static routes for the other sites to the rest of the site network.
On the Dial In Credentials page, in the Password and Confirm Password text boxes, type the password of the user account used by the calling router. An example is shown in the following figure.

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 site-to-site connection rather than a remote access connection.
Click Next. On the Dial Out Credentials page, type the user name in the User Name text box, the user account domain name in the Domain text box, and the user account password in both the Password and Confirm Password text boxes. This is shown in the following figure.

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 the User Name text box and skip the rest of the fields because this router never uses this interface to initiate a connection to the calling router. Click Next.
On the Completing The Demand-Dial Interface Wizard page, click Finish.

The result of this configuration is an L2TP/IPSec-based or PPTP-based demand-dial interface over which IP routing is enabled, depending on the tunneling protocol options you chose. 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

Now we must configure the calling router. Deploying the calling router for a site-to- site VPN connection consists of the following steps:

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 an IP address, a subnet mask, site DNS servers, and site WINS servers. If you configure a default route on the site connection, it will create a conflicting default route entry in the routing table and routing to the Internet might not function properly.

To run the Routing And Remote Access Server Setup Wizard to configure the Windows Server 2003 calling router

Click Start, point to Administrative Tools, and then click Routing And Remote Access.
Right-click your server name, and then click Configure And Enable Routing And Remote Access. Click Next.
In Configuration, click Remote Access (Dial-Up Or VPN) and then click Next.
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.
In VPN Connection, click the connection that corresponds to the interface connected to the Internet or your perimeter network, and then click Next.
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 for the virtual interfaces of routers calling this router to be reachable. When IP address assignment is complete, click Next.
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.
Click Finish.

To configure a demand-dial interface

Open the Routing And Remote Access snap-in.
In the console tree, right-click Network Interfaces and then click New Demand-Dial Interface.
On the Welcome To The Demand-Dial Interface Wizard page, click Next.
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.
On the Connection Type page, click Connect Using Virtual Private Networking (VPN) and then click Next.
If you are deploying PPTP as the tunneling protocol, on the VPN Type page click Point To Point Tunneling Protocol (PPTP) and then click Next. If you are deploying L2TP/IPSec as the tunneling protocol, on the VPN Type page click Layer 2 Tunneling Protocol (L2TP) and then click Next.
On the Destination Address page, type the IP address of the answering router, then click Next.
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 A Remote Router Can Dial In check box. Click Next.
On the Static Routes For Remote Networks page, click Add to add static routes assigned to the demand-dial interface (as needed). Click Next.
For a two-way initiated connection, in the Dial In Credentials page (this page is presented only if you selected the Add A User Account So A Remote Router Can Dial In option in step 8), type the password of the user account used by the answering router acting as a calling router in the Password and Confirm Password text boxes, 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.
On the Dial Out Credentials page, type the user name in the User Name text box, the user account domain name in the Domain text box, and the user account password in both the Password and Confirm Password text boxes. Click Next.
On the Completing The Demand-Dial Interface Wizard page, click Finish.

The result of this configuration is either an L2TP/IPSec-based or PPTP-based demand-dial interface over which IP routing is enabled, depending on the tunneling options you chose. A user account with the same name as the demand-dial interface is automatically added with correct account and dial-in settings (if needed).

Having both routers set up for either side of the site-to-site VPN connection, now we have to make sure that each one can authenticate, authorize and record accounting information to ensure security and control. We will now describe how to set up authentication, authorization, and accounting (AAA) to support your site- to-site VPN.

Deploying the AAA Infrastructure

Routing and Remote Access can be configured with either the Windows or RADIUS authentication provider. If Routing and Remote Access is configured with the Windows authentication provider, then RADIUS servers are not required and you configure the authorization (the remote access policies) and accounting (logging) using the Routing and Remote Access snap-in. If Routing and Remote Access is configured with the RADIUS authentication provider, then you must configure RADIUS servers to provide AAA. This section assumes the use of RADIUS and Internet Authentication Service (IAS).

IAS handles AAA for Windows-based deployments. If the IAS server fails, no connections can be authenticated or authorized. For this reason, we will be deploying two IAS servers for redundancy and reliability.

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

Configure Active Directory for user accounts and groups.
Configure the primary IAS server computer.
Configure the secondary IAS server computer.

Configuring Active Directory for User Accounts and Groups

Active Directory is the central resource for maintaining and controlling all access to your network, including site-to-site VPN connections.

To configure Active Directory for user accounts and groups

Ensure that all calling routers that are making site-to-site connections have a corresponding user account.
Set the remote access permission on each of the calling-router user accounts to Allow Access or Deny Access to manage remote access by user. Or, to manage access by group, set the remote access permission on user accounts to Control Access Through Remote Access Policy.
Organize each of the calling-router user accounts into the appropriate universal and nested groups to take advantage of group-based remote access policies.

Configuring the Primary IAS Server Computer

The primary IAS server will be the first stop for any authentication activities on the VPN.

To install IAS on the primary IAS server computer

Open Add Or Remove Programs in Control Panel.
Click Add/Remove Windows Components.
In the Windows Components Wizard dialog box, double-click Networking Services under Components.
In the Networking Services dialog box, select Internet Authentication Service.
Click OK and then click Next.
If prompted, insert your Windows product compact disc.
After IAS is installed, click Finish and then click Close.

The primary IAS server computer must be able to access account properties in the appropriate domains. If IAS is being installed on a domain controller, no additional configuration is required for IAS to access account properties in the domain to which it belongs. 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. You can do this by following the next set of procedures.

To configure the primary IAS server computer to read the properties of user accounts in the domain

Click Start, point to Administrative Tools, and then click Internet Authentication Service.
In the console tree, right-click Internet Authentication Service (Local) and then click Register Server In Active Directory.

A Register Internet Authentication Server In Active Directory dialog box appears.
Click OK.

Alternatively, you can:

Use the netsh ras add registeredserver command

or
Add the computer account of the IAS server to the RAS And IAS Servers security group by using the Active Directory Users And Computers snap-in.

If the IAS server is to authenticate and authorize VPN connection attempts for user accounts in other domains, verify that the other 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 by using the netsh ras add registeredserver command or the Active Directory Users And Computers snap-in.

If there are accounts in other domains and the 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. If there are accounts in other untrusted Active Directory forests, you must configure a RADIUS proxy between the forests.

If you want to store authentication and accounting information for connection analysis and security investigation purposes, enable logging for accounting and authentication events. Windows Server 2003 IAS can log information to a local file and to a Microsoft Structured Query Language (SQL) Server database.

To enable and configure local file logging for Windows Server 2003 IAS

In the console tree of the Internet Authentication Service snap-in, click Remote Access Logging.
In the details pane, double-click Local File.
On the Settings tab, select one or more check boxes for recording authentication and accounting requests in the IAS log files:
- To capture accounting requests and responses, select the Accounting Requests check box.
- To capture authentication requests, access-accept packets, and access- reject packets, select the Authentication Requests check box.
- To capture periodic status updates, such as interim accounting packets, select the Periodic Status check box.
On the Log File tab, type the log file directory as needed and select the log file format and new log time period.

To enable and configure SQL Server database logging for Windows Server 2003 IAS

In the console tree of the Internet Authentication Service snap-in, click Remote Access Logging.
In the details pane, double-click SQL Server.
On the Settings tab, select one or more check boxes for recording authentication and accounting requests in the IAS log files:
- To capture accounting requests and responses, select the Accounting Requests check box.
- To capture authentication requests, access-accept packets, and access- reject packets, select the Authentication Requests check box.
- To capture periodic status updates, such as interim accounting packets, select the Periodic Status check box.
In the Maximum Number Of Concurrent Sessions text box, type the maximum number of simultaneous sessions that IAS can create with SQL Server.
To configure an SQL data source, click Configure.
On the Data Link Properties dialog box, configure the appropriate settings for the SQL Server database.

Configuring IAS with RADIUS Clients

IAS must be configured to accept RADIUS messages from valid RADIUS clients. Therefore, you must configure the primary IAS server with RADIUS clients that correspond to the answering VPN routers.

To add a RADIUS client for Windows Server 2003 IAS

In the Internet Authentication Service snap-on, right-click RADIUS Clients and then click New RADIUS Client.
On the Name and Address page, type a name for the answering VPN router in the Friendly Name text box. In the Client Address (IP Or DNS) text box, type the IP address or DNS domain name. If you type a DNS domain name, click Verify to resolve the name to the correct IP address for the VPN router.
Click Next.
On the Additional Information page, type the shared secret for this combination of IAS server and VPN router in the Shared Secret text box and then type it again in the Confirm Shared Secret text box.
Click Finish.

Using IPSec to Secure RADIUS Traffic

To ensure the maximum security for RADIUS messages, it is recommended that you use Internet Protocol Security (IPSec) with certificate authentication and Encapsulating Security Payload (ESP). This will provide data confidentiality, data integrity, and data-origin authentication for RADIUS traffic sent between the IAS servers and the VPN routers. Windows 2000 and Windows Server 2003 support IPSec.

Configuring a VPN Remote Access Policy with Windows Server 2003 IAS

To specify different connection settings for different tunneling or authentication protocols, and other settings that can pertain to site-to-site VPN connections, use IAS to create remote access policies.

To create a remote access policy for site-to-site VPN connections for Windows Server 2003 IAS

From the console tree of the Internet Authentication Service snap-in, right- click Remote Access Policies and then click New Remote Access Policy.
On the Welcome To The New Remote Access Policy Wizard page, click Next.
On the Policy Configuration Method page, type the name of the policy in Policy Name.
Click Next.
On the Access Method page, select VPN.
Click Next.
On the User Or Group Access page, select Group.
Click Add.
In the Select Groups dialog box, type the name of your universal or global VPN calling routers group in the Enter The Object Names To Select text box.
Click OK. Your VPN calling routers group is added to the list of groups on the User Or Group Access page.
Click Next. On the Authentication Methods page, select the authentication methods you want your VPN calling routers to use.
To enable EAP-TLS authentication, select Extensible Authentication Protocol (EAP) and select Smart Card Or Other Certificate in the Type drop-down list. Then click Configure. In the Smart Card Or Other Certificate Properties dialog box, ensure that the name of the computer certificate installed on the IAS server is visible in Certificate Issued To. If there are multiple computer certificates installed on the IAS server, select the correct one in Certificate Issued To.

If you cannot select the certificate, the cryptographic service provider for the certificate does not support Secure Channel (SChannel). SChannel support is required for IAS to use the certificate for EAP-TLS authentication.
Click Next.
On the Policy Encryption Level page, clear the encryption strengths that you do not want to use. For example, to use 128-bit Microsoft Point-to-Point Encryption (MPPE), clear the Basic Encryption and Strong Encryption check boxes.
Click Next.
On the Completing The New Remote Access Policy page, click Finish.

Configuring the Secondary IAS Server Computer

In any well-deployed solution, you need to account for redundancy and failover, especially in the authentication systems of the network. To accomplish this, our setup contains primary and secondary IAS servers. This setup is optional, but a best practice is to have two sources for AAA services in case of a network or hardware failure. To configure the secondary IAS server computer, follow the instructions described earlier in the “Configuring the Primary IAS Server Computer” section, specifically those regarding how to install IAS and register the IAS server computer in the appropriate domains.

Next you need to copy the configuration of the primary IAS server to the secondary IAS server.

To copy the configuration of the primary IAS server to the secondary IAS server

On the primary IAS server computer, type netsh aaaa show config > path\file.txt at a command prompt. This stores the configuration settings, including registry settings, in a text file. The path can be a relative, absolute, or network path.
Copy the file created in step 1 to the secondary IAS server.

On the secondary IAS server computer, type netsh exec path\file.txt at a command prompt. This imports all the settings configured on the primary IAS server into the secondary IAS server.

Best Practices

If you change the IAS server configuration in any way, use the Internet Authentication Service snap-in to change the configuration of the IAS server that is designated as the primary configuration server and then use the command-line copy procedure to synchronize those changes on the secondary IAS server.

Deploying the Site Network Infrastructure

At this point, we have the VPN servers setup and connected to the Internet, and they have the ability to authenticate each other’s user accounts to Active Directory. Now we need to configure the routers to forward traffic to each other’s networks. It would not be very useful for the site-to-site link to be up but not provide forwarding to networks on either side of the link. Deploying the network infrastructure of a site for site-to-site VPN connections consists of the following steps:

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

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 the other 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.

Routing Table Maintenance Methods

You can add routes to routing tables using the following methods:

Dynamic routing using routing protocols
Static routing using manually-configured static routes

It’s up to you to analyze the network and decide which method to use at which time and on which portion of the network. Many would say that for the sake of administrative ease you should settle on one method, but a savvy network designer will identify how to use the methods to their best advantage and make them work together to provide the best network communications. We’ll show you where and when to use each method, but first we’ll show you the different uses of routing protocols in a Routing And Remote Access environment and explain why you should deploy different solutions for different scenarios.

Let’s take a look at different scenarios and usages of routing protocols in an enterprise VPN solution:

Failover

When you are running client systems—or an end-point, site-to-site system—that are critical to the company’s operations, you want to ensure interoperability and resilience in the case of network failure or hardware failure. This means that when you have more than one VPN router running, you want the two systems to monitor each other—one as a primary system and one as a failover system. The failover system must be able to tell when the primary router has failed and adjust the network so that all communications will go through it rather than the primary router. Dynamic routing protocols such as Open Shortest Path First (OSPF) allow you to set up two equal systems and keep one in failover mode while monitoring the primary system for availability. If the primary fails, the secondary can reconverge the network to go through the secondary path.

Network redundancy

Sometimes the infrastructure of the network layout shows that one VPN entry point is preferable to another, and you’ll want to streamline network traffic to run through different options based on the location of the end-user systems and the VPN routers. By deploying dynamic routing, you can always be sure that the end user is getting the most viable traffic link at any given time. If, for example, there are multiple resources to service a request (redundant databases, Web servers, mail servers, etc.) but you want to force traffic down a particular network path for a logistical reason, you can use routing protocols with weighted routes. If you need more information about how to apply a weight to a route, please refer to the appropriate documentation for your router equipment. Route prioritization is a critical function for VPN strategies because users and remote sites will have relatively low bandwidth to network resources as compared to internal nodes that will have full switching speeds available to them. To give the VPN users the same kind of network experience, you might want to work with your routing protocols to give them access to faster or closer solutions on the network.

Routing solutions

A proper combination of routing methods allows a network to perform at peak efficiency. There isn’t one magic method that can do all the work. For instance, you will want routing to stay static on well-known routes that will be advertised to outside entities, but you want to keep your intranet dynamic so that it can make quick changes if necessary. You also want to reduce the amount of administrative overhead needed to handle the routing of the internal resources and make the network changes transparent to the remote access-based user groups. These groups would be heavily affected if they had to be aware of every network change occurring internally. A cross between dynamic and static routing solutions will give the remote users an extrapolation layer to these changes and provide for a better overall experience with the VPN systems.

Dynamic routing vs. static routing

You need to understand two kinds of routing methods to get the greatest benefit from the VPN solutions and communications standards we are implementing: dynamic routing and static routing.

Dynamic routingAs the name implies, dynamic routing allows for the dynamic addition and deletion of routing in the routing table that reflect up- to-the minute changes in the network, and it allows the network to converge itself in the event that there is a change in the network topology. An example of dynamic routing is shown in Figure 9-1.

click to expand
Figure 9-1: Dynamic routing operations

In Figure 9-1, we can see that the network has two ways for a user on Network A to reach Network C. If everything is working properly on the routing infrastructure, there is a direct link from Router A to Router C. Therefore, the fastest way for traffic to get to Network C is to use that link. Next we see that the physical circuit from Router A to Router C is lost. The topology change triggers a dynamic routing protocol update to all interested routers, and the routing protocol makes an assessment of the new topology. It finds that there is another path from Network A to Network C through Router B. The routing protocol updates all interested routers with the change, and now the path via Router B is the primary choice for communications. Next we see that the link between Router A and Router C is reestablished. Because that link is a faster route with fewer hops for the data to traverse than the Router A to Router B to Router C option, the routing protocol will automatically update all routers again with the new information and give precedence to the shortest hop path.

Note

We have used the term converge a few times, so it is appropriate that we define network convergence. Convergence is the process a network uses to change its topology combined with the routing infrastructure’s process of mitigating that change in the topology. For instance, in the preceding example, when the link between Router A and Router C goes down, all three routers will exchange routing protocol information and recalculate their routing tables to account for the change. The recalculation process is called convergence. As the number of routers involved in the calculation process increases, so does the amount of time the network needs to converge on an agreed-upon topology for routing traffic.

Static routingAs the name implies, this routing solution mandates that the routes to various addresses or subnets be manually programmed onto each router and that they cannot be automatically changed. An example of static routing is shown in Figure 9-2.

Figure 9-2: Static routing operations

In this example, we see that Router A has a static route configured to Router C. There can be several reasons why the route is defined statically: operations, high-latency link, security, and so forth. We then see that the physical link between Router A and Router C is lost. Though there is an alternative physical path from Network A to Network C through Router B, no static routing exists that describes that route. Because we are using static routing in this configuration, the routing tables do not change—all traffic between Network A and Network C is now blocked. Once the link is re-established, all traffic flows normally. This setup might seem undesirable on the surface, but there are definite instances where this behavior might be desirable, especially for site-to-site VPN connections.

Pros and cons of deploying routing protocols with VPNs

When looking at the preceding examples, you would think that you’d want to use dynamic routing whenever possible because it is self-configuring and static routing is less configurable and less flexible. So why would we ever want to use static routing? There is one basic, but flawed, assumption administrators make when deploying a dynamic routing protocol: the network links are relatively stable and are always under the control of the administrator. Neither one of these conditions applies when routing traffic over the Internet! What’s more, Internet links are susceptible to latency issues. One example is when there is a long delay on an Internet connection and there is no communication between nodes for a few seconds. In such a case, the link can be perceived as being down by the dynamic routing protocol, thus causing a reconvergence of the routing infrastructure when there was no real physical change in the topology.

In a well-designed VPN installation, there is a place and time to use both dynamic and static routing, such as OSPF and Routing Information Protocol (RIP). The way to deploy both for maximum performance and benefit is shown in Figure 9-3.

click to expand
Figure 9-3: Dynamic and static routing with VPN services

Let’s go over the benefits and problems of both static and dynamic routing when operating a VPN installation to see where and when to use each.

One of the pros for using dynamic routing is that it includes the VPN router in the routing infrastructure. Including the VPN router in the dynamic routing infrastructure allows users to have full access to resources without having to worry about internal issues and updates to the network infrastructure. The dynamic routing protocol operates on the intranet interfaces of the VPN router in conjunction with the internal routing infrastructure to give the VPN router a clear and up-to-date routing solution.

Note

When setting up your VPN router and the intranet network interfaces, you should not configure a default gateway on the intranet interface. The reason for this is that all communications on the VPN router, no matter how many physical interfaces are installed on the system, will still run through one TCP/IP protocol stack. That protocol stack will only use one default gateway for the entire system at any one time and that default gateway needs to point to make all locations on the Internet reachable. Configuring a default gateway on an intranet interface might cause the VPN router to lose reachability to the Internet.

A reason against using dynamic routing is that VPN, by its nature, is subject to “slow” links and latency-rampant communications. In later sections, we’ll discuss the operations of the different kinds of dynamic routing supported by the Routing And Remote Access service. The main thing to keep in mind now is that if a link cannot be contacted for a certain period of time, the dynamic routing protocol will send out updates to the network saying that it has to reconverge. If the loss of contact is because of extended latency on the Internet, the link can be perceived by the dynamic routing protocol as going up and down, a phenomenon known as route flapping. This will cause the network to continually reconverge and can cause a failure in communications. For this reason, we have dynamic routing running only on controlled circuits and interfaces. Public interfaces are configured with static routes.

A significant consideration for using static routing is that, as stated previously, VPNs by their nature are subject to the Internet and high-latency situations. You’ll definitely want to maintain the routing infrastructure’s information when latency issues occur because the routing infrastructure will always be constant on certain links. Static routing is preferred because, unlike dynamic routing, it is not subject to latency issues.

As for disadvantages of using static routing, the main problem is that static routing is manually configured on each node it touches that is part of the network topology. If there is a need to reroute traffic to another segment or physical link, the administrator needs to do so manually on the static routing system. In essence, the network has no way to dynamically heal itself in the event of a topology change.

Prudent network administrators will use a combination of static and dynamic routing protocols to create the most robust and resilient VPN services for their networks.

Now that we have a complete understanding of the options, pros, and cons of using different kinds of routing techniques, you need to decide which ones to use and when and where to use them on your deployment. We will leave that determination up to your needs, but here are the procedures you need to follow to add static routing, dynamic routing, or both to your VPN deployment.

To add a static route for intranet routes

Open the Routing And Remote Access snap-in.
In the console tree, open Routing And Remote Access, choose the server name, and then select IP Routing.
Right-click Static Routes.
Click New Static Route.
In the Static Route dialog box, select the intranet interface from the Interface drop-down list; type the destination, network mask, and gateway information in the appropriate text boxes; and set the appropriate metric in the Metric box. This dialog box is shown in the following figure.
Click OK to add the route.
Repeat steps 3 through 6 for each additional intranet route.

Although we gave a general overview of static vs. dynamic routing, the detailed configuration required for a VPN router to act as a RIP or OSPF router is beyond the scope of this book. For more information, see the topics titled “Configure RIP for IP,” “OSPF Design Considerations,” and “Configure OSPF” in Windows Server 2003 Help And Support.

Verifying Reachability from Each VPN Router

From each VPN router (the calling router and answering 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, using Internet Explorer, and making drive and printer connections to known servers within the site.

Configuring Routing for Off-Subnet Address Ranges

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 or routes representing the off-subnet address ranges are present in your site routing infrastructure. This is required to reach the virtual interfaces of calling routers. You can ensure this by adding the static route or routes representing the off-subnet address ranges as static routes to the neighboring routers of the VPN routers and then using the routing protocol of your site to propagate the route to other routers. When you add the static routes, you must specify that the gateway or next hop address is the site interface of the VPN router.

Alternatively, 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). This simply means that you need to configure OSPF on the VPN router to advertise static routes. For more information, see the topic titled “OSPF Design Considerations” in Windows Server 2003 Help And Support.

Deploying the Intersite Network Infrastructure

It is not enough that each router needs to know about the routes within its site; each router needs to also know about the routes in the other VPN router’s site so that it can correctly forward traffic to the other side of the site-to-site VPN connection. 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

We can add static routes manually or we can use the more automatic method of auto-static propagation. We will start with the manual method, and then go to the automatic method. It is a good best practice to know how to do manual static updates before using the automatic method in case you have to troubleshoot the setup, so as tempting as it is to skip to the auto-method, take the time to add some static routes as well. To manually add static routes, from the Routing And Remote Access snap-in, perform the following steps:

In the console tree, click IP Routing.
Right-click Static Routes, and then click New Static Route.
In the Static Route dialog box, select the demand-dial interface in Interface, and type the destination, network mask, and metric. You can also select the Use This Route To Initiate Demand-Dial Connections check box to initiate a demand-dial connection for traffic that matches the route. This is shown in the following figure.
Click OK to add the route.

Repeat steps 2-4 for each additional intersite route.

Note

Because the demand-dial connection is a point-to-point connection, the Gateway IP address field for routes associated with demand-dial interfaces is not configurable.

The adding of static routes can also be done during the creation of the demand- dial interface with the Demand-Dial Interface Wizard.

Performing Auto-Static Updates on Each VPN Router

If RIP for IP option 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. To see if the option is enabled, use the Routing and Remote Access snap-in to open your server name, open IP Routing, and see if RIP has been added as a routing protocol. If not, you can add RIP by right-clicking on General under IP Routing, clicking New Routing Protocol, and selecting RIP version 2 for Internet Protocol. From there, you will need to configure new interfaces and we will be getting beyond the focus of this book, so refer to the Windows Server 2003 Help And Support for detailed procedures on enabling RIP for your environment.

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.

To initiate an auto-static update

Open the Routing And Remote Access snap-in on a VPN router (assuming the site-to-site VPN connection is active).
In the console tree, click IP Routing and then click General.
In the details pane, right-click the appropriate demand-dial interface and then click Update Routes.

You can also use the netsh routing ip rip update command with the netsh interface set interface command to perform an auto-static update at the command prompt. You can automate scheduled updates by using a combination of Netsh scripts and Task Scheduler. To perform an automated auto-static update by using RIP for IP, use the following netsh commands:

netsh interface set interface name=DemandDialInterfaceName connect=CONNECTED netsh routing ip rip update DemandDialInterfaceName netsh interface set interface name=DemandDialInterfaceName connect=DISCONNECTED

For example, to automatically update the IP routes by using a demand-dial connection named CorpHub, you type the following netsh commands:

netsh interface set interface name=CorpHub connect=CONNECTED netsh routing ip rip update CorpHub netsh interface set interface name=CorpHub connect=DISCONNECTED

You can run these commands from a batch file, or you can place them in a Netsh script file. For example, the script file Corphub.scp runs the following commands for CorpHub:

interface set interface name=CorpHub connect=CONNECTED routing ip rip update CorpHub interface set interface name=CorpHub connect=DISCONNECTED

To run the Corphub.scp script, type the following at a command prompt:

 netsh -f corphub.scp

After the batch file or Netsh script file is created, you can execute the batch file or Netsh script on a scheduled basis by using Task Scheduler.

Configuring Routing Protocols

If the site-to-site VPN connection is persistent (always active), you can also configure IP routing protocols such as RIP or OSPF to operate over the VPN connection. So you thought that making the decision to use dynamic routing protocols was going to be easy? Well there is bad news and good news: The bad news is that you have more decisions to make on which dynamic routing protocol to use for your routing infrastructure. The good news is that there are only a few options to choose from and each has its benefits and caveats. Let’s take a look at each option and discuss where each one is or is not appropriate for your VPN implementation.

RIP

RIP is the first routing protocol widely used by TCP/IP networks. It is actually very easy to turn on and set up, but there are several decisions the administrator needs to make to avoid being hit with extra traffic on the network to maintain the routing infrastructure.

The first decision you have to make is whether to use RIP version 1 or RIP version 2. As if the number of choices wasn’t bad enough with all the options already in front of you, now you have to choose which version of the RIP protocol to use in your environment. Let’s take a look at the benefits of each version:

RIP Version 1This is a basic routing protocol that allows for classful IP routing updates. Classful means that subnet masks for routes are based on the original Internet address classes. It cannot understand supernetting or subnetting.
RIP Version 2Version 2 has many improvements over the original RIP, including the following features:
- Multicast announcements
- Simple password authentication
- Support for subnetted and Classless InterDomain Routing (CIDR) environments

The Windows 2000 and Windows Server 2003 Routing And Remote Access implementation of both versions of RIP have the following features:

Selection of which RIP version to run on each interface for incoming and outgoing packets
Split-horizon, poison-reverse, and triggered-update algorithms that are used to avoid routing loops and speed recovery of the internetwork when topology changes occur
Route filters for choosing which networks to announce or accept
Peer filters for choosing which router’s announcements are accepted
Configurable announcement and route aging timers
Simple password authentication support
The ability to disable subnet summarization

RIP is a broadcast-based dynamic protocol, in that it will broadcast updates on a regular basis. (With version 1, the default for the broadcast is every 30 seconds.) This behavior can lead to an increase in network traffic as the size of the network increases.

Broadcast-based operations can cause a serious side effect with demand-dial interfaces. If RIP is broadcasting every 30 seconds and the site-to-site VPN connection is designed to launch every time there is interesting traffic to be sent, RIP can cause the demand-dial interface to start flapping. Flapping is the act of an interface continually coming online and offline because of odd traffic patterns. As the interface flaps, it can cause the network routing protocols to send continual updates. This can cause serious issues on the network convergence state.

You must also consider RIP’s effect on WAN and Internet circuits. WAN and Internet circuits do not have a lot of spare bandwidth, so a protocol that broadcasts updates across the wire every 30 seconds is not desirable. The benefit to using a broadcast- based protocol is that it will at least provide a consistent timing interval for routing updates, but for the most part, RIP should be avoided on WAN and Internet links.

The preceding facts make RIP seem undesirable for use with VPN, so let’s make sure we’ve properly presented the case for using RIP. Dynamic routing in general should be used only on the intranet interfaces of the VPN router, and dynamic routing updates should not be sent over the wire to the external sites of the VPN gateway. This negates many of the issues just stated about using RIP on the external Internet or WAN links. That still leaves the issues of using a message-intensive broadcast-based routing protocol on the VPN router, but there is an upside to using RIP as your routing protocol. The first beneficial aspect is that RIP is universally supported on any routing equipment currently available. The second benefit is that RIP is incredibly easy to configure—just turn it on and it does all the work. If you have plenty of bandwidth on the intranet and you want ease of administration and deployment of a routing protocol, RIP fits those criteria and requires very little planning or management overhead.

OSPF

OSPF is designed to examine the topology and, using metrics and neighbor association information, assess which path in the routing infrastructure is best to take. OSPF then calculates a routing table based on the link information. Let’s look at some features of OSPF as a routing protocol and see how it applies to VPN- based solutions.

Compared with the broadcast-based operations of RIP, OSPF is not a bandwidth- intensive protocol. OSPF is known as a link-state-based protocol, which means it will not send out any updates or information unless triggered to do so by a particular event. The event that would cause a link-state update, or link state advertisement (LSA), is when a link to a known subnet goes off-line or a new segment comes on-line. In other words, OSPF will not send out an update unless the network topology actually changes. This behavior is much more efficient and much less bandwidth-intensive than RIP.

OSPF needs to evaluate several parameters on the communications links to determine which link is the most open and has the shortest path from one given network segment to another. Let’s look at some decisions that would affect OSPF in its decision-making process for network convergence.

Figure 9-4 shows two physical links from one network segment to another.

click to expand
Figure 9-4: Dynamic routing operations

At first glance, the links seem to be redundant, but with closer inspection we can see some differences in the circuits:

Path X contains a full T1 WAN circuit with 1.55 Mbps transmission speed. It then links up to a 100-Mbps Fast Ethernet link to get to the far network destination.
Path Y is hooked up over the WAN with a 56 Kbps Frame Relay (FR) link over a private virtual circuit (PVC). It hooks directly to the far network destination.

OSPF will consider several factors to determine which link to use. If OSPF were to use the “shortest” path, Path Y with the 56 Kbps FR link would appear to be the choice because it has fewer hops. On the other hand, even though Path X has more hops on it, it is definitely the fastest route to take, making it the more desirable link, because it has a lower “weight” assessed to it. When the routing protocol is evaluating choices on the network, the protocol will apply a weight to every path. The path with the lowest weight is the one chosen for the traffic. Both links will be recorded in the OSPF calculation table as possible choices, but a route corresponding to Path X will be put into the routing table because it provides a better communications option for the traffic. If the T1 was to go down for some reason, an LSA exchange would occur and Path Y would be added to the routing tables as the primary link.

At first glance, OSPF seems to be an ideal solution for demand-dial links, but some other issues will arise. If some network interfaces are flapping up and down, LSAs can cause L2TP/IPSec connections to continually be built up and torn down. This results in additional overhead on the VPN gateways. If you have to use a dynamic routing protocol on the demand-dial interfaces, OSPF is the best choice because it will send out an update only when there is a change on the network and it won’t broadcast every 30 seconds like RIP does. You should constrain dynamic routing to the internal interfaces of the VPN gateway and use static routing on the external network links.

Looking at it from the external network point of view, another excellent reason not to use OSPF on the external links of a VPN gateway server is because the Internet and WAN links of a network are rampant with latency issues. There is no guarantee of turn-around time of data on the Internet, so configuring and running OSPF can be problematic. The way that OSPF determines whether a link is down is through the use of HELLO packets unicasted between OSPF neighbors on a regular basis. If the HELLO packet is delayed, the link will be perceived as being down and an LSA will be produced to reconverge the network even though it might not be appropriate. Latency-plagued links will have serious issues trying to support an OSPF protocol setup.

More Info

A lot of considerations go into the design and deployment of a successful OSPF implementation. Because the focus of this book is VPN technologies and not OSPF, we will not do a complete overview of the protocol here. (There are entire books written on this subject alone!) For more information, see the topic titled "Setting up an OSPF routed internetwork" in Help and Support Center for Windows Server 2003.

OSPF is usually the best option for dynamic routing solutions on an intranet network because it is so robust and handles the routing calculations for the entire network quickly and smoothly, without causing broadcast storms on the network. OSPF should be used only on the intranet interfaces of the VPN gateway, and OSPF updates should not be allowed out of or into the intranet interfaces of the VPN routers. The downside of OSPF is the complexity required to successfully design and implement a large OSPF network. There are many OSPF concepts to become familiar with—including area zoning, stub areas, route summarization, and border router and transit router settings—the list goes on. Once it is set up properly, OSPF can be an incredible tool that allows the network to heal itself in the case of a link failure.