Components of Windows Server 2003 Site-to-Site VPNs
Updated: October 7, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Figure 2 shows the components of Windows Server 2003 site-to-site virtual private networks.
Figure 2: Components of Windows Server 2003 site-to-site VPNs
The major components are:
- VPN routers
- Internet infrastructure
- Intranet infrastructure
- Authentication, authorization, and accounting (AAA) infrastructure
- Certificate infrastructure
VPN Routers
VPN routers either initiate or receive VPN-based demand-dial connections and consist of the following components:
- 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. Virtual private network (VPN) ports are logical ports.
- 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, the addressing used to create the connection (an IP address or domain name), authentication methods, encryption requirements, and authentication credentials.
For two-way initiated connections, a demand-dial interface configured on the answering router represents the PPP connection to the calling router. 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. To authenticate the calling router, the credentials of the calling router 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, then 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. - Routes. To forward traffic across a site-to-site VPN connection, IP routes in the routing tables of the VPN routers is 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 of 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 an administrator action or 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 and one network adapter connected to the intranet.
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 that 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 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. Alternately, the VPN server can initiate a VPN connection to another VPN router.
Note Microsoft recommends the choice of
Remote access (dial-up or VPN) over
Secure connection between two private networks in the Routing and Remote Access Server Setup Wizard 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 only creates 5 PPTP and 5 L2TP ports.
When you select the
Remote access (dial-up or VPN) option in the Routing and Remote Access Server Setup Wizard:
- 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. The interface that you select will be automatically configured with packet filters that allow only PPTP and L2TP-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. If you want to use the VPN server computer as a network address translator (NAT), Web server, or other function, see Appendix B.
- Next, if you have multiple network adapters that are connected to the intranet, you are prompted to select an interface over which DHCP, DNS, and WINS configuration is obtained.
- 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.
- 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.
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.
- The 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.
With Windows Server 2003, Web Edition, and Windows Server 2003, Standard Edition, you can create up to 1,000 Point-to-Point Tunneling Protocol (PPTP) ports, and you can create up to 1,000 Layer Two Tunneling Protocol (L2TP) ports. However, Windows Server 2003, Web Edition, can accept only one virtual private network (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.
Installing a Certificate on a VPN Router
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 computer 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 Certificate infrastructure in this paper.
Design Points: Configuring the VPN Router
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 for the Routing and Remote Access Server Setup Wizard, rename the connections with their purpose or role using Network Connections. For example, rename the connection connected to the Internet, default name Local Area Connection 2, to Internet. - Can the VPN router be a DHCP client?
The VPN router must have a manual TCP/IP configuration for its Internet interface. While technically possible, it is not recommended that the VPN router be a DHCP client for its intranet interface(s). Due to the routing requirements of the VPN router, manually configure an IP address, subnet mask, DNS server(s), and WINS server(s), but do not configure a default gateway.
Note that it is possible for the VPN router to 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, then, for the default configuration of the VPN router, the scope should contain at least 307 addresses (50 computers + 128 PPTP clients + 128 L2TP clients + 1 address for the VPN router). 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 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 is known as an unnumbered connection. While Windows Server 2003 VPN routers support unnumbered connections, the 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 Site network infrastructure in this paper. - What is the authentication and accounting provider?
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.
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. - Are you making L2TP/IPSec connections?
If so, you must install a computer certificate on both the calling router and answering router computers. - 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 (either the answering router computer [if the answering router is configured for the Windows authentication provider] or the RADIUS server [if the answering router 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 only available if the authenticating server is a member of an Active 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 output IP packet filters with the Transmit all packets except those that meet the criteria below option, then 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 output IP packet filters with the Drop all packets except those that meet the criteria below option, then 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. Alternately, you can clear the Remote access server checkbox on the General tab on the properties of the VPN server. - Do you need to install a computer certificate?
If the VPN router is supporting L2TP/IPSec connections 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 the VPN router is a calling router using the EAP-TLS authentication protocol, you must install a user certificate. For more information, see "Certificate infrastructure" in this paper. - 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 accounts 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 Remote Access Policies in this paper. - 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 Authentication 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 "Deploying a PPTP-based Site-to-Site VPN Connection" and "Deploying an L2TP/IPSec-based Site-to-Site VPN Connection" in this paper.
Internet Network Infrastructure
To create a site-to-site VPN connection to an answering router across the Internet:
- 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.
Answering Router Name Resolvability
While it is possible to configure demand-dial interfaces with the names of the answering routers to which a connection is made, it is recommended that you use IP addresses rather than names. If you use a name and the name resolves to the public IP address of the answering router, traffic sent to services running on the VPN router are sent in clear text across the Internet.
Answering Router Reachability
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 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 due to 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.
VPN Routers and Firewall Configuration
There are two 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 only allow VPN traffic in and out of its Internet interface. The firewall can be configured to allow specific types of inter-site 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 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 2 shows this configuration.
For the details of configuring packet filters for the VPN router and the firewall for both of these configurations, see Appendix A.
Design Points: Answering Router Accessibility from the Internet
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 either placing an appropriate DNS record in 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. Due to packet filtering, the result of the ping command may be "Request timed out", but check to ensure that the name specified was resolved by the Ping tool to the correct IP address.
- 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" error 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 correct set of packet filters is automatically configured by the Routing and Remote Access Server Setup Wizard when you select the Remote access (dial-up or VPN) configuration. For more information, see Appendix A.
Authentication Protocols
To authenticate the calling router who 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 Protocol (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.
Note 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 upper and lower case letters, numbers, and punctuation. An example of a strong password is f3L*02~>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 only available if the authenticating server is a member of an Active Directory domain.
Note You can use third-party CAs for EAP-TLS certificates. For more information, see Appendix E in the white paper titled "Virtual Private Networking with Windows Server 2003: Deploying Remote Access VPNs."
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 recommended.
Design Point: Which Authentication Protocol to 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 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.
VPN Protocols
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
Point-to-Point Tunneling Protocol
Introduced in Windows NT 4.0, PPTP leverages Point-to-Point Protocol (PPP) user authentication and Microsoft Point-to-Point Encryption (MPPE) to encapsulate and encrypt IP traffic. When MS-CHAP v2 is used with strong passwords, PPTP is a secure VPN technology. For non-password-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 network address translators (NATs).
Layer Two Tunneling Protocol With IPSec
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.
Design Point: PPTP or L2TP?
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 version 4.0 with RRAS. PPTP does not require a certificate infrastructure to issue computer certificates.
- PPTP-based VPN connections provide data confidentiality (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 Dial-up 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 there is a one-to-one mapping of a public IP address to the private IP address of the answering router or, if there is only one public address, 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 Traversal (NAT-T). IPSec NAT-T for site-to-site VPN connections is only supported by Windows Server 2003. However, Microsoft recommends that answering routers not be placed behind NATs. For more information, see IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators at IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators.
- L2TP/IPSec can only be used 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.
Site Network Infrastructure
The network infrastructure of the site is an important element of VPN design. Without proper design, calling routers are unable to obtain proper IP addresses, and packets cannot be exchange between computers in the different sites.
Name Resolution
If the calling router is configured with the IP addresses of Domain Name System (DNS) or Windows Internet Name Service (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\Servic es\Rasman \PPP\ControlProtocols\BuiltIn\RegisterRoutersWithN ameServers to 1.
Routing
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 of the locations on the Internet reachable. - 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 of the 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.
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.
- If you are using the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocols 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.
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:
- 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 pool(s) 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 pool of IP addresses for a separate subnet.
On-subnetAddressRange
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 the appropriate connected VPN routers.
Off-subnetAddressRange
If you are using an off-subnet address range, you must add the route(s) 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, choose address ranges that can be expressed using a single prefix and subnet mask. For more information, see the topic titled "Expressing an IP address range with a mask" 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 through the following:
- Add static routes to the neighboring router for the off-subnet address range that point to the VPN routers site interface. Configure the neighboring router to propagate this static route to other routers in the site using the dynamic routing protocol used in your site.
- If the VPN router is using OSPF and participating as a dynamic router, the VPN router must be configured as an autonomous system boundary router (ASBR) so that the static routes of the off-subnet address range are propagated to the other OSPF routers in the site.
If your site consists of a single subnet, then you must either configure each site host for persistent route(s) of the off-subnet address range that point to the VPN routers 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, it is recommended that you use an on-subnet address pool for a small office/home office (SOHO) network consisting of a single subnet.
Design Points: Routing Infrastructure
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), configure the neighboring router for RIP or OSPF on the interface connected to the subnet containing the VPN router, and then configure IGRP on all other interfaces.
- Configure the VPN router with an on-subnet address range by obtaining IP addresses through DHCP or by manually configuring on-subnet address pools.
AAA Infrastructure
The authentication, authorization, and accounting (AAA) infrastructure exists to:
- Authenticate the credentials of calling routers.
- Authorize the VPN connection.
- Record the VPN connection creation and termination for accounting purposes.
The AAA infrastructure consists of:
- The answering router computer
- RADIUS server computers
- Domain controllers
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 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) 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.
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 the Internet Authentication Service (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.
- IAS logs all RADIUS accounting information in a local log file (SystemRoot\System32\Logfiles\Logfile.log by default) 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 a SQL server.
IAS for Windows Server 2003 can also be used as a RADIUS proxy. For more information, see Windows Server 2003 Help and Support.
Remote Access Policies
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, trying to determine whether the connection attempt matches all of the conditions of each policy. If the connection attempt does not match all of 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:
- Conditions
- Permission
- Profile settings
Conditions
Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If there are multiple conditions, then all of 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 connection parameters based on group membership.
Permission
You can use the permission setting to either grant to 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.
Profile Settings
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 answering router, among others.
- 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 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), Strong (56-bit MPPE for PPTP and 56-bit DES for L2TP), or Strongest (128-bit MPPE for PPTP and 3DES for L2TP).
For example, you can create a Windows group called VPNRouters whose members are the user accounts of all calling routers. Then, you create a policy using the New Remote Access Policy Wizard that specifies VPN connection using the VPNRouters group. Using the Wizard, you can also select a specific authentication method and encryption strength.
Note IP packet filters on the
IP tab of the profile settings of a remote access policy only apply to remote access VPN connections. They have no effect on demand-dial connections.
Windows Domain User Accounts and Groups
Windows NT version 4.0 domains, mixed-mode Active Directory domains, and native-mode 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 users password that can be used for validation of the calling routers user credentials. Additional account properties determine whether the user account is enabled or disabled, locked out, or permitted to logon only during specific hours. If a user account is disabled, locked out, or not permitted to logon 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 login, 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 checkbox cleared and the
Password never expires checkbox 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:
- Allow access
- Deny access
- Control access through Remote Access Policy
The
Allow access and
Deny access settings explicitly allow or deny 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 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 has no VPN remote access restrictions, however, the Contractors group can only create VPN connections 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.
One-way Initiated Connections and Static Routes on the User Account
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 stand-alone Windows Server 2003 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. Static routes on user accounts are configured by selecting the
Apply static routes check box on the
Dial-in tab on the properties of a user account, and then adding 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 implied by the static routes is sent across the logical remote access connection to the calling router.
Note Static routes on the user account are only applied to the answering router when the incoming connection is a remote access VPN connection (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.
Design Points: AAA Infrastructure
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 a heterogeneous mixture of dial-up and VPN equipment, use RADIUS servers and configure the VPN router for the RADIUS authentication and accounting providers.
- 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 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 punctuation 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 UDP ports (1812 and 1645 for RADIUS authentication traffic and 1813 and 1646 for RADIUS accounting traffic).
Certificate Infrastructure
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.
Computer Certificates for L2TP/IPSec
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 certification authorities (CAs) from which a certificate is accepted for authentication. For L2TP 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 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 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 both 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 "Deploying an L2TP/IPSec-based Site-to-Site VPN Connection."
Note 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.
User and Computer Certificates for EAP-TLS 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 "1.3.6.1.5.5.7.3.2").
- The computer certificate of the answering router contains the Server Authentication enhanced key usage (object identifier "1.3.6.1.5.5.7.3.1").
For a Windows Server 2003 CA, a Router (Offline request) certificate, 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 "Deploying a PPTP-based Site-to-Site VPN Connection" and "Deploying an L2TP-based Site-to-Site VPN Connection."
Design Points: Certificate Infrastructure
Consider the following when configuring the certificate infrastructure for site-to-site VPN connections:
- In order to create L2TP/IPSec site-to-site VPN connections using computer certificate authentication for IPSec, you must install a certificate in the computer certificate store of the calling router and the answering router.
- In order 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.
LinkBack URL
About LinkBacks
Figure 1: The logical equivalent of a VPN connection
Note Using IPSec tunnel mode for site-to-site VPN connections is possible using computers running Windows Server 2003. Because the IPSec tunnel is not represented as a logical interface over which packets can be forwarded and received, routing protocols do not operate over IPSec tunnels. Because the configuration of IPSec tunnels for site-to-site VPN connections is vastly different, it is not discussed here. For more information, see article 252735, "How to Configure IPSec Tunneling in Windows 2000," in the Microsoft Knowledge Base.
Note Because the demand-dial connection is a point-to-point connection, the Gateway IP address field is not configurable. The adding of static routes can also be done during the creation of the demand-dial interface with the New Demand-Dial Interface Wizard.
Note Because the demand-dial connection is a point-to-point connection, the Gateway IP address field is not configurable. The adding of static routes can also be done during the creation of the demand-dial interface with the New Demand-Dial Interface Wizard.
Figure 3: The VPN router in front of the firewall 
Figure 4: The VPN router behind the firewall on the perimeter network 
Figure 5: The VPN router between two firewalls on the perimeter network 
Figure 6: The single-adapter VPN router configuration 
Note Tracing consumes system resources and should be used sparingly to help identify network problems. After the trace is captured or the problem is identified, you should immediately disable tracing. Do not leave tracing enabled on multiprocessor computers. Tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft support professionals or to network administrators who are very experienced with the Routing and Remote Access service. Tracing information can be saved as files and sent to Microsoft support for analysis.
