Unlike remote access VPNs, site-to-site links require both sides of the link to have a full set of resources to work with. Figure 8-1 shows the components of Windows Server 2003 site-to-site VPNs.
Figure 8-1: Components of Windows Server 2003 site-to-site VPNs.
The major components are:
Internet network infrastructure
Site network infrastructure
Authentication, authorization, and accounting (AAA) infrastructure
VPN routers are servers that control all remote connection operations of the site-to- site link. They are the heart of the site-to-site VPN system. VPN routers are the entities that either initiate or receive VPN-based demand-dial connections and have the following components installed on the server:
Routing And Remote Access service. The Routing And Remote Access service on both the calling and answering router is configured using the Routing And Remote Access Server Setup Wizard.
Ports. A port is a logical or physical communications channel capable of supporting a single PPP connection. Physical ports are based on equipment installed in the VPN router, such as a network adapter or a modem. VPN ports are logical ports that handle the logical connection parameters and negotiations for connections.
Demand-dial interfaces. A demand-dial interface configured on the calling router represents the PPP connection and contains configuration information such as the type of port to use (for example, PPTP or L2TP/IPSec), the addressing used to create the connection (that is, an IP address or domain name to be connected to on the Internet), authentication methods (for example, CHAP or MS-CHAP v2), encryption requirements (for example, encryption algorithms, bit strengths, and so forth), and authentication credentials (username, passwords, certificates, and so forth).
For two-way initiated connections, a demand-dial interface must be configured on the answering router that represents the PPP connection to the calling router. Because either side can be the calling router for two-way connections, demand-dial interfaces need to be created on both sides of the link. For a one-way initiated connection using static routes on the user account of the calling router, a demand-dial interface on the answering router does not need to be configured.
User account. For a calling router to be authenticated, its credentials must be verified by the properties of a corresponding user account. If the answering router is configured for Windows authentication, a user account in the authentication credentials of the calling router must be verifiable using Windows security. If the answering router is configured for RADIUS authentication, the RADIUS server must have access to the user account for the authentication credentials of the calling router.
The user account must have the following settings:
On the Dial-In tab, Remote Access Permission is set to either Allow Access or Control Access Through Remote Access Policy. When you create user accounts with the Demand-Dial Interface Wizard, the remote access permission is set to Allow Access.
On the General or Account tab, User Must Change Password At Next Logon is disabled, and Password Never Expires is enabled. These settings are configured when you create user accounts with the Demand- Dial Interface Wizard.
For a one-way initiated connection, you can configure static IP routes on the Dial-In tab that are added to the answering router’s routing table when the demand-dial connection is made. Doing this will allow the calling router to know what subnets are available on the far side of the link and determine whether to establish that link using those static routes.
Routes. To forward traffic across a site-to-site VPN connection, IP routes in the routing tables of the VPN routers are configured to use the correct demand-dial interface.
For one-way initiated connections, configure the calling router normally. For the answering router, you can configure the user account specified in the authentication credentials of the calling router with static IP routes.
Remote access policy. On the answering router or the Internet Authentication Service (IAS) server that is acting as a RADIUS server to the answering router, to specify connection parameters that are specific to demand-dial connections, create a separate remote access policy that uses the Windows- Groups attribute set to the group that has all the user accounts for calling routers as members. A separate remote access policy for demand-dial connections is not required.
A calling router does the following:
Initiates VPN connections based on a manual administrator action or automatically when a packet being forwarded matches a route using a VPN- based demand-dial interface
Waits for authentication and authorization before forwarding packets
Acts as a router forwarding packets between nodes in its site and the answering router
Acts as an endpoint of the VPN connection
The answering router does the following:
Listens for VPN connection attempts
Authenticates and authorizes VPN connections before allowing data to flow
Acts as a router forwarding packets between nodes in its site and the calling router
Acts as an endpoint of the VPN connection
VPN routers typically have two installed network adapters—one network adapter connected to the Internet (untrusted), and one network adapter connected to the intranet (trusted).
When you configure and enable the Routing And Remote Access service, the Routing And Remote Access Server Setup Wizard prompts you to select the role the computer will fulfill. For VPN routers, you should select the Remote Access (Dial- Up Or VPN) option. With the Remote Access (Dial-Up Or VPN) option, the Routing and Remote Access server operates in the role of a VPN server that supports both remote access and site-to-site VPN connections. For remote access VPN connections, users run VPN client software (which, for Windows 2000 and Windows XP clients, is a native part of the operating system and requires no extra software loads) and initiate a remote access connection to the VPN server. For site-to-site VPN connections, a router initiates a VPN connection to the VPN server and the clients do not need to launch a VPN themselves—all traffic will be handled by the end node routers for them. Alternately, the VPN server can initiate a VPN connection to another VPN router.
Microsoft recommends the choice of Remote Access (Dial-Up Or VPN) instead of Secure Connection Between Two Private Networks in the Routing And Remote Access Server Setup Wizard. Microsoft recommends this option because the Secure Connection Between Two Private Networks option does not prompt you to select an Internet interface over which to automatically configure packet filters, does not prompt you to configure RADIUS servers, and creates only 5 PPTP and 5 L2TP ports. Using the former option allows for more versatility, automatic feature sets, and more ports on which to make connections.
When you select the Remote Access (Dial-Up Or VPN) option in the Routing And Remote Access Server Setup Wizard, the following steps occur:
You are first prompted to specify whether VPN, dial-up, or both types of access are needed.
Next, you are prompted to select the interface that is connected to the Internet, thus identifying it as untrusted and in need of having extra security features applied. The interface you select will be automatically configured with packet filters that allow only PPTP- and L2TP/IPSec-related traffic (unless you clear the Enable Security On The Selected Interface By Setting Up Static Packet Filters check box). All other traffic is silently discarded. For example, you will no longer be able to ping the Internet interface of the VPN server. This configuration is vital to prevent hackers from causing denial of service (DoS) attacks and trying to gain access on other open ports that might be available. Only authorized VPN connections will be allowed.
If you have multiple network adapters connected to the intranet, you are prompted to select an interface over which Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Windows Internet Naming Service (WINS) configuration will be obtained. Making the correct choice here is vital because all clients connecting to the VPN server will inherit these settings and an incorrect choice might result in the wrong addresses being assigned to the remote access or site-to-site connections.
Next, you are prompted to determine whether you want to obtain IP addresses to assign to remote access clients by using either DHCP or a specified range of addresses. If you select a specified range of addresses, you are prompted to add one or more address ranges. Make sure that any static assigned ranges are excluded from relevant DHCP scopes to avoid conflicts. It is recommended that over 20 connections be handled by DHCP services for convenience and control of the administrators.
Next, you are prompted to specify whether you want to use RADIUS as your authentication provider. If you select RADIUS, you are prompted to configure primary and alternate RADIUS servers and the shared secret. This option is a good one if you are going to have multiple technologies accessing the same authentication services. For instance, if you are using VPN and wireless access at your company, both services should access RADIUS so that only one user credential database needs to be maintained at one time. This option also allows for easier auditing and reporting of logging with IAS RADIUS and structured query language–Extended Markup Language (SQL- XML) logging capabilities on Windows Server 2003.
When you select the Remote Access (Dial-Up Or VPN) option in the Routing And Remote Access Server Setup Wizard, the results are as follows:
The Routing And Remote Access service is enabled as both a remote access server and a LAN and demand-dial router, with Windows as the authentication and accounting provider (unless RADIUS was chosen and configured). If there is only one network adapter connected to the intranet, that network adapter is automatically selected as the IP interface from which to obtain DHCP, DNS, and WINS configuration. Otherwise, the network adapter specified in the wizard is selected to obtain DHCP, DNS, and WINS configuration. If specified, the static IP address ranges are configured.
Exactly 128 PPTP and 128 L2TP ports are created. All of them are enabled for both inbound remote access connections and inbound and outbound demand-dial connections.
The selected Internet interface is configured with input and output IP packet filters that allow only PPTP and L2TP/IPSec traffic.
The DHCP Relay Agent component is added with the Internal interface. If the VPN server is a DHCP client at the time the wizard is run, the DHCP Relay Agent is automatically configured with the IP address of a DHCP server. Otherwise, you must manually configure the properties of the DHCP Relay Agent with an IP address of a DHCP server on your intranet. The DHCP Relay Agent forwards DHCPInform packets between VPN remote access clients and an intranet DHCP server. This is necessary because the remote access VPN client does not know where to send the DHCPInform packets. The DHCP Relay Agent takes the DHCPInform message from the remote access client and unicasts it to the configured DHCP server.
The Internet Group Management Protocol (IGMP) component is added. The Internal interface is configured for IGMP router mode. All other LAN interfaces are configured for IGMP proxy mode. This allows VPN remote access clients to send and receive IP multicast traffic. IGMP is not a multicast protocol in itself, but it’s required if multicast is going to be used across the VPN router. Multicast will not work without IGMP.
With Windows Server 2003, Web Edition, and Windows Server 2003, Standard Edition, you can create up to 1,000 PPTP ports, and you can create up to 1,000 L2TP ports. However, Windows Server 2003, Web Edition, can accept only one VPN connection at a time. Windows Server 2003, Standard Edition, can accept up to 1,000 concurrent VPN connections. If 1,000 VPN clients are connected, further connection attempts are denied until the number of connections falls below 1,000. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition can create unlimited numbers of ports.
If VPN routers are making L2TP/IPSec connections or using EAP-TLS authentication, certificates must be installed on the VPN router computers. For L2TP/IPSec connections, a computer certificate must be installed on both the calling and answering router computers to provide authentication for establishing an IPSec session. For EAP-TLS authentication, a computer certificate must be installed on the authenticating server (either the answering router or a RADIUS server) and a user certificate must be installed on the calling router.
For more information about installing certificates on calling routers, answering routers, and authentication server computers, see the “Certificate Infrastructure” section later in this chapter.
Obviously, site-to-site communications require some intensive cooperation from either side of the link and several options need to be configured in conjunction with each other to make it completely operational. Consider the following before running the Routing And Remote Access Server Setup Wizard:
Which connection of the VPN router is connected to the Internet? Typical Internet-connected VPN routers have at least two LAN connections: one connected to the Internet (either directly or connected to a perimeter network), and one connected to the site. To make this distinction easier to see while in the Routing And Remote Access Server Setup Wizard, rename the connections with their purpose or role using Network Connections. For example, if the connection connected to the Internet has the default name “Local Area Connection 2”, rename that connection to “Internet”.
Can the VPN router be a DHCP client? The VPN router must have a manual TCP/IP configuration for its intranet interface. While it’s technically possible to have the Internet interface be dynamically assigned, the use of an external DNS dynamic update service is required to maintain the DNS relationship between the VPN server’s fully qualified domain name and the dynamically assigned IP address. Additionally, it is not recommended that the VPN server be a DHCP client for its intranet interfaces. Because of the routing requirements of the VPN router, you should manually configure an IP address, subnet mask, DNS server or servers, and WINS server or servers, but you should not configure a default gateway.
Note that the VPN router can have a manual TCP/IP configuration and still use DHCP to obtain IP addresses for remote access VPN clients and other calling routers.
How will IP addresses be allocated to remote access VPN clients and other calling routers? The VPN router can be configured to obtain IP addresses from DHCP or from a manually configured set of address ranges. Using DHCP to obtain IP addresses simplifies the configuration; however, you must ensure that the DHCP scope for the subnet to which the site connection of the calling router is attached has enough addresses for all the computers physically connected to the subnet and the maximum number of PPTP and L2TP ports. For example, if the subnet to which the site connection of the VPN router is attached contains 50 DHCP clients, the scope for the default configuration of the VPN router should contain at least 307 addresses (50 computers + 128 PPTP clients + 128 L2TP clients + 1 address for the VPN router). Also, note that the Routing And Remote Access service is designed to grab 10 addresses from the DHCP scope at a time. Once the set of 10 is used up, the server will request another 10 addresses. If there are not enough IP addresses in the scope, remote access VPN clients and calling routers that connect after all the addresses in the scope are allocated will be assigned an address in the Automatic Private IP Addressing (APIPA) range of 169.254.0.0/16.
If you configure a static pool of addresses, ensure that the pool has enough addresses for all your PPTP and L2TP ports, plus an additional address for the VPN router. If there are not enough addresses in your static pool, remote access VPN clients and Windows NT 4.0 RRAS calling routers will not be able to connect. Windows Server 2003 calling routers, however, will still be able to connect. Windows Server 2003 calling and answering routers will still request an IP address from each other during the connection establishment process. But if one of the routers does not have an address to assign, both routers continue with the connection establishment process. The logical interface on the point-to-point connection does not have an assigned IP address. This condition is known as an unnumbered connection. While Windows Server 2003 VPN routers support unnumbered connections, the dynamic routing protocols included with Windows Server 2003 do not work over an unnumbered connection.
If you are configuring a static pool of addresses, there might be additional routing considerations. For more information, see the “Site Network Infrastructure” section later in this chapter.
What is the authentication and accounting provider? The authentication provider will take the credentials presented by the connecting entity and verify them for the VPN router. The accounting provider maintains detailed logs of successes and failures of the connections being made. The VPN router can use Windows or RADIUS as its authentication or accounting provider.
When Windows is used as the authentication and accounting provider, the VPN router uses Windows security to validate the credentials of a calling router and access the calling router’s user account dial-in properties. Locally configured remote access policies authorize the VPN connection and locally written accounting log files log VPN connection accounting information. This scenario is good for small to medium installations because accounting needs will be contained on a few select nodes.
When RADIUS is used as the authentication and accounting provider, the VPN router uses a configured RADIUS server to validate the credentials of a calling router, authorize the connection attempt, and store VPN connection accounting information. Using RADIUS is ideal for large-scale installations or scenarios where multiple technologies (for example, VPN and wireless solutions in the same organization) need to use the same authorization and accounting tools. Also, using RADIUS with IAS allows for centralized logging and auditing using the new SQL-XML logging features of Windows Server 2003.
Are you making L2TP/IPSec connections? If so, you must install a computer certificate on both the calling router and answering router computers or use preshared keys. Because of security issues, Microsoft recommends the use of certificates.
Are you using user-level certificate authentication with EAP-TLS? If so, you must install a user certificate on the calling router computer and a computer certificate on the authenticating server. The authenticating server will be the answering router computer if the answering router is configured for the Windows authentication provider, or it will be the RADIUS server if the answering router computer is configured for the RADIUS authentication provider. If the authenticating server is a Windows Server 2003 VPN router or a Windows Server 2003 Internet Authentication Service (IAS) server, EAP- TLS is available only if the authenticating server is a member of a Microsoft Active Directory directory service domain.
For on-demand connections, do you want to prevent connections from occurring during certain times of the day, during the week, or for certain types of traffic? If so, configure dial-out hours or demand- dial filters on the demand-dial interface of the calling router.
Do you want to match your IP packet filters to the demand-dial filters? Demand-dial filters are applied before the connection is made. IP packet filters are applied after the connection is made. To prevent the demand-dial connection from being established for traffic that is discarded by the IP packet filters:
If you have configured a set of outbound IP packet filters with the Transmit All Packets Except Those That Meet The Criteria Listed Below option, configure the same set of filters as demand-dial filters with Initiate Connection set to For All Traffic Except.
If you have configured a set of outbound IP packet filters with the Drop All Packets Except Those That Meet The Criteria Listed Below option, configure the same set of filters as demand-dial filters with Initiate Connection set to Only For The Following Traffic.
Consider the following when changing the default configuration of the VPN router for site-to-site VPN connections:
Do you want to support remote access VPN connections? By default, all the PPTP and L2TP ports are configured to allow both remote access connections (inbound only) and demand-dial routing connections (inbound and outbound). To disable remote access connections and create a dedicated site-to-site VPN connection server, clear the Remote Access Connections (Inbound Only) check box from the properties of the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices from the properties of the Ports object in the Routing And Remote Access snap-in. Alternatively, you can clear the Remote Access Server check box on the General tab on the properties of the VPN server.
Do you need to install a computer certificate? For each VPN router that is supporting L2TP/IPSec connections with certificates or is authenticating connections using the EAP-TLS authentication protocol and configured to use the Windows authentication provider, you must install a computer certificate. If a VPN router is a calling router using the EAP-TLS authentication protocol, you must install a user certificate on that router. For more information, see the “Certificate Infrastructure” section later in this chapter.
Do you need custom remote access policies for VPN connections? If you configure the VPN router for Windows authentication or for RADIUS authentication and the RADIUS server is an IAS server, the default remote access policies reject all types of connection attempts unless the remote access permission of the user account’s dial-in properties is set to Allow Access. If you want to manage authorization and connection parameters by group or by type of connection, you must configure additional remote access policies. For more information, see the “Remote Access Policies” section later in this chapter.
Do you want separate authentication and accounting providers? The Routing And Remote Access Server Setup Wizard configures both authentication and accounting providers to be the same. After the Wizard is complete, however, you can configure the authentication and accounting providers separately (for example, if you want to use Windows authentication and RADIUS accounting). You can configure authentication and accounting providers on the Security tab from the properties of the VPN router in the Routing And Remote Access snap-in.
After the VPN router is configured, you can begin creating demand-dial interfaces and configuring routes using the Routing And Remote Access snap-in. For more information, see Chapter 9.
To create a site-to-site VPN connection to an answering router across the Internet, you need to ensure that name resolution, IP availability and routing, and discovery services are operational and properly configured. You should remember three main issues for enabling successful connections:
The answering router’s name must be resolvable.
The answering router must be reachable.
VPN traffic must be allowed to and from the answering router.
While it is possible to configure demand-dial interfaces with the names of the answering routers to which a connection is made, you should use IP addresses rather than names. Using the IP address instead of a name removes some of the complexities of the setup and testing. Name resolution, for example, is taken out of the equation, thus simplifying the design.
To be reachable, the answering router must be assigned a public IP address to which packets are forwarded by the routing infrastructure of the Internet. If you have been assigned a static public IP address from an ISP or an Internet registry, this is typically not an issue. In some configurations, the answering router is actually configured with a private IP address and has a published static IP address by which it is known on the Internet. A network address translation (NAT) device between the Internet and the answering router translates the published and actual IP addresses of the answering router in packets to and from the answering router.
While the routing infrastructure might be in place, the answering router might be unreachable because of the placement of firewalls, packet filtering routers, network address translators, security gateways, or other types of devices that prevent packets from either being sent to or received from the answering router computer. Therefore, if the answering router is going to be protected by any of these options, you need to ensure that proper configurations and testing can be done to ensure proper packet handling by these network devices.
Typcially there are three approaches to using a firewall with a VPN router:
The VPN router is attached directly to the Internet, and the firewall is between the VPN router and the site.
In this configuration, the VPN router must be configured with packet filters that allow only VPN traffic in and out of its Internet interface. The firewall can be configured to allow specific types of intersite traffic.
The firewall is attached to the Internet, and the VPN router is between the firewall and the site.
In this configuration, both the firewall and the VPN router are attached to a network segment known as the perimeter network (also known as a demilitarized zone (DMZ) or a screened subnet). Both the firewall and the VPN router must be configured with packet filters that allow only VPN traffic to and from the Internet. Figure 8-1 shows this configuration.
The firewall and VPN server are the same entity, as is the case with Microsoft Internet Security and Acceleration Server (ISA Server). In this case, the same server handles both functions.
In this configuration, you can assume the same options as in step number 2, but it is important to read the firewall documentation as to how and what firewall ruleset will be automatically plumbed for you. For instance, ISA will open the PPTP or L2TP/IPSec ports for you, but you need to make sure that all Routing and Remote Access service IP filters are configured as well and that they match the ISA firewall filters—otherwise, your traffic will be blocked.
For the details of configuring packet filters for the VPN router and the firewall for all three of these configurations, see Appendix B.
Consider the following when configuring your Internet infrastructure for site-to-site VPN connections:
Wherever possible, configure your demand-dial interfaces with the IP addresses of answering routers. If you are using names, ensure that the DNS names of your answering routers are resolvable by placing an appropriate DNS record in either your Internet DNS server or the DNS server of your ISP. Test the resolvability by using the Ping tool to ping the name of each of your answering routers. Because of packet filtering of Ping responses, the result of the Ping command might be a “Request timed out” message, but check to ensure that the name specified was resolved by the Ping tool to the correct IP address. A common implementation practice used when the VPN server is the same server as the firewall is called stealthing. With stealthing, all direct communications with the firewall are dropped and the firewall is made to look as if it is not there. If you are stealthing your firewall, be sure to make exception rules for the VPN traffic.
Ensure that the IP addresses of your answering routers are reachable from the Internet by using the Ping tool to ping the name or address of your answering router with a 5-second timeout (using the -w command line option) when directly connected to the Internet. If you see a “Destination unreachable” message, the answering router is not reachable.
Configure packet filtering for PPTP traffic, L2TP/IPSec traffic, or both types of traffic on the appropriate firewall and answering router interfaces connecting to the Internet and the perimeter network. The Routing And Remote Access Server Setup Wizard automatically configures the correct set of packet filters when you select the Remote Access (Dial-Up Or VPN) configuration. Use the default remote access policy, individual filters are also plumbed for each client address assigned. If you are using more than 500 connections concurrently, consider disabling the default IP filters option for better performance, but remember not to remove the base protocol filters for the server itself. For more information, see Appendix B.
To authenticate the calling router that is attempting to create a PPP connection, Windows Server 2003 supports a wide variety of PPP authentication protocols, including:
Password Authentication Protocol (PAP)
Shiva Password Authentication Protocol (SPAP)
Challenge-Handshake Authentication Protocol (CHAP)
Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
MS-CHAP version 2 (MS-CHAP v2)
Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)
Extensible Authentication Protocol-Transport Level Security (EAP-TLS)
For PPTP connections, you must use MS-CHAP, MS-CHAP v2, or EAP-TLS. Only these three authentication protocols provide a mechanism to generate the same encryption key on both the calling router and the answering router. MPPE uses this encryption key to encrypt all PPTP data sent on the VPN connection. MS-CHAP and MS-CHAP v2 are password-based authentication protocols.
In the absence of user certificates, MS-CHAP v2 is highly recommended, as it is a stronger authentication protocol than MS-CHAP and provides mutual authentication. With mutual authentication, the answering router authenticates the calling router and the calling router authenticates the answering router. MS-CHAP provides only one-way authentication as opposed to mutual authentication.
If you must use a password-based authentication protocol, enforce the use of strong passwords on your network. Strong passwords are long (greater than 8 characters) and contain a random mixture of uppercase and lowercase letters, numbers, and symbols. An example of a strong password is f3L*q02~>xR3w#4o.
EAP-TLS is used in conjunction with a certificate infrastructure and user certificates. With EAP-TLS, the calling router sends a user certificate for authentication and the authenticating server (the answering router or RADIUS server) sends a computer certificate for authentication. This is the strongest authentication method, as it does not rely on passwords. If the authenticating server is a Windows Server 2003 VPN router or an IAS server, EAP-TLS is available only if the authenticating server is a member of an Active Directory domain.
You can use third-party certificate authorities (CAs) for EAP-TLS certificates. For more information, see Appendix C.
For L2TP/IPSec connections, any PPP authentication protocol can be used because the user authentication occurs after the calling router and answering router have established a secure channel of communication known as an IPSec security association (SA). However, the use of either MS-CHAP v2 or EAP-TLS is the recommended authentication protocol for all remote communications. PAP and CHAP are not recommended by Microsoft for use and are provided only for legacy support issues. SPAP is a legacy-supported protocol used for connections with Shiva-based modem servers and is also not recommended for use.
Consider the following when choosing an authentication protocol for VPN connections:
If you are using a certificate infrastructure that issues user certificates, use the EAP-TLS authentication protocol for both PPTP and L2TP/IPSec connections. Windows NT 4.0 RRAS routers do not support EAP-TLS.
If you must use a password-based authentication protocol, use MS-CHAP v2 and enforce strong passwords using Group Policy. MS-CHAP v2 is supported by computers running Windows Server 2003, Windows 2000, and Windows NT 4.0 with RRAS and Service Pack 4 and later.
Microsoft implements industry-standard, Request-for-Comments (RFC)-compliant protocols for implementation on Windows operating systems. Windows Server 2003 includes support for two PPP-based site-to-site VPN protocols:
Point-to-Point Tunneling Protocol
Layer Two Tunneling Protocol with IPSec
Several VPN vendors use IPSec tunnel mode for site-to-site communications. IPSec tunnel mode requires the use of a technology named XAUTH/MODCFG, which has been rejected by the Internet Engineering Task Force (IETF) because it is susceptible to man-in-the-middle attacks. Also, all vendors who support it have implemented proprietary versions of XAUTH/MODCFG that require their own third-party clients and are therefore not interoperable with each other. To promote full interoperability with all VPN services and adhere to strict IETF RFC standards, Microsoft has implemented the only ratified IPSec VPN protocol—L2TP/IPSec. No approved IPSec VPN protocols are available today other than L2TP/IPSec.
Introduced in Windows NT 4.0, PPTP leverages PPP user authentication and MPPE to encapsulate and encrypt IP traffic. When MS-CHAP v2 is used with strong passwords, PPTP is a secure VPN technology. For nonpassword-based authentication, EAP-TLS can be used in Windows Server 2003 to support user certificates. PPTP is widely supported, easily deployed, and can be used across most NATs.
L2TP leverages PPP user authentication and IPSec Encapsulating Security Payload (ESP) transport mode to encapsulate and encrypt IP traffic. This combination, known as L2TP/IPSec, uses certificate-based computer identity authentication to create the IPSec security association in addition to PPP-based user authentication. L2TP/IPSec provides data integrity and data authentication for each packet. However, L2TP/IPSec requires a certificate infrastructure to allocate computer certificates and is supported by Windows Server 2003 VPN routers and other third-party VPN routers. L2TP/IPSec requires NAT traversal (NAT-T)–capable endnodes to go across a NAT. Windows Server 2003 has NAT-T capability, and all client operating systems can use NAT-T with the proper download client for Microsoft Windows 98, Microsoft Windows Me, and Windows NT 4.0. Windows XP and Windows 2000 Professional can use NAT-T by obtaining the proper update from Windows Update or in the future with the installation of Service Pack 2 or Service Pack 5, respectively.
Consider the following when deciding between PPTP and L2TP for site-to-site VPN connections:
PPTP can be used with Windows Server 2003, Windows 2000, and Windows NT 4.0 with RRAS. PPTP does not require a certificate infrastructure to issue computer certificates.
PPTP-based VPN connections provide data confidentiality—that is, captured packets cannot be interpreted without the encryption key. PPTP VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data authentication (proof that the data was sent by the authorized computer).
PPTP-based calling routers can be located behind a NAT because most NATs include a NAT editor that knows how to properly translate PPTP tunneled data. For example, the Internet connection sharing (ICS) feature of Network Connections and the NAT/Basic Firewall routing protocol component of the Windows Server 2003 Routing and Remote Access service include a NAT editor that translates PPTP traffic from PPTP clients located behind the NAT. Answering routers cannot be behind a NAT unless there are multiple public IP addresses and a one-to-one mapping of a public IP address to the private IP address of the answering router. Also, if there is only one public address, answering routers can be behind a NAT if the NAT is configured to translate and forward the PPTP tunneled data to the VPN router. Most NATs using a single public IP address, including ICS and the NAT routing protocol component, can be configured to allow inbound traffic based on IP addresses and TCP and UDP ports. However, PPTP tunneled data does not use TCP or UDP headers. Therefore, an answering router cannot be located behind a computer using ICS or the NAT routing protocol component when using a single IP address.
L2TP/IPSec-based VPN routers cannot be behind a NAT unless both the calling and answering routers support IPSec NAT-T. Only Windows Server 2003 supports IPSec NAT-T for site-to-site VPN connections.
L2TP/IPSec can be used only with Windows Server 2003, Windows 2000, and third-party VPN routers and supports computer certificates as the default authentication method for IPSec. Computer certificate authentication requires a certificate infrastructure to issue computer certificates to the answering router computer and all calling router computers.
By using IPSec, L2TP-based VPN connections provide data confidentiality, data integrity, data authentication, and replay protection.
PPTP and L2TP is not an either/or choice. By default, a Windows Server 2003 VPN router supports both PPTP and L2TP connections simultaneously. You can use PPTP for some site-to-site VPN connections (from calling routers that are running Windows Server 2003, Windows 2000, or Windows NT 4.0 with RRAS and do not have an installed computer certificate) and L2TP for other site-to-site VPN connections (from calling routers running Windows Server 2003 or Windows 2000 that have an installed computer certificate).
If you are using both PPTP and L2TP, you can create separate remote access policies that define different connection parameters for PPTP and L2TP connections.
The network infrastructure of the site is an important element of VPN design. Calling routers cannot forward packets without the proper routing infrastructure in place.
If the calling router is configured with the IP addresses of DNS or WINS servers, DNS and WINS server IP addresses are not requested from the answering router during the PPP connection negotiation. If the calling router is not configured with the IP addresses of DNS and WINS servers, DNS and WINS servers are requested. The answering router never requests DNS and WINS server IP addresses from the calling router.
Unlike Windows Server 2003, Windows 2000, and Windows XP remote access clients, the calling router does not send a DHCPInform message to the answering router to discover additional TCP/IP configuration information.
By default, the calling router does not register itself with the DNS or WINS servers of the answering router. To change this behavior, set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rasman\PPP\ControlProtocols\BuiltIn\RegisterRoutersWithNameServers to 1.
Each VPN router is an IP router and, as such, must be properly configured with the set of routes that makes all locations reachable. Specifically, each VPN router needs the following:
A default route that points to a firewall or router directly connected to the Internet. This route makes all locations on the Internet reachable. Without a default route, there would be no way to route “unknown” traffic to the Internet and all “unknown” address packets would be dropped at the VPN router.
One or more routes that summarize the addresses used within the site of the VPN router that point to a neighboring site router. These routes make all locations within the site of the VPN router reachable from the VPN router. Without these routes, all hosts in the site not connected to the same subnet as the VPN router are unreachable. There is no way for the far end to know what subnets are beyond the VPN router’s own subnet. Because there are no dynamic routing updates passing over the link, this information needs to be manually provided. If there are subnets that the remote site should not be accessing, simply to exclude these subnets from the set of static routes and they will be unreachable.
To add a default route that points to the Internet, configure the Internet interface with a default gateway and then manually configure the site interface without a default gateway.
To add site routes to the routing table of each VPN router, you can:
Add static routes using the Routing And Remote Access snap-in. You do not necessarily have to add a route for each subnet in your site. At a minimum, you just need to add the routes that summarize all the possible addresses in your site. For example, if your site uses portions of the private address space 10.0.0.0/8 to number its subnets and hosts, you do not have to add a route for each subnet. Just add a route for 10.0.0.0 with the subnet mask 255.0.0.0 that points to a neighboring router on the site subnet to which your VPN router is attached. This practice is known as route summarization. Route summarization allows you to keep the routing tables small, and thus speeds up forwarding of packets through the routers and decreases the amount of time needed for network convergence.
If you are using the RIP or OSPF routing protocol in your site, you can add and configure the RIP or OSPF routing protocol components of the Routing and Remote Access service so that the VPN router participates in the propagation of routing information as a dynamic router.
If your site has only a single subnet, no further configuration is required and dynamic routing protocols are not necessary. Use dynamic routing only on demand-dial links when absolutely called for. Static routing is the recommended solution to prevent the demand-dial connection from flapping, a term used to describe when a connection goes up and down and causes routing updates to continually occur. Flapping is especially likely to happen when the Internet connections are not stable.
When a site-to-site VPN connection is made, each router sends traffic using a logical interface that corresponds to the PPTP or L2TP port of the connection. During the PPP negotiation, IP addresses might be assigned to these logical interfaces. Ensuring the reachability of the logical interfaces of VPN routers depends on how you configure each VPN router to obtain IP addresses for remote access clients and calling routers. The IP addresses assigned to VPN routers as they connect can be from the following sources:
An on-subnet address range, which is an address range of the site subnet to which the VPN router is attached. An on-subnet address range is used whenever the VPN router is configured to use DHCP to obtain IP addresses and when the manually configured ranges of IP addresses are within the range of addresses of the attached subnet.
An off-subnet address range, which is an address range that represents a different subnet that is logically attached to the VPN router. An off-subnet address range is used whenever the VPN router is manually configured with a range of IP addresses for a separate subnet.
If you are using an on-subnet address range, no additional routing configuration is required, as the VPN router acts as a proxy for all packets destined to the logical interfaces of the other connected VPN routers. Routers and hosts on the VPN router subnet forward packets destined to the logical interfaces of connected VPN routers to the VPN router, and the VPN router relays them to the appropriate connected VPN routers.
If you are using an off-subnet address range, you must add the route or routes that summarize the off-subnet address range to the site routing infrastructure so that traffic destined to the logical interfaces of connected VPN routers are forwarded to the VPN router and then sent by the VPN router to the appropriate connected VPN router. To provide the best summarization of address ranges for routes, use route summarization techniques to choose address ranges that can be expressed using a single prefix and subnet mask. For more information, see the “Expressing an IP address range with a mask” topic in Windows Server 2003 Help And Support.
You can add the routes that summarize the off-subnet address range to the routing infrastructure of the site by using the following techniques:
Add static routes to the neighboring router for the off-subnet address ranges that point to the VPN router’s site interface. Configure the neighboring router to propagate this static route to other routers in the site by using the dynamic routing protocol used in your site.
If your site consists of a single subnet, you must either configure each site host for persistent routes of the off-subnet address range that point to the VPN router’s site interface or configure each site host with the VPN router as its default gateway. Because routing for off-subnet address ranges requires additional host configuration, you should use an on-subnet address pool for a small office/home office (SOHO) network consisting of a single subnet.
Consider the following when configuring the routing infrastructure for site-to-site VPN connections:
Configure the Internet interface of the VPN router with a default gateway. Do not configure the site interface of the VPN router with a default gateway.
Add static IP routes to the VPN router that summarize the addresses used in the site in which the VPN router is located. Alternately, if you use either RIP or OSPF as your dynamic routing protocol, configure and enable RIP or OSPF on the VPN router. If you use a routing protocol other than RIP or OSPF—such as Interior Gateway Routing Protocol (IGRP) or Enhanced Interior Gateway Protocol (EIGRP), which are both Cisco proprietary protocols—configure the neighboring router for RIP or OSPF on the interface connected to the subnet containing the VPN router, configure IGRP or EIGRP on all other interfaces, and then set up route redistribution between the protocols.
Configure the VPN router with an on-subnet address range by obtaining IP addresses through DHCP or by manually configuring on-subnet address pools.
The AAA infrastructure exists to provide authentication of connections and log those connections so that the security of the network can be monitored. A strong AAA infrastructure is vital to the security of any remote access or site-to-site enabled network. The AAA infrastructure does the following:
Authenticates the credentials of calling routers
Authorizes the VPN connection
Records the VPN connection creation and termination for accounting purposes
The AAA infrastructure consists of:
The answering router computer
RADIUS server computers
As previously discussed, a Windows Server 2003 answering router can be configured with either Windows or RADIUS as its authentication or accounting provider. RADIUS provides a centralized AAA service when you have multiple answering routers and remote access VPN servers or a mix of heterogeneous dial-up and VPN equipment.
When you configure Windows as the authentication provider, the answering router performs the authentication of the VPN connection by communicating with a domain controller using a secure remote procedure call (RPC) channel and it performs authorization of the connection attempt through the dial-in properties of the user account and locally configured remote access policies.
When you configure RADIUS as the authentication provider, the answering router relies on a RADIUS server to perform both the authentication and authorization. When a VPN connection is attempted, the answering router sends the calling router credentials and other connection parameters to the configured RADIUS server in a RADIUS Access-Request message. If the connection attempt is both authenticated and authorized, the RADIUS server sends back a RADIUS Access-Accept message. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends back a RADIUS Access-Reject message.
When you configure Windows as the accounting provider, the answering router logs VPN connection information in a local log file (SystemRoot\System32\LogFiles\Logfile.log by default and it may change per the timestamp if multiple logs are present) based on settings on the Settings tab of the properties of the Local File object in the Remote Access Logging folder in the Routing And Remote Access snap-in. By default, all types of logging are disabled. Windows Server 2003 also supports the sending of connection accounting information to a structured query language (SQL) server database using the new SQL-XML logging feature.
When you configure RADIUS as the authentication provider, the answering router sends RADIUS accounting messages for VPN connections on a RADIUS server, which records the accounting information.
If you are using RADIUS and a Windows domain as the user account database for which to verify user credentials and obtain dial-in properties, Microsoft recommends using IAS, included as an optional networking component in Windows Server 2003 and Windows 2000 Server. IAS is a full-featured RADIUS server that is tightly integrated with Active Directory and the Routing And Remote Access service.
When IAS is used as the RADIUS server:
IAS performs the authentication of the VPN connection by communicating with a domain controller using a secure RPC channel. IAS performs authorization of the connection attempt through the dial-in properties of the user account and remote access policies configured on the IAS server.
You should use IPSec policy filters to encrypt traffic from the VPN server to the RADIUS services to ensure credentials are not compromised, because the RADIUS server is not physically attached to the VPN server.
IAS logs all RADIUS accounting information in a local log file (SystemRoot\System32\LogFiles\Logfile.log by default and it may change per the timestamp if multiple logs are present) based on settings configured on the properties of the Local File object in the Remote Access Logging folder in the Internet Authentication Service snap-in. IAS in Windows Server 2003 also supports the sending of connection accounting information to an SQL server.
IAS for Windows Server 2003 can also be used as a RADIUS proxy. A RADIUS proxy allows RADIUS traffic to be sent via IAS to another authoritative third-party RADIUS service. For more information, see Windows Server 2003 Help And Support.
Remote access policies are an ordered set of rules that define how connections are either accepted or rejected. For connections that are accepted, remote access policies can also define connection restrictions. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. Connection attempts are evaluated against the remote access policies in order to determine whether the connection attempt matches all the conditions of each policy. If the connection attempt does not match all the conditions of any policy, the connection attempt is rejected.
If a connection matches all the conditions of a remote access policy and is granted remote access permission, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.
Remote access policies consist of the following elements:
Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If there are multiple conditions, all the conditions must match the settings of the connection attempt in order for it to match the policy. For VPN connections, you commonly use the following conditions:
NAS-Port-Type. By setting the NAS-Port-Type condition to Virtual (VPN), you can specify all VPN connections.
Tunnel-Type. By setting the Tunnel-Type to Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP), you can specify different policies for PPTP and L2TP connections.
Windows-Groups. By setting the Windows-Groups to the appropriate groups, you can specify access parameters based on group membership.
You can use the permission setting to either grant or deny remote access for the connection attempt if the remote access permission of the user account is set to Control Access Through Remote Access Policy. Otherwise, the remote access permission setting on the user account determines the remote access permission.
A remote access policy profile is a set of properties that are applied to a connection when it is authorized. For VPN connections, you can use the following profile settings:
Dial-in constraints can be used to define how long the connection can exist or be idle before being terminated by the calling or answering router.
Authentication settings can define which authentication protocols the calling router can use when sending its credentials and the configuration of EAP types, such as EAP-TLS.
Encryption settings can define whether encryption is required and, if so, the encryption strength. For encryption strengths, Windows Server 2003 supports Basic (40-bit MPPE for PPTP and 56-bit Data Encryption Standard [DES] for L2TP/IPSec), Strong (56-bit MPPE for PPTP and 56-bit DES for L2TP/IPSec), or Strongest (128-bit MPPE for PPTP and 3DES for L2TP/IPSec). To use the 2048-bit Diffie-Hellman algorithm if you are running Windows Server 2003, you must create a registry key. To do this, follow these steps:
Click Start, and then click Run.
In the Open box, type regedit, and then click OK.
Locate and then click the following registry subkey:
On the Edit menu, point to New, and then click DWORD Value.
Type NegotiateDH2048, and then press ENTER.
Right-click NegotiateDH2048, and then click Modify.
In the Value data box, type 1, and then click OK.
On the Registry menu, click Exit.
For example, you can create a Windows group named VPNRouters whose members are the user accounts of all calling routers. Next, you create a policy using the New Remote Access Policy Wizard that specifies a VPN connection using the VPNRouters group. Using the Wizard, you can also select a specific authentication method and encryption strength.
IP packet filters on the IP tab of the profile settings of a remote access policy apply only to remote access VPN connections. They have no effect on demand-dial connections.
Windows NT 4.0 domains, mixed-mode Active Directory domains, and native-mode Active Directory domains contain the user accounts and groups used by the Routing And Remote Access service and IAS to authenticate and authorize VPN connection attempts.
User accounts contain the user name and a form of the user’s password that can be used for validation of the calling router’s user credentials. Additional account properties determine whether the user account is enabled or disabled, locked out, or permitted to log on only during specific hours. If a user account is disabled, locked out, or not permitted to log on during the time of the VPN connection, the site-to- site VPN connection attempt is rejected. Additionally, if the user account of the calling router is configured to change the password at the next logon, the site-to-site VPN connection attempt will fail because changing the password while attempting to make the connection is an interactive process. Demand-dial routers need to be able to make connections as needed without requiring human intervention. Therefore, all user accounts for calling routers must be configured with the User Must Change Password At Next Logon check box cleared and the Password Never Expires check box selected for the account options on the Account tab on the properties of the user account. When you create dial-in accounts with the Demand- Dial Interface Wizard, these account settings are automatically configured.
You should use a separate user account for each site that contains a calling router. Each user account should have a name that matches a demand-dial interface configured on the answering router. When you create dial-in accounts with the Demand-Dial Interface Wizard, this one-to-one relationship between user accounts used by calling routers in separate sites and demand-dial interfaces is automatically created.
User accounts also contain dial-in settings. The dial-in setting most relevant for VPN connections is the Remote Access Permission setting, which has the following values:
Control Access Through Remote Access Policy
The Allow Access and Deny Access settings explicitly allow or deny, respectively, remote access and are equivalent to the remote access permission setting of Windows NT 4.0 domain accounts. When you use the Control Access Through Remote Access Policy setting, the remote access permission is determined by the remote access permission setting of the matching remote access policy. If the user account is in a mixed-mode domain, the Control Access Through Remote Access Policy setting is not available and you must manage remote access permission on a per-user basis. If the user account is in a native-mode domain, the Control Access Through Remote Access Policy setting is available and you can manage remote access permission on a per-user basis or by using groups. When a dial-in account is created with the Demand-Dial Interface Wizard, the remote access permission is set to Allow Access.
When using groups to manage access, you can use your existing groups and create remote access policies that either allow or reject access or restrict access based on the group name. For example, the Employees group might have no VPN remote access restrictions; however, the Contractors group might be allowed to create VPN connections only during business hours. Alternately, you can create groups based on the type of connection being made. For example, you can create a VPNRouters group and add as members all the user accounts allowed to create VPN connections.
With one-way initiated connections, one router is always the answering router and one router is always the calling router. The answering router accepts the connection, and the calling router initiates the connection. One-way initiated connections are well suited to a spoke-and-hub topology, where the branch office router is the only router that initiates the connection.
To simplify configuration for one-way initiated connections, user accounts on a stand-alone Windows Server 2003 system or in a native-mode Active Directory domain support the configuration of static routes. The static routes are automatically added to the routing table of the VPN router when a VPN connection using the user account is made. If the VPN router is participating in dynamic routing for the site, the routes are propagated to the other routers in the site using routing protocols such as RIP and OSPF. To configure static routes on user accounts, select the Apply Static Routes check box on the Dial-In tab on the properties of a user account, and then add static routes.
To use static routes on the user account, configure the calling router normally. On the answering router, all you have to do is create a user account that is used by the calling router and configure static routes that correspond to the calling router’s site. Because there is no demand-dial interface on the answering router with the same name as the user account of the calling router, the incoming VPN connection is determined to be a remote access connection. The static routes of the calling router’s user account are added to the VPN router’s routing table, and all traffic to the locations specified by the static routes is sent across the logical remote access connection to the calling router.
Static routes on the user account are applied to the answering router only when the incoming connection is a remote access VPN connection—that is, the user name in the credentials of the calling router does not match the name of a demand-dial interface on the answering router. Static routes on the user account are not applied when the incoming connection is a demand-dial connection.
Consider the following when configuring the AAA infrastructure for site-to-site VPN connections:
If you have multiple VPN routers and you want to centralize AAA service, or you have a heterogeneous mixture of dial-up and VPN equipment, use RADIUS servers and configure the VPN router for the RADIUS authentication and accounting providers. The new SQL-XML logging features of Windows Server 2003 IAS are excellent, centralizing all logging and auditing into one database for analysis.
If your user account database is a Windows domain, use IAS as your RADIUS server. If you use IAS, install IAS on a domain controller for best performance. Install at least two IAS servers for fail-over and fault tolerance of AAA services.
Whether the AAA infrastructure is configured locally or on an IAS server, use remote access policies to authorize VPN connections and specify connection constraints. For example, use remote access policies to grant access based on group membership, to enforce the use of encryption and a specific encryption strength, or specify the use of EAP-TLS.
For one-way initiated connections, you can configure the calling router normally and configure the answering router with a user account that contains the static routes of the calling router’s site.
Sensitive fields of RADIUS messages, such as the user password and encryption keys, are encrypted with the RADIUS shared secret configured on the VPN router and the RADIUS server. Make the shared secret a long (22 characters or longer), random sequence of letters, numbers, and symbols and change it often to protect your RADIUS traffic. An example of a strong shared secret is 8d#>9fq4bV)H7%a3@dW9.>. To further protect RADIUS traffic, use IPSec policies to provide data confidentiality for all traffic using the RADIUS User Datagram Protocol (UDP) ports (1812 and 1645 for RADIUS authentication traffic, and 1813 and 1646 for RADIUS accounting traffic).
To perform certificate-based authentication for L2TP connections and user certificate-based authentication for site-to-site VPN connections using EAP-TLS, a certificate infrastructure must be in place to issue the proper certificates to submit during the authentication process and to validate the certificate being submitted.
If you manually configure the certificate authentication method for a rule of an IPSec policy in Windows Server 2003, you can specify the list of root CAs from which a certificate is accepted for authentication. For L2TP/IPSec connections, the IPSec rule for L2TP traffic is automatically configured and the list of root CAs is not configurable. Instead, each computer in the L2TP/IPSec connection sends a list of root CAs to its IPSec peer from which it accepts a certificate for authentication. The root CAs in this list correspond to the root CAs that issued certificates that are stored in the computer certificate store. For example, if Computer A was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPSec peer during main mode negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the IPSec peer, Computer B, does not have a valid certificate in its computer certificate store issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.
Ensure one of the following events occurred before attempting an L2TP connection:
Both the calling router and answering router were issued computer certificates from the same CA.
Both the calling router and answering router were issued computer certificates from CAs that follow a valid certificate chain up to the same root CA.
In general, the calling router must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the answering router trusts. Additionally, the answering router must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the calling router trusts.
A single CA commonly issues computer certificates to all computers in an organization. Because of this, all computers within the organization have computer certificates from a single CA and request certificates for authentication from the same single CA.
For information about installing computer certificates on VPN routers for L2TP connections, see Chapter 9.
The Windows Server 2003 Routing and Remote Access service supports the configuration of a preshared key for IPSec authentication of L2TP/IPSec connections. To configure the answering router, select Allow Custom IPSec Policy For L2TP Connection from the Security tab in the properties of a VPN router in the Routing And Remote Access snap-in, and then type the preshared key. To configure the calling router, click IPSec Settings on the Security tab in the properties of a demand-dial interface, and then type the preshared key. However, preshared key authentication for L2TP/IPSec connections is not secure and is not recommended, except as an interim measure while deploying a certificate infrastructure or to connect to third-party VPN routers that do not support certificate authentication.
To perform EAP-TLS authentication for a site-to-site VPN connection in Windows Server 2003:
The calling router must be configured with a user certificate to submit during the EAP-TLS authentication process.
The authenticating server must be configured with a computer certificate to submit during the EAP-TLS authentication process. The authenticating server is either the answering router (if the answering router is configured to use the Windows authentication provider) or a RADIUS server (if the answering router is configured to use the RADIUS authentication provider).
EAP-TLS authentication is successful when the following conditions are met:
The calling router submits a valid user certificate that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the answering router trusts.
The authenticating server submits a valid computer certificate that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the calling router trusts.
The user certificate of the calling router contains the Client Authentication enhanced key usage (object identifier (OID)=“188.8.131.52.184.108.40.206.2”).
The computer certificate of the authenticating server contains the Server Authentication enhanced key usage (OID=“220.127.116.11.18.104.22.168.1”).
For a Windows Server 2003 CA, a Router (Offline Request) certificate, which is a special type of user certificate for demand-dial connections, is created and mapped to an Active Directory user account. When the calling router attempts a VPN connection, the Router (Offline Request) certificate is sent during the connection negotiation process. If the Router (Offline Request) certificate is valid, it is used to determine the appropriate user account from which dial-in properties are obtained.
For information about configuring user and computer certificates for EAP-TLS authentication, see Chapter 9.
Consider the following when configuring the certificate infrastructure for site-to-site VPN connections:
To create L2TP/IPSec site-to-site VPN connections using computer certificate authentication for IPSec, you must install a certificate in the Local Computer certificate store of the calling router and the answering router.
To authenticate VPN connections using EAP-TLS, the calling router must have a user certificate installed and the authenticating server (either the answering router or the RADIUS server) must have a computer certificate installed.
To install a computer or user certificate on a computer across the Internet, make a PPTP connection using a password-based authentication protocol such as MS-CHAP v2. After connecting, use the Certificate Manager snap-in or Internet Explorer to request the appropriate certificates. Once the certificates are installed, disconnect and then reconnect with the appropriate VPN protocol and authentication method. An example of this situation is a computer at a remote branch office without the certificates needed to make L2TP/IPSec or EAP-TLS-authenticated connections. This process is known as bootstrapping or provisioning.