L2TP Remote Access

For many years, I lived with PPTP as my remote access VPN protocol, despite its security weaknesses. With the arrival of Windows 2000, I looked forward to trying Layer Two Tunneling Protocol (L2TP) but I soon became painfully aware of some problems when using L2TP with Network Address Translation (NAT)—more about that later.

You can use L2TP to establish a fully manageable, highly secure remote access VPN that supports Windows 95 and later clients. You will, however, need to tackle certain problems associated with remote users who are behind a NAT firewall, client configuration, certificate configuration, authentication, and locking everything down. Keep in mind that while I was writing this article, I used the beta version of Windows Server 2003; the final version is now available. Let's begin by looking at L2TP as a core component of a secure remote access VPN.

Advancing Encryption Protocols
PPTP is vulnerable to man-in-the-middle attacks related to data integrity and data origination, but the biggest problem is that it supports only single-factor, password-based authentication. As a result, if an intruder steals or guesses an employee's password, that intruder can access your company's network. Two-factor authentication, which consists of something you know (e.g., a password) and something you have (e.g., a secure key card, a certificate), is much more difficult to compromise. You can use Extensible Authentication Protocol–Transport Layer Security (EAP-TLS) in Windows XP and later with PPTP and thereby replace user passwords with user certificates. However, PPTP with EAP-TLS is still single-factor authentication and doesn't address PPTP's network vulnerabilities. Also, certificates aren't portable. As a result, if a user needs to borrow a coworker's notebook or you need to replace a broken laptop for a user who's on the road, you run into complications because you must install the user-specific certificate on the computer before that user can connect to the VPN to access your network.

Although Microsoft has bandaged PPTP over the years to keep it viable (see "Is PPTP Safe?," May 1999, http://www.winnetmag.com, InstantDoc ID 5188), L2TP relies on a much more solid, standards-based foundation of strong two-factor authentication, encryption, and data integrity. When you use L2TP to connect to a VPN server, L2TP uses the client and server computers' certificates to authenticate the systems. Upon successful authentication, L2TP sets up an IP Security (IPSec) connection in Encapsulating Security Payload (ESP) mode. (As you might be aware, IPSec is a highly respected protocol that provides privacy, data integrity, and authentication for every packet.) To this point, L2TP has encrypted all of the data traveling through the VPN on the Internet, protected the connection from man-in-the-middle attacks, and completed the first level of authentication. If you're concerned about the obvious requirement to provision all your computers with certificates, don't be—Microsoft provides some great tools (e.g., Group Policy to automate certificate enrollment, Connection Manager Administration Kit—CMAK—to automate the rollout of VPN clients) to help you accomplish this task and many others that relate to deploying an industrial-strength remote access VPN.

Next, L2TP authenticates the user. You have several methods to choose from, but let's discuss using the user's network account password. You must also select which authentication protocol L2TP will use to verify the user's password. At first glance, that decision might seem unimportant because you're already using IPSec. However, don't forget that your VPN server must communicate with the domain controller (DC) to complete user-level authentication. As a result, the authentication protocol can be an important factor in protecting the user's password from being stolen by an eavesdropper on your internal network. After L2TP successfully authenticates the user, you'll have a secure tunnel over the Internet to your network; this tunnel will provide the same access you have when you connect locally, albeit a bit slower.

Although I was excited about the arrival of L2TP with Win2K, I soon discovered a problem. After I set up L2TP, I was able to connect to my VPN server from the road when I connected to the Internet through my global ISP. However, when I plugged in my laptop to a client's LAN and tried to connect to my VPN server, L2TP failed with error code 791: The L2TP connection attempt failed because security policy for the connection was not found. The problem occurred because like many companies, my client uses NAT to hide the internal network from the Internet. Because NAT changes TCP and UDP port numbers when you pass packets between the Internet and intranet, IPSec's data-integrity checking fails with L2TP. This limitation prevents many companies from using L2TP as a viable remote access protocol because many remote users connect from other business partner LANs or from home networks, both of which commonly use NAT.

To solve this problem, industry leaders, including Microsoft, Nortel Networks, F-Secure, and Cisco Systems, developed NAT-Transversal (NAT-T); a draft document for this new standard is available at the Internet Engineering Task Force (IETF) Web site at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt. NAT-T provides a way for two computers to detect the presence of one or more NAT devices between them and then switch to encapsulating the usual IPSec packets inside UDP port 4500 packets. At the time of publication, Microsoft plans to support Win98 and later as VPN clients by using L2TP with NAT-T. Although you can use earlier clients and Win2K DCs and Certificate Authorities (CAs), your VPN server must run Windows 2003.

Creating a Sample L2TP VPN Configuration
To demonstrate how to set up an L2TP VPN, let's look at a sample configuration. For starters, let's assume our domain is hosted by Win2K DCs with a mix of XP, Windows NT, and Win9x clients all on one LAN segment, as Figure 1 shows. To provide L2TP/NAT-T–capable access to remote users, you need to add a Windows 2003 server. All Windows 2003 editions, except for Windows 2003, Web Edition, support at least 1000 simultaneous VPN connections.

In our sample configuration, the Windows 2003 VPN server connects directly to the Internet. You can deploy the VPN server either in front of the firewall or inside the demilitarized zone (DMZ)—Microsoft provides information for configuring packet filters on your firewall and VPN server to accomplish either scenario. The firewall and VPN server can even reside on the same computer. In our example, the VPN server also connects to the intranet, so we'll need to tightly lock down the server so that attackers can't break into the internal network.

In addition to the Windows 2003 VPN server, we need to install Internet Authentication Service (IAS), which is Microsoft's implementation of a Remote Authentication Dial-In User Service (RADIUS) server, on one of the existing Win2K DCs so that the VPN server can use RADIUS to authenticate remote users against their accounts in the Win2K domain. For the final server-based component, we must install Certificate Services so that we can provide computer certificates to the VPN server and remote client computers. For XP and Win2K clients, you need to install the IPSec NAT-T update. Because XP and Win2K already support L2TP and IPSec, this update simply adds support for IPSec to NAT-T devices. For NT and Win9x clients, you need to install the Microsoft L2TP/IPSec VPN Client, which is available at http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp.

Configuring CA and IAS in the Win2K Domain
Before we set up the VPN server, let's establish the CA. You can select any server in the domain, including DCs, as the CA. Certificate Services can install either a standalone CA or an enterprise CA. In enterprise mode, Win2K and later computers in the domain will automatically trust certificates that the CA issues. This mode also lets you automatically deploy these certificates to Windows 2003, XP, and Win2K computers. In our sample network, we'll install Certificate Services on the ad1 DC, as Figure 1 shows.

To install Certificate Services, log on to the server, open the Control Panel Add/Remove Programs applet, then select Add/Remove Components to start the Windows Component Wizard. Select the Certificate Services check box, click Next until you reach the Certification Authority Type screen, select Enterprise Root CA as the first CA, then proceed through the rest of the wizard. Because Certificate Services requires Microsoft IIS, if you haven't already installed IIS, Win2K will install it. Within a few hours after you create the enterprise CA, each Win2K and later computer in the domain will automatically add a self-signed certificate to its Trusted Root Certification Authorities certificate store, thereby establishing a trust with all certificates presented by other computers that your CA has signed.

Next, you need to deploy certificates to the client computers that will use the VPN to connect to the network so that they can set up the initial IPSec link to the VPN server. To deploy certificates to Win2K and later computers that are part of the domain, you can use Group Policy. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, select the root of the domain, and deploy a certificate to every computer in the domain. (Optionally, you can select the organizational unit—OU—that stores information about all the remote computers.) Right-click the domain name, select Properties to open the properties for the domain root, then select the Group Policy tab. Under the Default Domain Policy Group Policy Object (GPO), navigate to Computer Configuration\Windows Settings\Security Settings\Public Key Policies, right-click Automatic Certificate Request Settings, select New, then select Automatic Certificate Request. The Automatic Certificate Request Setup Wizard will open and ask you which certificate template and CA you want to use. Select the Computer certificate template, select your new CA, then finish the wizard to complete the process of adding a new request to the local CA. Now, each computer that applies this GPO will automatically request a certificate from the CA without further action on your part. The CA automatically approves the request because default permissions on the Computer certificate template let DCs request a certificate, and the computer can use Kerberos to automatically authenticate to the CA because both computers are part of the same domain.

To deploy certificates to pre-Win2K computers and employee-owned systems used for telecommuting, you must manually request and install the client computer's certificate as well as the CA's certificate. To make this request, you can use the certificate server's Web site, which is available at \\computername\certserv.

Next, you need to install IAS on the DC to handle authentication requests from the RADIUS-enabled VPN server. Open the Add/Remove Programs applet again, then select Add/Remove Components. This time, select Networking Services, then select Details. Select the Internet Authentication Service check box and continue through the wizard. After you install IAS, you must configure it to accept RADIUS requests from the VPN server, which is a client of the IAS server. Open the Internet Authentication Service snap-in, right-click the Clients folder, then select New Client. Enter the name of the VPN server (in this example, I entered the name testras), then click Next. When prompted, add the client name in the RADIUS Client dialog box (in this example, I entered the name testras.ad.local), change the Client-Vendor setting to Microsoft, then enter a string of characters that you want to use as the shared secret. The shared secret limits authentication requests to only the legitimate VPN server on which you'll enter the same shared secret to authenticate with the domain. Win2K also uses this secret to encrypt and confirm the integrity of data sent between the VPN server and the RADIUS server. The shared secret protects sensitive RADIUS traffic from prying eyes and meddling fingers as it travels on the internal network. Microsoft recommends making the secret at least 22 characters long, consisting of upper- and lowercase letters as well as numbers and symbols. After you've entered the shared secret, click Finish to exit the wizard.

The DC is now ready to accept requests from the VPN server, but before you get too far, you need to make one security tweak that the IAS wizard fails to do. Open the Internet Authentication Service snap-in, then select the Clients folder. Double-click the client record for the VPN server to open the server's Properties dialog box, which Figure 2 shows, then select the Client must always send the signature attribute in the request check box. Enabling this setting ensures that Windows uses maximum protection for RADIUS traffic on your internal network by forcing the client to authenticate each request and providing the RADIUS server with a way to ensure that the request wasn't modified in transit.

Setting Up the VPN Server
After you configure CA and IAS, you can set up the VPN server. The server should have two network adapters. Connect one adapter to the intranet and leave the other one disconnected—for security purposes, we won't connect the second adapter to the Internet until after we've locked it down. Install Windows 2003 with default settings (we'll adjust these later), and make sure you enter a long, hard-to-guess password for the local Administrator account. During setup, let the server obtain a DHCP address, then join the computer to your domain. After installation is complete, log on as a domain administrator. Open the Network Connections folder and rename the network adapters so that you can easily distinguish the Internet and intranet connections. Next, configure the intranet connection with a static IP address and the appropriate subnet, DNS, and default gateway. You can use DHCP for your VPN server on the intranet, but the configuration is more complex and Microsoft recommends that you use a static address. Next, configure the Internet connection with the appropriate IP address, subnet, and default gateway as provided from your ISP. If you want, you can connect a hub to the Internet side of the VPN server, then connect another computer to simulate the Internet. If you give the computer an address within the same subnet as your VPN server, you'll be able to use that computer as a test client and run port scans or vulnerability scanners against your VPN server after locking down the server as a final check before connecting it to the Internet.

After you configure the network adapters, you need to set up Routing and Remote Access. Open the Routing and Remote Access snap-in, right-click the server you want to use for Routing and Remote Access, then select Configure and Enable Routing and Remote Access to start the Routing and Remote Access Server Setup Wizard. Select Remote access (dial-up or VPN), then click Next. On the Remote Access screen, select the VPN check box, clear the Dial-up check box, then click Next. On the VPN Connection screen, which Figure 3, page 63, shows, select the Internet connection, select the Enable security on the selected interface by setting up static packet filters check box, then click Next. On the IP Address Assignment screen, specify how the VPN server will assign IP addresses from your intranet to VPN clients. You can choose to have the VPN server lease an address from your DHCP server on your behalf or have the VPN server assign an IP address from a range of addresses you reserve on your network for VPN clients. Using DHCP is the simplest method. However, you might want to consider using a reserved range of addresses for two reasons. First, you'll be able to easily identify any VPN client traffic on your intranet simply by the source IP address (whereas if you use DHCP, your VPN client addresses will be mixed in with your local LAN clients). Second, if you want to provide added protection for sensitive servers in your network that don't need to be accessible to remote users entering the network through the VPN, you can configure packet filters on those computers that block packets from within the VPN client range. That way, if someone uses your VPN server to successfully break into your intranet, the intruder won't be able to attack your sensitive servers directly. After making your choice, click Next.

If you chose an address-range assignment, the wizard will prompt you to enter the range; otherwise, the wizard will ask you whether you want to authenticate using Routing and Remote Access or a RADIUS server. While researching this article, I initially chose to use Routing and Remote Access to avoid adding another component to the mix. However, this selection led to some authentication errors that disappeared when I switched to using a RADIUS server. Choose RADIUS, then click Next. The wizard will ask you for the DNS name of your RADIUS server and the shared secret. In our example, I used the DC name, ad1.ad.local, which is the machine on which I installed IAS, and the shared secret that I entered earlier on the IAS server. If you want to guard against VPN outages that can result when a DC goes down, you can install and configure IAS on another DC and specify the DC here as the Alternate RADIUS server. Click Next and review the wizard summary. When you click Finish, Win2K will start Routing and Remote Access.

Locking Down the VPN Server
Although the server is now ready to accept VPN connections, you'll want to lock it down before you connect to the Internet. In the Routing and Remote Access console, open the VPN server's Properties dialog box and clear the Router check box. Select the Security tab, then click Configure next to the Authentication provider drop-down list. When you see the RADIUS Authentication dialog box, select your RADIUS server and click Edit. The VPN server will be configured to use the RADIUS server, but the Always use message authenticator check box isn't selected by default. As Figure 4 shows, I've selected this check box. Because this check box isn't selected by default, Windows might not use the shared secret that you entered earlier when you set up RADIUS on this server and IAS on the DC. For maximum protection against someone tampering with your VPN and IAS traffic, select this check box. Next, select the Logging tab from the Properties dialog box and enable logging for all events so that you can track VPN usage. Click OK and let Routing and Remote Access restart. Right-click the Ports folder in the Routing and Remote Access snap-in, then select Properties from the context menu to open the Ports Properties dialog box, which Figure 5 shows.

Next, you need to shut down any outgoing or incoming VPN connections except for incoming L2TP remote access. Open the properties for WAN Miniport (PPPOE) in the Ports Properties dialog box, clear the Demand-dial routing connections (outbound only) check box, then click OK. Next, open WAN Miniport (PPTP), clear the Demand-dial routing connections (outbound only) check box, clear the Remote access connections (inbound only) check box, then click OK. Perform the same actions for Direct Parallel.

Now, the only way into the VPN server is through an L2TP remote access connection. Open WAN Miniport (L2TP) in the Ports Properties dialog box, then clear the Demand-dial routing connections (outbound only) check box. Determine how many concurrent connections you want to support, configure the maximum ports accordingly, then click OK twice. Navigate back to the Routing and Remote Access console, then right-click the IP Routing folder. Next, from the context menu, select Properties to view the properties for the Internet interface. From here, you can explore inbound and outbound filters that prevent unauthorized traffic from being routed through the VPN server.

Configuring the Windows 2003 Basic Firewall
To provide further protection against attacks from the Internet, you might want to enable Windows 2003's basic firewall. After you enable Routing and Remote Access, Internet Connection Firewall (ICF) and Internet Connection Sharing (ICS) will be unavailable. For stateful packet inspection and NAT functionality, Routing and Remote Access provides the NAT/Basic Firewall option instead. To enable this option, right-click the IP Routing folder, select Properties, select the General tab, then select New Routing Protocol. In the New Routing Protocol dialog box, select NAT/Basic Firewall, then click OK. You'll see NAT/Basic Firewall added as a folder under IP Routing. Right-click the NAT/Basic Firewall, then select New Interface. Select the Internet interface from the list, then click OK. The Network Address Translation Properties dialog box appears, as Figure 6 shows; select Basic firewall only because we don't want clients on the intranet to access the Internet through the VPN server. Also, click Inbound Filters and delete all filters referring to protocol 47 (GRE) or TCP port 1723 (PPTP). Both of these ports support PPTP, and even though we've disabled PPTP in Routing and Remote Access, the basic firewall still allows that traffic by default. Click Outbound Filters in the Network Address Translations Properties dialog box, and delete the same entries. Next, select the Services and Ports tab. This tab lets you configure which types of traffic the basic firewall permits. Select the VPN Gateway (L2TP/IPSec – running on this server) check box, then click Edit. In the Edit Service dialog box, enter the address of the VPN server's internal network adapter. After you finish configuring the basic firewall, click OK.

Implementing Domain and Local Computer Security
At this point, your server is tightly locked down against attacks from the Internet; your VPN server should respond only to IPSec-related traffic. You can prove this response by running a port scan such as Insecure.org's Nmap. You're almost ready to connect your VPN server to the Internet. But before doing so, give attention to some domain and local computer-related security measures.

Thankfully, Windows 2003's default security settings are much stronger than Win2K's, but you should still perform a general hardening of the VPN server. Enable auditing and configure your security so that you can track security events. Make sure the local user accounts don't have RAS dial-in access. Also, set a strong account-lockout policy. Use a strong password for the local Administrator account, and disable the Guest account and any other unneeded local accounts. You'll also want to disable any unneeded services. I recommend that you use a GPO rather than a direct configuration to make these changes so that the settings will persist, even if you replace the server or deploy more servers in the event that your VPN needs to grow.

At the domain level, enable RAS dial-in access only for appropriate users who need remote access, and mandate strong password requirements for those users. Because a remote user authenticates to the VPN server with the same account that he or she uses to log on locally at the office, attackers can use Denial of Service (DoS) attacks to lock out one or more accounts through failed logon attempts to the VPN server. With Windows, you can handle remote access–account lockouts separately so that external attackers can't lock out domain accounts for use on the local LAN but instead are locked out from the VPN server. You can enable this special handling for remote access lockouts by configuring the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout registry setting. (For details about configuring this setting, see the Windows documentation at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/datacenter/sag_rras-ch1_74.asp.)

After you connect your VPN server, you can try connecting from various clients. I recommend that you start by connecting from a client that dials in directly to an ISP so that you aren't crossing a NAT device. Remember to update your clients with either the Microsoft L2TP/IPSec VPN client on pre-Win2K computers or the IPSec NAT-T update on Win2K and later computers. Also, make sure that your client has a computer certificate installed and that the CA's certificate is in its Trusted Root Certification Authorities folder. Then, open Network Connections and use the New Connection Wizard to create a connection to your VPN server. Configure the connection to use L2TP and try it out using a domain account that you've enabled for dial-in access. If you can successfully connect, try next to connect from behind a NAT device (e.g., a home network firewall, a business partner's location).

Sharing a Few Troubleshooting Tips
Whenever you make a configuration change to Routing and Remote Access or IAS, I recommend restarting the service to make sure that your change takes effect immediately. You can use the Security and System logs on your client and on the VPN server as well as the IAS log on the IAS server (in the \%winroot%\system32\logfiles directory) to troubleshoot connectivity problems that you might encounter. IAS logs begin with IN and are best viewed using the IASParse tool that comes with the Microsoft Windows 2000 Server Resource Kit. Enjoy setting up dual-factor authentication for a remote access VPN that even survives crossing NAT boundaries.