Export (0) Print
Expand All

Components of Windows Remote Access VPNs

Updated: October 7, 2005

Applies To: Windows Server 2003 with SP1

Figure 2 shows the components of Windows remote access virtual private networks.

Art Image

Figure 2: Components of Windows remote access VPNs

The major components are:

  • VPN clients

  • Internet infrastructure

  • VPN server

  • Intranet infrastructure

  • Authentication, authorization, and accounting (AAA) infrastructure

  • Certificate infrastructure

VPN Clients

The VPN client can be any computer that is capable of creating a PPTP connection using MPPE or L2TP connection using IPSec encryption. Table 1 lists the VPN-capable Microsoft operating systems.

Table 1 VPN-Capable Microsoft Operating Systems

 

VPN Tunneling Protocol Microsoft Operating System

PPTP

Windows Server 2003, Windows XP, Windows 2000, Windows NT version 4.0, Windows Millennium Edition, or Windows 98

L2TP/IPSec

Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0 Workstation, Windows Millennium Edition, and Windows 98 with Microsoft L2TP/IPSec VPN Client

Typical VPN clients are:

  • Laptop users who connect to the organization intranet to access e-mail and other resources while traveling.

  • Telecommuters who use the Internet to access organization resources from home.

  • Remote administrators who use the Internet to connect to an organization network and configure network or application services.

Microsoft VPN clients can configure VPN connections either manually or by using the Connection Manager components available in Windows Server 2003. To manually configure a Windows 2000 VPN client, use Make New Connection in the Network and Dial-up Connections folder to create a VPN connection to the IP address or DNS name of the VPN server on the Internet. To manually configure a Windows XP VPN client, use the New Connection Wizard in the Network Connections folder to create a VPN connection to the IP address or DNS name of the VPN server on the Internet.

Connection Manager

When scaling the configuration of VPN connections for an enterprise, there are the following problems:

  • The exact procedure to configure a VPN connection varies depending on the version of Windows running on the client computer.

  • To prevent configuration errors, it is preferable to have the information technology (IT) staff configure the VPN connection rather than end users.

  • A configuration method must be able to scale to hundreds or thousands of client computers in a large organization.

  • A VPN connection may need a double-dial configuration, where a user must dial the Internet first before creating a VPN connection with the organization intranet.

The solution to these issues of configuring VPN connections across an enterprise is Connection Manager. Connection Manager consists of the following:

  • Connection Manager

  • Connection Manager Administration Kit

  • Connection Point Services

Connection Manager

Connection Manager is a client dialer, included in Windows Server 2003, whose advanced features make it a superset of basic dial-up networking. Windows Server 2003 includes a set of tools that enables a network manager to deliver pre-configured connections to network users. These tools are the Connection Manager Administration Kit (CMAK) and Connection Point Services (CPS).

Connection Manager provides support for local and remote connections to your service using a network of access points, such as those available worldwide through ISPs. If your service requires secure connections over the Internet, you can also use Connection Manager to establish VPN connections to your service.

Connection Manager Administration Kit

A network administrator can tailor the appearance and behavior of a connection made with Connection Manager by using CMAK. With CMAK, an administrator can develop client dialer and connection software that allows users to connect to the network by using only the connection features that the administrator defines for them. Connection Manager supports a variety of features that both simplify and enhance implementation of connection support for you and your users, most of which can be incorporated using the Connection Manager Administration Kit Wizard.

CMAK allows you to build profiles customizing the Connection Manager installation package that you deliver to your customers, so that Connection Manager reflects the identity of your organization. It allows you to determine which functions and features you want to include and how Connection Manager appears to your customers. You can do this by using the Connection Manager Administration Kit Wizard to build custom service profiles.

For more information about CMAK and the configuration of connection manager service profiles, see Windows Server 2003 Help and Support.

Connection Point Services

Connection Point Services (CPS) enables you to automatically distribute and update custom phone books. These phone books contain one or more Point of Presence (POP) entries, with each POP supplying a telephone number that provides dial-up access to an Internet access point. The phone books give users complete POP information, so when they travel they can connect to different Internet access points rather than being restricted to a single POP.

Without the ability to update phone books (a task CPS handles automatically), users would have to contact their organization's technical support staff to be informed of changes in POP information and to reconfigure their client dialer software.

CPS has two components:

  1. Phone Book Administrator

    A tool used to create and maintain the phone book database and to publish new phone book information to the Phone Book Service.

  2. Phone Book Service

    A Microsoft Internet Information Services (IIS) extension that runs on Windows NT Server 4.0 or later (with IIS). Phone Book Service automatically checks subscribers' or corporate employees' current phone books and, if necessary, downloads a phone book update.

For more information about CPS and the configuration of phone books, see Windows Server 2003 Help and Support.

Single Sign-on

Single sign-on is the capability that allows a remote access user to create a remote access connection to an organization and logon to the organization's domain by using the same set of credentials. For a domain-based infrastructure, the user name and password or smart card is used for both authenticating and authorizing a remote access connection and for authenticating and logging on to a Windows domain. Single sign-on is performed by selecting the Logon by using dial-up networking option on the Windows XP and Windows 2000 logon dialog box and then selecting a dial-up or VPN connection to use to connect to the organization.

For VPN connections, the user must first connect to the Internet before creating a VPN connection. After the Internet connection is made, the VPN connection and logon to the domain can be accomplished. If there is a separate ISP account that the user uses to connect to the Internet, you can create a dial-up connection with the ISP credentials already configured. Then, configure your VPN connection to dial the ISP connection before attempting the VPN connection. In this configuration, the user will never have to type the ISP credentials when logging on to the domain. This association between the VPN connection and the ISP connection can be configured manually or by using Connection Manager.

Installing a Certificate on a Client Computer

If your Windows 2000 or Windows XP VPN clients are either making L2TP connections or using certificates for user-level authentication, certificates must be installed on the VPN client computer. For L2TP connections, a computer certificate must be installed on the VPN client computer to provide authentication for establishing an IPSec security association (SA). For user-level authentication using the Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol, you can either use a user certificate or a smart card.

For user certificate-based authentication, the computer user must request a user certificate from a Windows Server 2003 certification authority (CA) on your intranet. For smart card-based authentication, a network administrator must configure an enrollment station and issue smart cards with certificates that are mapped to individual user accounts.

For more information about installing certificates on VPN client computers, see Certificate Infrastructure in this paper.

Design Points: Configuring the VPN client

Consider the following when configuring your VPN clients for remote access VPN connections:

  • If you have a small number of VPN clients, perform manual configuration of VPN connections on each computer.

  • If you have a large number of VPN clients or they are running different versions of Microsoft operating systems, use the Connection Manager components of Windows Server 2003 to create the custom VPN connection configuration package for distribution and to maintain the phone book database for your POPs.

  • If you are using Windows XP, Windows 2000, or Microsoft L2TP/IPSec VPN Client to make L2TP connections, you must install a computer certificate on the VPN client computer.

  • If you are using Windows XP or Windows 2000 VPN clients and user-level certificate authentication with EAP-TLS, you must either install a user certificate on the VPN client computer or a user certificate on the smart card used by the VPN client computer.

Internet Network Infrastructure

To create a VPN connection to a VPN server across the Internet:

  • The VPN server's name must be resolvable.

  • The VPN server must be reachable.

  • VPN traffic must be allowed to and from the VPN server.

VPN Server Name Resolvability

In most cases you want to reference the VPN server by name, rather than an IP address, as names are much easier to remember. You can use a name (for example VPN1.example.microsoft.com) as long as the name can be resolved to an IP address. Therefore, you must ensure that whatever name you are using for your VPN servers when configuring a VPN connection, that name must be able to be resolved to an IP address using the Internet Domain Name System (DNS) infrastructure.

When you use names rather than addresses, you can also take advantage of DNS round robin load balancing if you have multiple VPN servers with the same name. Within DNS, you can create multiple records that resolve a specific name to different IP address. In this situation, DNS servers send back all the addresses in response to a DNS name query and randomize the order of the addresses for successive queries. Because most DNS clients use the first address in the DNS query response, the result is that VPN client connections are on average spread across the VPN servers.

VPN Server Reachability

To be reachable, the VPN server 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 VPN server 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 VPN server translates the published and actual IP addresses of the VPN server in packets to and from the VPN server.

While the routing infrastructure might be in place, the VPN server 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 VPN server computer.

VPN Servers and Firewall Configuration

There are two approaches to using a firewall with a VPN server:

  1. The VPN server is attached directly to the Internet and the firewall is between the VPN server and the intranet.

    In this configuration, the VPN server 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 remote access traffic.

  2. The firewall is attached to the Internet and the VPN server is between the firewall and the intranet.

    In this configuration, both the firewall and the VPN server are attached to a network segment known as the perimeter network (also known as a screened subnet). Both the firewall and the VPN server 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 server and the firewall for both of these configurations, see Appendix A.

Design Points: VPN Server Accessibility from the Internet

Consider the following when configuring your Internet infrastructure for remote access VPN connections:

  • Ensure that the DNS names of your VPN servers are resolvable from the Internet 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 VPN server when directly connected to the Internet. 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 proper IP address.

  • Ensure that the IP addresses of your VPN servers are reachable from the Internet by using the Ping tool to ping the name or address of your VPN server 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 VPN server is not reachable.

  • Configure packet filtering for PPTP traffic, L2TP traffic, or both types of traffic on the appropriate firewall and VPN server interfaces connecting to the Internet and the perimeter network. For more information, see Appendix A.

Authentication Protocols

To authenticate the user who is attempting to create a PPP connection, Windows Server 2003 supports a wide variety of PPP authentication protocols including:

  • Password Authentication Protocol (PAP)

  • 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 VPN client and the VPN server. 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 or smart cards, MS-CHAP v2 is highly recommended as it is a stronger authentication protocol than MS-CHAP and provides mutual authentication. With mutual authentication, the VPN server authenticates the VPN client and the VPN client authenticates the VPN server.

noteNote
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. In an Active Directory service domain, use Group Policy settings to enforce strong user passwords.

EAP-TLS is used in conjunction with a certificate infrastructure and either user certificates or smart cards. With EAP-TLS, the VPN client sends its user certificate for authentication and the VPN server sends a computer certificate for authentication. This is the strongest authentication method as it does not rely on passwords.

noteNote
You can use third-party CAs. For information, see Appendix E.

For L2TP/IPSec connections, any authentication protocol can be used because the authentication occurs after the VPN client and VPN server 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 to provide strong user authentication.

Design Point: Which Authentication Protocol to Use?

Consider the following when choosing an authentication protocol for VPN connections:

  • If you are using smart cards or have a certificate infrastructure that issues user certificates, use the EAP-TLS authentication protocol for both PPTP and L2TP connections. Only VPN clients running Windows XP and Windows 2000 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 XP, Windows 2000, Windows NT 4.0 with Service Pack 4 and later, Windows Millennium Edition, and Windows 98.

VPN Protocols

Windows Server 2003 includes support for two remote access VPN protocols:

  1. Point-to-Point Tunneling Protocol

  2. 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 version 2 of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2) is used with strong passwords, PPTP is a secure VPN technology. For nonpassword-based authentication, Extensible Authentication Protocol-Transport Level Security (EAP-TLS) can be used to support smart cards. PPTP is widely supported, easily deployed, and can be used across network address translators (NATs).

Layer Two Tunneling Protocol with IPSec

L2TP leverages PPP user authentication and IPSec encryption to encapsulate and encrypt IP traffic. This combination, known as L2TP/IPSec, uses certificate-based computer identity authentication to create the IPSec session in addition to PPP-based user authentication. L2TP/IPSec provides data integrity and data origin authentication for each packet. However, L2TP/IPSec requires a certificate infrastructure to allocate computer certificates and is supported by Windows Server 2003, Windows XP, Windows 2000, and Microsoft L2TP/IPSec VPN Client L2TP clients.

Design Point: PPTP or L2TP/IPSec?

Consider the following when deciding between PPTP and L2TP/IPSec for remote access VPN connections:

  • PPTP can be used with a variety of Microsoft clients including Windows Server 2003, Windows XP, Windows 2000, Windows NT version 4.0, Windows Millennium Edition, and Windows 98. 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 origin authentication (proof that the data was sent by the authorized user).

  • PPTP-based VPN clients can be located behind a NAT if the NAT includes a NAT editor that knows how to properly translate PPTP tunneled data. For example, both the Internet connection sharing (ICS) feature of the Network Connections folder and the NAT/Basic Firewall routing protocol component of the Routing and Remote Access service include a NAT editor that translates PPTP traffic to and from PPTP clients located behind the NAT. VPN servers 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 VPN server or, if there is only one public address, if the NAT is configured to translate and forward the PPTP tunneled data to the VPN server. Most NATs using a single public IP address, including ICS and the NAT/Basic Firewall 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, a VPN server cannot be located behind a computer using ICS or the NAT routing protocol component when using a single IP address.

  • L2TP/IPSec-based VPN clients or servers cannot be behind a NAT unless both the client and server support IPSec NAT Traversal (NAT-T). IPSec NAT-T is supported by Windows Server 2003, Windows XP Service Pack 2 (SP2), Windows XP Service Pack 1 (SP1) and Windows 2000 with L2TP/IPSec NAT-T Update for Windows XP and Windows 2000, and for previous versions of Windows with Microsoft L2TP/IPSec VPN Client. Microsoft recommends that servers, such as VPN servers running Windows Server 2003, 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.

    Computers running Windows XP SP2 by default do use IPSec NAT-T to connect to servers that are located behind a NAT. This includes VPN server computers running Windows Server 2003. This default behavior can be modified with a registry setting. For more information, see The default behavior of IPSec NAT traversal (NAT-T) is changed in Windows XP Service Pack 2.

  • L2TP/IPSec can be used with Windows Server 2003, Windows XP, Windows 2000, and Microsoft L2TP/IPSec VPN Client clients and supports computer certificates as the recommended authentication method for IPSec. Computer certificate authentication requires a certificate infrastructure to issue computer certificates to the VPN server computer and all VPN client computers.

  • By using IPSec, L2TP/IPSec -based VPN connections provide data confidentiality, data integrity, data origin authentication, and replay protection.

  • PPTP and L2TP/IPSec is not an either/or choice. By default, a Windows Server 2003 VPN server supports both PPTP and L2TP/IPSec connections simultaneously. You can use PPTP for some remote access VPN connections (from VPN clients that are not running Windows XP or Windows 2000 and do not have an installed computer certificate) and L2TP/IPSec for other remote access VPN connections (from VPN clients running Windows XP, Windows 2000, or Microsoft L2TP/IPSec VPN Client and have an installed computer certificate).

  • If you are using both PPTP and L2TP/IPSec, you can create separate remote access policies that define different connection parameters for PPTP and L2TP/IPSec connections.

VPN Server

A VPN server is a computer running Windows Server 2003 and the Routing and Remote Access service. The VPN server does the following:

  • Listens for PPTP connection attempts and IPSec SA negotiations for L2TP connection attempts.

  • Authenticates and authorizes VPN connections before allowing data to flow.

  • Acts as a router forwarding data between VPN clients and resources on the intranet.

  • Acts as an endpoint of the VPN tunnel from the tunnel client (typically the VPN client).

  • Acts as the endpoint of the VPN connection from the VPN client.

The VPN server typically has two or more installed network adapters: one or more network adapters connected to the Internet and one or more network adapters connected to the intranet. The configuration of a VPN server with a single network adapter is discussed in Appendix B.

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.

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 servers, you should select the Remote access (dial-up or VPN) configuration option.

With the Remote access (dial-up or VPN) option, the Routing and Remote Access server operates in the role of a dial-up or VPN server that supports remote access VPN connections. For remote access VPN connections, users run VPN client software and initiate a remote access connection to the server.

When you select the Remote access (dial-up or VPN) option in the Routing and Remote Access Server Setup Wizard:

  1. You are first prompted to specify whether VPN, dial-up, or both types of access are needed.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

  1. 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.

  2. 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.

  3. The selected Internet interface is configured with input and output IP packet filters that allow only PPTP and L2TP/IPSec traffic.

  4. 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.

  5. 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.

Design Points: Configuring the VPN Server

Consider the following before running the Routing and Remote Access Server Setup Wizard:

  • Which connection of the VPN server is connected to the Internet?

    Typical Internet-connected VPN servers have at least two LAN connections: one connected to the Internet (either directly or connected to a perimeter network) and one connected to the organization intranet. To make this distinction easier to see during the Routing and Remote Access Server Setup Wizard, rename the connections with their purpose or role using the Network Connections folder. For example, rename the connection connected to the Internet, default name Local Area Connection 2, to Internet.

  • Can the VPN server be a DHCP client?

    The VPN server must have a manual TCP/IP configuration for its Internet interface. While technically possible, it is not recommended that the VPN server be a DHCP client for its intranet interface(s). Due to the routing requirements of the VPN server, 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 server to have a manual TCP/IP configuration and still use DHCP to obtain IP addresses for VPN clients.

  • How will IP addresses be allocated to remote access VPN clients?

    The VPN server 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 intranet connection of the VPN server 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 intranet connection of the VPN server is attached contains 50 DHCP clients, then, for the default configuration of the VPN server, the scope must contain at least 307 addresses (50 computers + 128 PPTP clients + 128 L2TP clients + 1 address for the VPN server). If there are not enough IP addresses in the scope, VPN clients that connect after all the addresses in the scope are allocated will be unable to access intranet resources.

    If you are configuring a static pool of addresses, there might be additional routing considerations. For more information, see Intranet network infrastructure in this paper.

  • What is the authentication and accounting provider?

    The VPN server can use Windows or RADIUS as its authentication or accounting provider.

    When Windows is used as the authentication and accounting provider, the VPN server uses Windows mechanisms to validate the credentials of the VPN client and access the VPN client'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 server uses a configured RADIUS server to validate the credentials of the VPN client, authorize the connection attempt, and store VPN connection accounting information.

  • Will there be multiple VPN servers?

    If so, create multiple DNS A records to resolve the same name of the VPN server (for example, vpn.microsoft.com) to the different IP addresses of the separate VPN servers. DNS round robin will distribute the VPN connections across the VPN servers.

Consider the following when changing the default configuration of the VPN server for remote access VPN connections:

  • Do you need additional PPTP or L2TP ports?

    By default, the Routing and Remote Access Server Setup Wizard configures 128 PPTP and 128 L2TP ports allowing 128 simultaneous PPTP connections and 128 simultaneous L2TP connections. If this is not sufficient for the maximum number of PPTP or L2TP connections, you can change the number of PPTP and L2TP ports by configuring the WAN miniport (PPTP) and WAN miniport (L2TP) devices from the properties of the Ports object in the Routing and Remote Access snap-in.

  • Do you need to install a computer certificate?

    If the VPN server is configured with the Windows authentication provider and is supporting L2TP connections or is authenticating connections using the EAP-TLS authentication protocol, you must install a computer certificate on the VPN server that can be validated by the VPN client and a root certificate that is used to validate the VPN client.

  • Do you need custom remote access policies for VPN connections?

    If you configure the VPN server for Windows authentication or for RADIUS authentication and the RADIUS server is a computer running the Internet Authentication Service (IAS), the default remote access policy rejects 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 custom 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 server in the Routing and Remote Access snap-in.

Intranet Network Infrastructure

The network infrastructure of the intranet is an important element of VPN design. Without proper design, VPN clients are unable to obtain proper IP addresses and resolve intranet names, and packets cannot be forwarded between VPN clients and intranet resources.

Name Resolution

If you use Domain Name System (DNS) to resolve intranet host names or Windows Internet Name Service (WINS) to resolve intranet NetBIOS names, ensure that the VPN server is configured with the IP addresses of the appropriate DNS and WINS servers. The VPN server can be configured with DNS and WINS server either manually or as a DHCP client. As part of the PPP negotiation process, the VPN clients receive the IP addresses of DNS and WINS server. By default, the VPN clients inherit the DNS and WINS server addresses configured on the VPN server.

After the PPP connection negotiation is complete, Windows XP and Windows 2000 VPN clients send a DHCPInform message to the VPN server. The response is relayed back to the VPN client and contains a DNS domain name, additional DNS server addresses for DNS servers that are checked before the DNS server configured through the PPP negotiation, and WINS server addresses that replace the WINS server addresses configured through the PPP negotiation. This communication is facilitated by the DHCP Relay Agent routing protocol component of the Routing and Remote Access service, which is automatically added by the Routing and Remote Access Server Setup Wizard.

If the VPN server is a DHCP client (the VPN server is using DHCP to configure its intranet interfaces), the VPN server relays the DHCPInform messages to the DHCP server that was in use when the Routing and Remote Access Server Wizard was run. If the VPN server has a manual TCP/IP configuration on its intranet interface (recommended), the DHCP Relay Agent routing protocol component must be configured with the IP address of at least one DHCP server on your intranet. You can add DHCP server IP addresses to the DHCP Relay Agent routing protocol component on the General tab from the properties of the DHCP Relay Agent object under IP Routing in the Routing and Remote Access snap-in.

Design Points: Name Resolution by VPN Clients for Intranet Resources

Consider the following when configuring name resolution for remote access VPN clients:

  • Using the Ping and Net tools, test DNS and WINS name resolution for intranet resources from the VPN server computer. If name resolution does not work from the VPN server, it will not work for VPN clients. Troubleshoot and fix all name resolution problems of the VPN server before testing VPN connections.

  • If the VPN server is a DHCP client (the VPN server is using DHCP to configure its intranet interfaces), no other configuration is necessary. The DNS and WINS servers assigned to the VPN server are also assigned to the VPN clients. The default configuration of the Routing and Remote Access Server Setup Wizard adds the DHCP Relay Agent routing protocol component and configures it with the IP address of the VPN server's DHCP server so that DHCPInform messages sent by VPN clients running Windows XP and Windows 2000 and its response are properly relayed between the VPN client and the DHCP server of the VPN server.

    However, configuring the VPN server as a DHCP client is not recommended due to issues with configuring the VPN server's default gateway. Therefore, it is recommended that you manually configure the TCP/IP configuration of the VPN server's intranet interfaces and manually configure the DHCP Relay Agent routing protocol component with the IP address of one or more of your DHCP servers.

  • If the VPN server is manually configured with a TCP/IP configuration, verify the DNS and WINS server addresses. In this configuration, the Routing and Remote Access Server Setup Wizard cannot automatically configure the DHCP Relay Agent routing protocol component. You must manually add the IP address of at least one DHCP server on your intranet in order for DHCPInform messages to be replayed between VPN clients running Windows XP and Windows 2000 and the DHCP server. If you do not, DHCPInform messages sent by VPN clients running Windows XP and Windows 2000 are discarded and the VPN clients do not receive the updated DNS and WINS server addresses or the DNS domain name.

  • If you have a single-subnet small office/home office (SOHO) with no DHCP, DNS, or WINS server, you must either configure a DNS server or WINS server in order to resolve names for both computers on the SOHO subnet and VPN clients or enable NetBIOS broadcast name resolution, which enables NetBIOS over TCP/IP name resolution between connected VPN clients and computers on the SOHO network. NetBIOS broadcast name resolution can be enabled from the IP tab in the properties of a VPN server in the Routing and Remote Access snap-in.

Routing

The VPN server is an IP router and as such must be properly configured with the set of routes that makes all locations reachable.

Specifically, the VPN server 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 on your intranet that point to a neighboring intranet router.

    These routes make all of the locations on your intranet reachable from the VPN server. Without these routes, all intranet hosts not connected to the same subnet as the VPN server 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 intranet interface without a default gateway.

To add intranet routes to the routing table of the VPN server, 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 intranet. At a minimum, you just need to add the routes that summarize all the possible addresses in your intranet. For example, if your intranet 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 intranet subnet to which your VPN server is attached.

  • If you are using the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocols in your intranet, you can add and configure the RIP or OSPF routing protocol components of the Routing and Remote Access service so that the VPN server participates in the propagation of routing information as a dynamic router.

If your intranet has only a single subnet, no further configuration is required.

Ensuring the reachability of VPN clients from the intranet depends on how you configure the VPN server to obtain IP addresses for VPN clients.

The IP addresses assigned to VPN clients as they connect can be from:

  • An on-subnet address range, which is an address range of the intranet subnet to which the VPN server is attached.

    An on-subnet address range is used whenever the VPN server is configured to use DHCP to obtain IP addresses for VPN clients 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 server.

    An off-subnet address range is used whenever the VPN server is manually configured with pool(s) 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 server acts as a proxy for all packets destined for VPN clients. Routers and hosts on the VPN server subnet forward packets destined to VPN clients to the VPN server and the VPN server relays them the appropriate VPN client.

If you are using an off-subnet address range, you must add the route(s) that summarize the off-subnet address range to the intranet routing infrastructure so that traffic destined to VPN clients are forwarded to the VPN server and then sent by the VPN server to the appropriate VPN client. 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 intranet through the following:

  • Add static routes to the neighboring router for the off-subnet address range that point to the VPN server's intranet interface. Configure the neighboring router to propagate this static route to other routers in the intranet using the dynamic routing protocol used in your intranet.

  • If the VPN server is using OSPF and participating as a dynamic router, the VPN server 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 intranet.

If your intranet consists of a single subnet, then you must either configure each intranet host for persistent route(s) of the off-subnet address range that point to the VPN server's intranet interface or configure each intranet host with the VPN server as its default gateway. Therefore, it is recommended that you use an on-subnet address pool for a SOHO network consisting of a single subnet.

VPN Client Routing and Simultaneous Intranet and Internet Access

By default, when a Windows-based VPN client makes a VPN connection, it automatically adds a new default route for the VPN connection and modifies the existing default route to have a higher metric. Adding the new default route means that all Internet locations except the IP address of the tunnel server and locations based on other routes are not reachable for the duration of the VPN connection.

To prevent the default route from being created, obtain properties of the Internet Protocol (TCP/IP) component of the VPN connection. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the General tab, and then clear the Use default gateway on remote network check box. When the Use default gateway on remote network check box is cleared, a default route is not created, however, a route corresponding to the Internet address class of the assigned IP address is created. For example, if the address assigned during the connection process is 10.0.12.119, the Windows 2000 and Windows XP VPN client creates a route for the class-based network ID 10.0.0.0 with the subnet mask 255.0.0.0.

Based on the Use default gateway on remote network setting, one of the following occurs when the VPN connection is active:

  • Internet locations are reachable and intranet locations are not reachable except those matching the address class of the assigned IP address (the Use default gateway on remote network check box is cleared).

  • All intranet locations are reachable and Internet locations are not reachable except the address of the VPN server and location available through other routes (the Use default gateway on remote network check box is selected).

For most Internet-connected VPN clients, this behavior does not represent a problem because they are typically engaged in either intranet or Internet communication, not both.

For VPN clients who want concurrent access to intranet and Internet resources when the VPN connection is active, you can do one of the following:

  • Select the Use default gateway on remote network check box (the default setting) and allow Internet access through the organization intranet. Internet traffic between the VPN client and Internet hosts would pass though firewalls or proxy servers as if the VPN client is physically connected to the organization intranet. While there is an impact on performance, this method allows Internet access to be filtered and monitored according to the organization's network policies while the VPN client is connected to the organization network.

  • If the addressing within your intranet is based on a single class-based network ID, clear the Use default gateway on remote network check box. The best example is when your intranet is using the private IP address space 10.0.0.0/8.

  • If the addressing within your intranet is not based on a single class-based network ID, you can use one of the following solutions:

    • The DHCPInform message sent by Windows XP clients includes the requesting of the DHCP Classless Static Routes DHCP option. If configured on a Windows Server 2003 DHCP server, the Classless Static Routes DHCP option contains a set of routes representing the address space of your intranet that are automatically added to the routing table of the requesting client.

    • The Connection Manager Administration Kit for Windows Server 2003 allows you to configure specific routes as part of the connection manager profile distributed to VPN users. You can also specify a Uniform Resource Locator (URL) that contains the current set of organization intranet routes or additional routes beyond those configured in the profile.

    • Clear the Use default gateway on remote network check box and use one of the following a command file (.CMD) on the VPN client with route commands to add static routes for the network IDs of your intranet using your assigned IP address as the gateway IP address after the connection is made.

You can determine your assigned IP address from the display of the Ipconfig command or by double-clicking the VPN connection in the Network Connections folder when the VPN connection is active. In the resulting Status dialog box, click the Details tab. The VPN client's assigned IP address is listed as Client IP address.

Design Points: Routing Infrastructure

Consider the following when configuring the routing infrastructure for remote access VPN connections:

  • Configure the Internet interface of the VPN server with a default gateway. Do not configure the intranet interface of the VPN server with a default gateway.

  • Add static IP routes to the VPN server that summarize the addresses used in your intranet. Alternately, if you use either RIP or OSPF for your dynamic routing protocol, configure and enable RIP or OSPF on the VPN server. If you use a routing protocol other than RIP or OSPF, such as Interior Gateway Routing Protocol (IGRP), you might configure the VPN server's neighboring intranet router for RIP or OSPF on the interface connected to subnet to which the VPN server is attached and IGRP on all other interfaces.

  • Configure the VPN server with an on-subnet address range by obtaining IP addresses through DHCP or by manually configuring on-subnet address pools.

Quarantine Resources

Network Access Quarantine Control, a new feature in the Windows Server 2003 family, delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, with which network access is limited. The administrator-provided script is run on the remote access computer. When the script notifies the remote access server that it has successfully run and the remote access computer complies with current network policies, quarantine mode is removed and the remote access computer is granted normal remote access.

Quarantine resources consists of servers that a remote access client in quarantine mode can access to perform name resolution (DNS servers), obtain the latest version of the script (such as file servers with anonymous access allowed), or instructions and components needed to make the remote access client comply with network policies (such as Web servers with anonymous access allowed).

For more information about Network Access Quarantine Control, see the white paper titled "Windows Server 2003 Network Access Quarantine Control."

AAA Infrastructure

The authentication, authorization, and accounting (AAA) infrastructure exists to:

  • Authenticate the credentials of VPN clients.

  • Authorize the VPN connection.

  • Record the VPN connection creation and termination for accounting purposes.

The AAA infrastructure consists of:

  • The VPN server computer

  • A RADIUS server computer

  • A domain controller

As previously discussed, a Windows Server 2003 VPN server can be configured with either Windows or RADIUS as its authentication or accounting provider. RADIUS provides a centralized AAA service when you have multiple VPN servers or a mix of heterogeneous dial-up and VPN equipment.

When you configure Windows as the authentication provider, the VPN server 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 VPN server relies on a RADIUS server to perform both the authentication and authorization. When a VPN connection is attempted, the VPN client credentials and other connection parameters are used to create a RADIUS Access-Request message that is sent to the configured RADIUS server. 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 VPN server logs VPN connection 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 Routing and Remote Access snap-in.

When you configure RADIUS as the authentication provider, the VPN server 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, it is recommended to use the Internet Authentication Service (IAS). IAS is a full-featured RADIUS server (for Windows 2000 Server and Windows Server 2003) that is tightly integrated with Active Directory and the Routing and Remote Access service. IAS for Windows Server 2003 also supports a RADIUS proxy.

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.

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 grant or deny access 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 VPN server, among others.

  • IP settings can define using IP packet filters the specific types of IP traffic that are allowed for remote access VPN connections. With profile packet filters, you can configure the IP traffic that is allowed from remote access clients (From client filters) or to remote access clients (To client filters) on an exception basis: either all traffic except traffic specified by filters or no traffic except traffic specified by filters. Remote access policy profile filtering applies to all remote access connections that match the remote access policy.

  • Authentication settings can define which authentication protocols the VPN client must use in order to send 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 named VPNUsers whose members are the user accounts of the users creating remote access VPN connections across the Internet. Then, you create a policy with two conditions on the policy: NAS-Port-Type is set to Virtual (VPN) and Windows-Group is set to VPNUsers. Finally, you configure the profile for the policy for a specific authentication method and encryption strength.

Preventing Traffic Routed from VPN Clients

Once a VPN client successfully establishes a PPTP or L2TP connection, by default any packet sent over the connection is received by the VPN server and forwarded.

Packets sent over the connection can include:

  • Packets originated from the remote access client computer

  • Packets sent to the remote access client computer by other computers

When the remote access client computer makes the VPN connection, by default it creates a default route so that all traffic that matches the default route is sent over the VPN connection. If other computers are forwarding traffic to the remote access VPN client, treating the remote access client computer as a router, then that traffic is also be forwarded across the VPN connection. This is a security problem because the VPN server has not authenticated the computer that is forwarding traffic to the remote access VPN client. The computer forwarding traffic to the remote access VPN client computer has the same network access as the authenticated remote access VPN client computer.

To prevent the VPN server from receiving traffic across the VPN connection for computers other than authenticated remote access VPN client computers, configure remote access policy packet filters on the remote access policy that is used for your VPN connections.

For the Input Filters, set the filter action to Permit only the packets listed below and configure a single filter with the settings listed in Table 2.

Table 2 Input filter settings

 

IP Packet Filter Field Setting

Source Address

User's address

Source Network Mask

User's mask

Destination Address

Any

Destination Network Mask

Any

Protocol

Any

For the Output Filters, set the filter action to Permit only the packets listed below and configure a single filter with the settings listed in Table 3.

Table 3 Output filter settings

 

IP Packet Filter Field Setting

Source Address

Any

Source Network Mask

Any

Destination Address

User's address

Destination Network Mask

User's mask

Protocol

Any

noteNote
Although the Routing and Remote Access snap-in displays User's address and User's mask, the actual filter that is created for each remote access client is for the client's assigned IP address and a subnet mask of 255.255.255.255.

noteNote
The default policy named Connections to Microsoft Routing and Remote Access server has the input packet filters previously described already configured. With this set of IP packet filters, the VPN server discards all traffic sent across the VPN connection except traffic that either originated from or is sent to authenticated remote access VPN clients.

Windows Domain User Accounts and Groups

Windows NT version 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 VPN clients 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 VPN connection attempt is rejected.

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 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 VPNUsers group and add as members all the user accounts allowed to create VPN connections.

Both the Routing and Remote Access service and IAS can use Active Directory universal principal names (UPNs) and universal groups. In a large domain with thousands of users, create a universal group for all of the users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all of your user accounts directly into the universal group, especially if you have a large number of them on your network. Instead, create separate global groups that are members of the universal group, and add users to those global groups.

Design Points: AAA Infrastructure

Consider the following when configuring the AAA infrastructure for remote access VPN connections:

  • If you have multiple VPN servers and you want to centralize AAA service or a heterogeneous mixture of dial-up and VPN equipment, use a RADIUS server and configure the VPN server 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, to specify the use of EAP-TLS, or to limit traffic using IP packet filtering.

  • To prevent VPN clients from forwarding routed traffic, configure remote access policy profile packet filters to discard all traffic on VPN connections except traffic to and from VPN clients.

  • For a large Active Directory domain, nest global groups within universal groups to manage access based on group membership.

  • Sensitive fields of RADIUS messages, such as the user password and encryption keys, are encrypted with the RADIUS shared secret configured on the VPN server and the RADIUS server. Make the shared secret a long (22 characters or longer), random sequence of letters, numbers, and punctuation. An example of a strong shared secret is 8d#>9fq4bV)H7%a3^jfDe2. To further protect RADIUS traffic, use Windows Server 2003 IPSec policies to provide data confidentiality for all traffic using the RADIUS UDP destination 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 smart card or user certificate-based authentication for VPN connections using EAP-TLS, a certificate infrastructure, also known as a public key infrastructure (PKI), 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

When you are using the certificate authentication method for L2TP connections, the list of certification authorities (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 computer certificates to the computer. 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 computer certificate issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.

The VPN client 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 VPN server trusts. Additionally, the VPN server 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 VPN client trusts.

For example, if the VPN client was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies the VPN server during IPSec security negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the VPN server does not have a valid computer certificate issued from a CA that follows a certificate chain to either CertAuth1 or CertAuth2, IPSec security negotiation fails.

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.

Deploying computer certificates in your organization consists of the following:

  1. Deploy a certificate infrastructure. For more information, see Appendix D, "Deploying a Certificate Infrastructure".

  2. Install a computer certificate on each computer. For more information, see "Deploying L2TP-based Remote Access" in this paper.

Certificate Infrastructure for Smart Cards

The use of smart cards for user authentication is the strongest form of user authentication in Windows Server 2003. For remote access VPN connections, you must use the Extensible Authentication Protocol (EAP) with the Smart card or other certificate (TLS) EAP type, also known as EAP-Transport Level Security (EAP-TLS).

Deploying smart cards in your organization consists of the following:

  1. Create a certificate infrastructure using certification authorities.

  2. For each domain, set security permissions and delegation for the Smart Card User, Smart Card Logon and Enrollment Agent certificate templates.

  3. Configure the CA to issue smart card and Enrollment Agent certificates.

  4. Configure an enrollment station, a computer that is used to physically install the smart card certificates on smart cards.

  5. Use the enrollment station to create a smart card with a smart card user logon certificate that is installed on the smart card and assigned to a specific user account.

For more information about how to configure smart cards for user logon, see the topic titled Checklist: Deploying smart cards for logging on to Windows in Windows Server 2003 Help and Support.

The individual smart cards are distributed to users who have a computer with a smart card reader. To log in to the computer, the smart card must be inserted into the smart card reader and the smart card personal identification number (PIN) must be typed. When the user attempts a VPN connection, the smart card certificate is sent during the connection negotiation process.

To configure EAP-TLS for smart cards on the VPN client:

  • The VPN connection must be configured to use EAP with the Smart Card or other certificate EAP type.

  • In the properties of the Smart Card or other certificate EAP type, select Use my smart card.

  • For Windows 2000 or Windows XP (prior to Service Pack 1) VPN clients, if you want to validate the computer certificate of the VPN or IAS server, select Validate server certificate. If you want to ensure that the servers DNS name ends in a specific string, select Connect only if server name ends with and type the string. To require the server's computer certificate to have been issued a certificate from a specific trusted root CA, select the CA in Trusted root certification authority.

  • For Windows XP (Service Pack 1 and later) VPN clients, if you want to validate the computer certificate of the VPN or IAS server, select Validate server certificate. If you want to configure the names of the authenticating servers, select Connect to these servers and type the server names. To require the server's computer certificate to have been issued a certificate from a specific set of trusted root CAs, select them in Trusted Root Certification Authorities.

To configure EAP-TLS authentication on the VPN server:

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

To configure EAP-TLS authentication on the remote access policy:

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

Certificate Infrastructure for User Certificates

The use of registry-based user certificates for user authentication can be used in place of smart cards. However, it is not as strong a form of authentication. With smart cards, the user certificate issued during the authentication process is only made available when the user physically possesses the smart card and has knowledge of the PIN to logon to their computer. With user certificates, the user certificate issued during the authentication process is made available when the user logs on to their computer using a domain-based user name and password.

Just as with smart cards, authentication using user certificates for remote access VPN connections use EAP-TLS as the authentication protocol.

Deploying user certificates in your organization consists of the following:

  1. Deploy a certificate infrastructure. For more information, see Appendix D, "Deploying a Certificate Infrastructure".

  2. Install a user certificate for each user. For more information, see "Deploying PPTP-based Remote Access" and "Deploying L2TP-based Remote Access" in this paper.

When the user attempts a VPN connection, the user certificate is sent during the connection negotiation process.

To configure EAP-TLS for user certificates on the VPN client:

  • The VPN connection must be configured to use EAP with the Smart Card or other certificate EAP type.

  • For Windows 2000 or Windows XP (prior to Service Pack 1) VPN clients, if you want to validate the computer certificate of the VPN or IAS server, select Validate server certificate. If you want to ensure that the server's DNS name ends in a specific string, select Connect only if server name ends with and type the string. To require the server's computer certificate to have been issued a certificate from a specific trusted root CA, select the CA in Trusted root certification authority.

  • For Windows XP (Service Pack 1 and later) VPN clients, if you want to validate the computer certificate of the VPN or IAS server, select Validate server certificate. If you want to configure the names of the authenticating servers, select Connect to these servers and type the server names. To require the server's computer certificate to have been issued a certificate from a specific set of trusted root CAs, select them in Trusted Root Certification Authorities.

To configure EAP-TLS authentication on the VPN server:

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

To configure EAP-TLS authentication on the remote access policy:

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

Design Points: Certificate Infrastructure

Consider the following when configuring the certificate infrastructure for remote access VPN connections:

  • In order to create L2TP/IPSec remote access VPN connections using computer certificate authentication for IPSec, you must install computer certificates, also known as machine certificates, on each VPN client and VPN server. If you are using a Windows Server 2003 enterprise CA as an issuing CA, configure your Active Directory domain for auto-enrollment of computer certificates using Computer Configuration Group Policy. Each computer that is a member of the domain automatically requests a computer certificate when the Computer Configuration Group Policy is updated.

    The computer certificate of the VPN client must be valid and verifiable by the VPN server the VPN server must have a root CA certificate for the CA that issued the computer certificate of the VPN client.

    The computer certificate of the VPN server must be valid and verifiable by the VPN client the VPN client must have a root CA certificate for the CA that issued the computer certificate of the VPN server.

  • In order to authenticate VPN connections using a smart card or user certificate with EAP-TLS, the VPN client must have a smart card or registry-based user certificate installed and the authenticating server must have a computer certificate installed. The authenticating server is either the VPN server (if configured for Windows authentication) or the IAS server (if the VPN server is configured for RADIUS authentication and the RADIUS server is a computer running Windows Server 2003 and IAS).

    The smart card or user certificate of the VPN client must be valid and verifiable by the authenticating server the authenticating server trust the root CA for the CA that issued the certificate of the VPN client.

    The computer certificate of the authenticating server must be verifiable by the VPN client the VPN client trust the root CA for the CA that issued the computer certificate of the authenticating server.

  • 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 laptop computer that is issued to an employee without the certificates needed to make L2TP/IPSec or EAP-TLS-authenticated connections.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft