Deploying L2TP/IPSec-based Remote Access

Applies To: Windows Server 2003 with SP1

Deploying L2TP-based remote access VPN connections using Windows Server 2003 consists of the following:

• Deploy certificate infrastructure

• Deploy Internet infrastructure

• Deploy AAA infrastructure

• Deploy VPN servers

• Deploy intranet infrastructure

• Deploy VPN clients

Deploying Certificate Infrastructure

For L2TP-based VPN connections, a certificate infrastructure is required to issue computer certificates needed to negotiate authentication for IPSec. Additionally, a certificate infrastructure is also needed when you are using either smart cards or user certificates and EAP-TLS for user authentication. You must install a computer certificate on all VPN clients and VPN servers. If you are using EAP-TLS for user authentication, you must install a user certificate on all VPN clients and, if the authenticating server is a RADIUS server, a computer certificate on the RADIUS server.

For information about deploying a certificate infrastructure, see Appendix D, "Deploying a Certificate Infrastructure."

Deploying Computer Certificates

To install a computer certificate, a CA must be present to issue certificates. Once the CA is configured, you can install a computer certificate in the following ways:

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

   This method allows a single point of configuration for the entire domain. All members of the domain automatically request the computer certificate through a Group Policy setting. To immediately obtain a computer certificate for a computer running Windows 2000 that is a member of the domain for which auto-enrollment is configured, restart the computer or type secedit /refreshpolicy machine_policy from a command prompt. To immediately obtain a computer certificate for a computer running Windows Server 2003 or Windows XP that is a member of the domain for which auto-enrollment is configured, restart the computer or type gpupdate /target:computer from a command prompt. To configure an Active Directory domain for automatic enrollment of computer certificates, see the topic titled "Checklist: Configuring certificate autoenrollment" in Windows Server 2003 Help and Support.

2. By using the Certificates snap-in to request a computer certificate.

   If you are using a Windows Server 2003 enterprise CA as an issuing CA, each computer can separately request a computer certificate from the issuing CA using the Certificates snap-in. For more information, see the topics titled "Manage an individual certificate" and "Request a certificate" in Windows Server 2003 Help and Support.

3. By using the Certificates snap-in to import a computer certificate.

   If you have a certificate file that contains the computer certificate, you can import the computer certificate using the Certificates snap-in. For more information about importing a certificate using the Certificates snap-in, see the topic titled Import a certificate in Windows Server 2003 Help and Support.

4. By executing a CAPICOM script that requests a computer certificate.

   In this method, each computer must execute a CAPICOM script that requests a computer certificate from the issuing CA. CAPICOM is a COM client, supporting Automation, that performs cryptographic functions (the CryptoAPI) using Microsoft ActiveX and COM objects. CAPICOM can be used via Visual Basic, Visual Basic Scripting Edition, and C++. For more information about CAPICOM, see CAPICOM at https://msdn.microsoft.com/library/en-us/seccrypto/security/using_capicom.asp?frame=true.

Deploying Smart Cards

For information about deploying smart cards in Windows Server 2003, see the topic titled "Checklist: Deploying smart cards for logging on to Windows" in Windows Server 2003 Help and Support.

Deploying User Certificates

To install a user certificate, an issuing CA must be present to issue certificates. Once the issuing CA is configured, you can install a user certificate in the following ways:

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

   This method allows a single point of configuration for the entire domain. All users that correspond to members of the domain automatically request the user certificate through a Group Policy setting. To immediately obtain a user certificate for a computer running Windows Server 2003 or Windows XP that is a member of the domain for which auto-enrollment is configured, restart the computer or type gpupdate /target:user from a command prompt. To configure an Active Directory domain for automatic enrollment of computer certificates, see the topic titled "Checklist: Configuring certificate autoenrollment" in Windows Server 2003 Help and Support. Autoenrollment of user certificates requires Windows Server 2003, Enterprise Edition. Computers running Windows 2000 do not support autoenrollment of user certificates.

2. By using a Web browser to request a user certificate.

   For more information about requesting a user certificate, see the topic titled Submit a user certificate request via the Web in Windows Server 2003 Help and Support. The issuing CA must support Web enrollment of certificates. For example, if you are using a Windows Server 2003 enterprise CA as an issuing CA and the CA computer is also running Internet Information Services (IIS), you can use Web enrollment to request a user certificate.

3. By using the Certificates snap-in to request a user certificate.

   If you are using a Windows Server 2003 enterprise CA as an issuing CA, you can request a user certificate using the Certificates snap-in. For more information about requesting a user certificate using the Certificates snap-in, see the topic titled Request a certificate in Windows Server 2003 Help and Support.

4. By importing a user certificate using the Certificates snap-in.

   If you have a certificate file that contains a user certificate, import the user certificate using the Certificates snap-in. For more information about requesting a user certificate using the Certificates snap-in, see the topic titled Import a certificate in Windows Server 2003 Help and Support.

5. By executing a CAPICOM script that requests a user certificate.

   In this method, each user must execute a CAPICOM script that requests a user certificate from the issuing CA.

Deploying Internet Infrastructure

Deploying the Internet infrastructure for remote access VPN connections consists of the following:

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

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

• Add address records to Internet DNS.

Placing VPN Servers in Perimeter Network or on the Internet

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

Installing Windows Server 2003 on VPN Servers and Configuring Internet Interfaces

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

Adding Address Records to Internet DNS

To ensure that the name of the VPN server (for example, vpn.microsoft.com) can be resolved to its proper IP address, either add DNS address (A) records to your DNS server (if you are providing DNS name resolution for Internet users) or have your ISP add DNS address (A) records to their DNS server(s) (if your ISP is providing DNS name resolution for Internet users). Verify that the name of the VPN server can be resolved to its public Internet IP address when connected to the Internet.

Deploying AAA Infrastructure

Deploying the AAA infrastructure for remote access VPN connections consists of the following:

• Configure Active Directory for user accounts and groups.

• Configure the primary IAS server on a domain controller.

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

Configuring Active Directory for User Accounts and Groups

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

1. Ensure that all users that are making remote access connections have a corresponding user account. This includes employees, contractors, vendors, and business partners.

2. Set the remote access permission on user accounts to Allow access or Deny access to manage remote access by user. Or, to manage remote access by group, set the remote access permission on user accounts to Control access through Remote Access Policy.

3. Organize remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see the topic titled "Nested groups" in Windows Server 2003 Help and Support.

Configuring the Primary IAS Server on a Domain Controller

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

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

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

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

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

4. Add the VPN server(s) as RADIUS clients of the IAS server. For more information, see the topic titled "Add RADIUS clients" in Windows Server 2003 Help and Support. For the IP address of each VPN server, use the intranet IP address assigned to the VPN server. If you are using names, use the internal name of the VPN server (this is not necessarily the same DNS name used by Internet clients). Use strong shared secrets.

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

   For example, to configure a remote access policy that requires L2TP-based VPN connections for members of the Employees group to use MS-CHAP v2 authentication and Triple-DES IPSec encryption, create a typical remote access policy with the following settings:

   Policy name: VPN connections (example)

   Access method: VPN

   Group access: Employees group (example)

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

   Policy encryption level: Select only Strongest encryption

If you are using Network Access Quarantine Control, you can use the MS-Quarantine-IPFilter or MS-Quarantine-Session-Timeout RADIUS vendor-specific attributes (VSAs) to specify quarantine settings. Both of these VSAs are configured from the Advanced tab in the profile properties of the remote access policy that you create for remote access connections.

You can use the MS-Quarantine-IPFilter attribute to configure input and output packet filters to allow only the following:

• The traffic generated by the remote access client notifier component. If you are using Rqc.exe (from Windows Server 2003 Resource Kit Tools) and its default port, then configure a single input packet filter to allow only traffic from TCP port 7250 and to TCP port 7250.

• The traffic needed to access the quarantine resources. This includes filters that allow the remote access client to access name resolution servers (such as Domain Name System [DNS]), file shares, or Web sites.

You can use the MS-Quarantine-Session-Timeout attribute to specify how long the remote access server must wait to receive the notification that the script has run successfully before terminating the connection.

Because the quarantine VSAs can limit network access and automatically disconnect remote access users, you should configure these attributes only after a quarantine Connection Manager package has been distributed and installed on the remote access client computers of your organization.

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

Configuring the Secondary IAS Server on a Different Domain Controller

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

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

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

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

3. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see the topic titled "Copy the IAS configuration to another server" in Windows Server 2003 Help and Support.

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

Deploying VPN Servers

Deploying the VPN servers for remote access VPN connections consists of the following:

• Configure the VPN server's connection to the intranet.

• Run the Routing and Remote Access Server Setup Wizard.

Windows Server 2003 includes enhanced support for the clustering of L2TP/IPSec VPN servers. For more information, see the topic titled "Checklist: Enabling and configuring Network Load Balancing" in Windows Server 2003 Help and Support.

Configuring the VPN Server's Connection to the Intranet

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

Running the Routing and Remote Access Server Setup Wizard

Run the Routing and Remote Access Server Setup Wizard to configure each Windows Server 2003 VPN server using the following steps:

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

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

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

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

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

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

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

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

8. Click Finish.

9. If prompted, start the Routing and Remote Access service.

By default, only 128 L2TP ports are configured on the WAN Miniport (L2TP) device. If you need more L2TP ports, configure the WAN Miniport (L2TP) device from the properties of the Ports object in the Routing and Remote Access snap-in. By default, 128 PPTP ports are also configured. If you want to disable the VPN server's ability to accept PPTP connections, set the number of ports on the WAN Miniport (PPTP) device to 1 and clear the Remote access connections (inbound only) and Demand-dial connections (inbound and outbound) check boxes.

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

If you are using Network Access Quarantine Control, install the quarantine listener component on the VPN server. If you are using Rqs.exe from Windows Server 2003 Resource Kit Tools, modify the Rqs_setup.bat file to include the correct version strings for the version of the network policy compliance script that is being run on the remote access clients. Next, run the Rqs_setup.bat file to install the Remote Access Quarantine Agent service.

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

Intranet Network Infrastructure

Deploying the intranet network infrastructure for remote access VPN connections consists of the following:

• Configure routing on the VPN server.

• Verify name resolution and intranet reachability from the VPN server.

• Configure routing for off-subnet address pools.

Configuring Routing on the VPN Server

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

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

Verifying Name Resolution and Reachability from the VPN Server

From each VPN server, verify that the VPN server can resolve names and successfully communicate with intranet resources by using the Ping command, Internet Explorer, and making drive and printer connections to known intranet servers.

Configuring Routing for Off-subnet Address Pools

If you configured any of the VPN servers with manual address pools and any of the pools are an off-subnet pool, you must ensure that the route(s) representing the off-subnet address pool(s) are present in your intranet routing infrastructure. You can ensure this by either adding static route(s) representing the off-subnet address pool(s) as static routes to the neighboring router(s) of the VPN server(s) and then using the routing protocol of your intranet to propagate the route to other routers. When you add the static route(s), you must specify that the gateway or next hop address is the intranet interface of the VPN server.

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

Quarantine Resources

If you are using Network Access Quarantine Control, designate an internal DNS server, file servers and shares for updated scripts, and Web servers with Web page(s) containing network policy compliance instructions and components.

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

Deploying VPN Clients

Deploying VPN clients for remote access VPN connections consists of the following:

• Manually configure VPN clients

• Configure CM packages with CMAK

Manually Configuring VPN clients

If you have a small number of VPN clients, you can manually configure VPN connections for each VPN client. For Windows 2000 VPN clients, use the Make New Connection Wizard to create the Internet and VPN connections and link them together so that when you connect using the VPN connection, the Internet connection is already made. For Windows XP VPN clients, use the New Connection Wizard to create the Internet and VPN connections.

Configuring CM Packages with CMAK

For a large number of VPN clients running different versions of Windows, you should use the CMAK to create and distribute customized Connection Manager packages for your users. For more information, see the topic titled "Before you start: Understanding Connection Manager and the Administration Kit" in Windows Server 2003 Help and Support.

If you are using Network Access Quarantine Control, create the Connection Manager package to contain the following:

The CM profile contains the following:

• A post-connect action setting that runs a network policy requirements script.

• A network policy requirements script.

  This script performs validation checks on the remote access client computer to verify that it conforms to network policies. It can be a custom executable file or as simple as a command file (also known as a batch file). When the script has run successfully and the connecting computer has satisfied all of the network policy requirements (as verified by the script), the script runs a notifier component (an executable) with the appropriate parameters and, optionally, copies the latest version of the script from a quarantine resource.

  If the script does not run successfully, it should direct the remote access user to a quarantine resource such as an internal Web page, which describes how to install the components that are required for network policy compliance.

• A notifier component

  The notifier component sends a message that indicates a successful execution of the script to the quarantine-compatible remote access server. You can use your own notifier component or you can use Rqc.exe, which is provided with Windows Server 2003 Resource Kit Tools. If you use Rqc.exe, run it from the script with the correct parameters, including the script version.

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