Skip to main content

Windows Server 2008 R2 Remote Access Options

Published: June 9, 2010

Author: Debra Littlejohn Shinder - Microsoft MVP, Enterprise Security

In today's geographically dispersed business environment, remote access is not a luxury; it's a necessity. From full time telecommuters to executives and sales people who are "on the road again" to employees who occasionally take work home, users need to be able to connect to the corporate network when they're away from the office.  Windows Server 2008 R2 gives you more choices, so you can pick the remote access solution(s) that best fit your organization's needs.

One option is a traditional Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Transport Protocol over IPsec (L2TP/IPsec) Virtual Private Network (VPN) connection, but you can also opt for a Secure Sockets Layer (SSL) encrypted HTTP VPN connection using the Secure Socket Tunneling Protocol (SSTP). Or you can opt for Internet Protocol Security (IPsec) Tunnel Mode with Internet Key Exchange version 2 (IKEv2), which is called VPN Reconnect. Finally, you have the option to go beyond virtual private networking, make it easier and more transparent for users to connect and give administrators more control over remote computers by using DirectAccess, the new technology that could prove to be a "VPN killer." In this article, we'll take a look at how each of these can be deployed and the advantages and disadvantages of each.

Note that part of the selection process will be to determine whether a particular remote access technology will allow clients to actually connect from the locations that they may roam to. For example, PPTP and L2TP are often blocked if your client computers roam behind someone else's firewall. Windows Server 2008 R2 Routing and Remote Access (RRAS) is configured via the RRAS MMC snap-in. Note that if the Network Policy Server (NPS) role is installed, you must use it to configure authentication and accounting providers and create or modify connection request policies. The NPS role is configured via the NPS MMC snap-in. NPS can be used as a RADIUS server, RADIUS proxy, and/or Network Access Protection (NAP) policy server.

In this article:

Traditional PPTP or L2TP/IPsec VPN

PPTP was the first VPN protocol that was supported by Windows, and Windows Server 2008 R2 RRAS still includes support for the remote access VPN PPTP server. L2TP/IPsec was introduced in Windows 2000 Server. PPTP uses the Point-to-Point (PPP) protocol for authentication and Microsoft Point-to-Point Encryption (MPPE) for encryption of data. PPTP is not often used in modern VPN deployments due to security concerns, but it has the advantage of being simple to deploy. If you choose to use PPTP for your VPN, you'll typically need to:

  1. Determine the location on the network for placing your VPN server(s), e.g. on the perimeter network between the local network and the Internet.
  2. Configure the VPN server with two NICs, one to the external network and one to the internal network.
  3. Configure the edge firewall to allow PPTP transmissions to/from the VPN server's external NIC, which include GRE (IP Protocol 47) and TCP port 1723.
  4. Configure RRAS to allow forwarding between the Internet and the local network.
  5. Add DNS address records to the DNS server so the VPN server's name can be resolved to its public IP address.
  6. Configure Active Directory to allow remote access to the users who will be connecting to the VPN server.
  7. Configure the VPN clients.

Microsoft's L2TP/IPsec implementation offers better security; in addition to PPP authentication methods, it uses IPsec for mutual computer authentication. However, IPsec should be deployed using certificates, which requires a Public Key Infrastructure (PKI), so it is more complex to deploy if you don't already have that infrastructure in place. (With PPTP, you only need a PKI if you're using smart card authentication or EAP-TLS authentication). For more granular control over user access, you can use an Internet Authentication Service (IAS) server that uses the Remote Access Dial-in User Service (RADIUS) protocol for centralized authentication, authorization and accounting. To deploy L2TP/IPsec, the steps are as follows:

  1. Deploy a PKI, with at least one certification authority (CA). Larger organization will typically use a two- or three-level hierarchy of CAs; in a small organization, one CA can serve as both root and issuing CA.
  2. Install computer certificates on the authenticating VPN (or IAS) servers).
  3. Install user and computer certificates on the VPN client computers.
  4. Determine the location on the network for placing your VPN server(s), e.g. on the perimeter network between the local network and the Internet.
  5. Configure the VPN server with two NICs, one to the external network and one to the internal network.
  6. Configure the edge firewall to allow L2TP/IPsec transmissions to/from the VPN server's external NIC.
  7. Configure RRAS to allow forwarding between the Internet and the local network.
  8. Add DNS address records to the external DNS server so the VPN server's name can be resolved to its public IP address.
  9. Configure Active Directory to allow remote access to the users who will be connecting to the VPN server.
  10. Configure the VPN clients.

Note that while L2TP/IPsec can be configured to support pre-shared key authentication, this method is not as secure, nor as scalable, as a PKI based solution.

In both PPTP and L2TP/IPsec deployments, if you are using RADIUS authentication, you need to configure the Internet Authentication Service (IAS) server, create remote access policies and add the VPN server(s) as Remote Authentication Dial In User Service (RADIUS) clients of the IAS server.

Back to top

SSL-encrypted HTTP VPN with SSTP

SSL was first introduced as a web-based protocol for creating a secure connection between client and server using asymmetric encryption, often used by web sites to secure financial and other private transactions. SSL-encrypted web sites traditionally use URLs that begin with https: rather than http:.  Today there are actually two different technologies that are commonly referred to as “SSL VPN.”  The first is the type used for publishing web-based applications that users connect to with a browser as the client, where the application’s traffic is transmitted inside SSL-protected HTTP.  This is an application-specific VPN.

SSL can also be used to create VPN tunnels for remote access connections. This second type is more like a traditional VPN, where all traffic sent by the client computer is encapsulated inside SSL-protected HTTP and sent to the organization’s intranet. SSL tunnels can be used to access non-web applications. SSL VPNs became popular in part because there was no need to install a thick VPN client (the SSTP client is now built into Windows) and they were considered more user-friendly than traditional VPNs.

SSL works at the application layer of the OSI networking model. A big advantage is that most firewalls and proxies allow SSL traffic through port 443, so you don’t have to do any special configuration of the firewall to get it to work. Some Internet Service Providers don’t allow Generic Route Encapsulation (GRE) encapsulated packets (used with PPTP) and there can be problems with firewalls, web proxies and Network Address Translation (NAT). Likewise, the IKE traffic and Encapsulating Security Payload (ESP)-encapsulated packets used by L2TP/IPsec may not be able to get through some port restricted firewalls, proxies and NATs.

As the industry trend moved toward SSL-based VPNs, Microsoft came out with a PPP over SSL VPN protocol, Secure Socket Tunneling Protocol (SSTP) that was introduced in Windows Server 2008/Vista SP1. It’s integrated into RRAS and actually uses Transport Layer Security (TLS), which is the successor to SSL.  SSTP can handle both IPv4 and IPv6 packets. It supports Network Access Protection (NAP) and can use the same authentication protocols used by PPTP and L2TP (such as EAP-TLS); however, it is used only for remote client access and doesn’t support site-to-site VPNs.

The SSTP server must have a web site certificate (with the intended purpose of “server authentication”) that will be used by the SSTP client to authenticate the server during the establishment of the SSL session. The SSTP client must trust the certificate used by the SSTP VPN Server. This means the root CA’s certificate must be installed on the SSTP clients. User authentication takes place after the SSL session is established, thus protecting credentials within the encrypted tunnel.

Steps involved in the deployment of SSTP depend on the specific configuration. The following articles contain detailed information for the specified situations:

Note that IIS is not required for the SSL VPN server because it listens to HTTPS directly via HTTP.SYS.

Back to top

IPsec Tunnel Mode with IKEv2 and VPN Reconnect

RRAS in Windows Server 2008 R2, along with the Windows 7 client, supports a new tunneling protocol: IPsec Tunnel Mode with Internet Key Exchange version 2 (IKEv2). This makes VPN connections more reliable by automatically reestablishing the connection when a user has temporarily lost Internet connectivity, and particularly when a client computer changes its IP address. This is a fairly common scenario when a wireless mobile connection is used. With a traditional VPN, the user would have to manually reconnect to the VPN after regaining Internet connectivity, but with VPN Reconnect, the VPN automatically reconnects with no action required on the user’s part.

The typical steps for deploying IPsec Tunnel Mode with IKEv2 and VPN Reconnect are:

  1. Configure EAP or deploy a PKI, with at least one certification authority (CA). Larger organization will typically use a two- or three-level hierarchy of CAs; in a small organization, one CA can serve as both root and issuing CA.
  2. Configure the VPN server with two NICs, one to the external network and one to the internal network.
  3. Install the root CA certificate on the VPN server.
  4. Request and install the server authentication certificate on the VPN server, with both Server Authentication and IP security IKE intermediate extended key usage options, and make sure it is in the machine store.
  5. Install the RRAS role on the VPN server.
  6. If the VPN server will also act as the Network Policy Server, install the NPS role.
  7. Configure the RRAS to make the server a VPN server.
  8. Configure the Network Policy Server to enable and configure the remote access policies for an IKEv2 VPN connection (note that NPS is required if using EAP-based authentication. If you are using machine certificate authentication, NPS is not required).

To configure the Windows 7 client, you’ll need to first create the VPN connectoid with the Set up a new connection or network wizard in the Network and Sharing Center. After the connectoid has been created, you can find it by clicking Change adapter settings in the left pane of the Network and Sharing Center, right clicking the VPN connection and selecting Properties. On the Security tab, you’ll need to select IKEv2 from the dropdown menu under Type of VPN. You can use any of the supported data encryption types. For authentication, you can use either EAP or X.509 machine certificates. Then click Advanced Settings and ensure that the Mobility checkbox is checked. VPN Reconnect will support either IPv4 or IPv6.

Back to top

Beyond the VPN: DirectAccess

DirectAccess is new to Windows Server 2008 R2 and Windows 7, and it is considered by many to be the future of remote access and the eventual replacement for the VPN, at least when it comes to corporate managed computers. Whereas VPN Reconnect made reestablishment of a VPN seamless to the user, DirectAccess goes much further, and makes connection to the corpnet seamless from the beginning. There is no need for a VPN because users are automatically connected to the company network anytime they have Internet connectivity, even when they are behind a web proxy or port restricted firewall. But it’s not only users’ lives that are made easier by DirectAccess; administrators’ jobs are simplified, as well. With DirectAccess, you have more control over the computers that connect to your company network and you can update Group Policy or software on them anytime they’re connected to the Internet – even if the user hasn’t logged on.

Another advantage of DirectAccess over the various VPN types is security. DirectAccess uses IPv6 over IPsec and supports multifactor authentication. IPsec authentication is used for both the user and the computer; a smart card can be used for user authentication. Even though DirectAccess uses IPv6, client computers can still connect to the DirectAccess server on the company network over the IPv4 Internet. The DirectAccess server can be a Windows Server 2008 R2 server or a Forefront Unified Access Gateway (UAG).

DirectAccess can also be configured so that Internet traffic and intranet traffic are separated. Thus communications going to the Internet don’t have to go to the internal network first and then back out to the Internet, as they do with most VPNs. This means better performance. This is the default, but you can choose to send Internet traffic through the DirectAccess server if you prefer. You can also use outbound rules in Windows Firewall with Advanced Security  to control which applications can communicate with the Internet and which internal subnets clients can connect to.

DirectAccess uses two IPsec tunnels. The first is an Encapsulating Security Payload (ESP) tunnel that uses a computer certificate and computer account NTLMv2 authentication to access DNS servers, domain controllers, and other management servers, such as those used for Network Access Protection (NAP) and software updates, so the computer be managed even before the user logs on. The second uses a computer certificate, too, but also uses the user credentials to authenticate the user using Kerberos, and can access the resources and applications on the company network. Clients connect to network resources using either end-to-end or end-to-edge IPsec encryption. The former provides higher security, but the application servers have to be running Server 2008/2008 R2 and have both IPv6 and IPsec enabled. The end-to-edge connection goes from client to gateway (the DirectAccess server) and then sends the packets on to the application servers on the company network, unprotected. The advantage is that you don’t have to have IPsec and IPv6 deployed on the internal network, and can connect to IPv4-only servers (if you are using Forefront UAG and its NAT64/DNS64 technologies). DirectAccess clients must be Windows 7 Enterprise or Ultimate edition computers.

To deploy Windows Server 2008 R2 DirectAccess, you must:

  1. Deploy a PKI to issue computer certificates (and smart card certificates and NAP health certificates, if you use those technologies) and configure for autoenrollment of computer certificates.
  2. Deploy Network Location Servers (essentially just SSL web sites) that are used by the DirectAccess client to determine if they are on the corporate network or not.
  3. Ensure that the DirectAccess server is joined to an Active Directory domain where at least one domain controller and one DNS server run Windows Server 2008/2008 R2.
  4. Create AD security groups for DirectAccess clients and (optionally) selected servers.
  5. Configure packet filtering on firewalls.
  6. Configure the DirectAccess server with two NICs, one connected to the Internet and one connected to the internal network.
  7. Configure at least two consecutive public IP addresses on the external NIC.
  8. Add DNS address records to the internal-facing and external (Internet) DNS servers so DirectAccess clients can locate the server components.
  9. Install a computer certificate with computer authentication Enhanced Key Usage on the DirectAccess server (used to authenticate for IPsec).
  10. Install an SSL certificate for IP-HTTPS authentication.

The DirectAccess Setup Wizard will guide you through the steps of configuring the DirectAccess server for intranet access, selected server access, or end-to-end access. For detailed instructions on how to deploy Windows Server 2008 R2 DirectAccess in each of these scenarios, see the DirectAccess Deployment Guide at http://technet.microsoft.com/en-us/library/ee649163(WS.10).aspx

It is important to note that the Windows DirectAccess solution is not designed for an enterprise environment due to its lack of support for arrays, high availability, centralized configuration or support for non-IPv6 resources. For enterprise deployments of DirectAccess, Microsoft recommends Forefront UAG DirectAccess. Forefront UAG DirectAccess includes a number of technology enhancements that makes DirectAccess “enterprise ready”. For more information on UAG DirectAccess deployment scenarios and consideration, please see the UAG DirectAccess Design Guide at http://technet.microsoft.com/en-us/library/ee406191.aspx

Back to top

Summary

Windows Server 2008 R2 provides more remote access options than ever before. From legacy methods such as dial-up remote access to the most modern DirectAccess technology, you can choose the best way to give remote users access to your corpnet based on your organization’s needs, including bandwidth considerations, existing infrastructure, compatibility issues, user and administrative ease of use, and whatever other criteria matter to you. Best practice is to combine these approaches to give your users the most flexible remote access experience. For example, configure your organization’s computers to use DirectAccess if they are joined to an Active Directory domain and set up Windows so the users can default to using VPN Reconnect as the primary VPN, but fall back to SSTP and then to PPTP in situations where VPN Reconnect might be blocked by an intervening firewall.

All of the server and client software required to deploy these access methods comes with the Windows Server 2008 R2 operating system, and Windows desktop operating systems include client software for some or all, depending on the client OS version.

Back to top

About the Author

Debra Littlejohn Shinder photo Debra Littlejohn Shinder is a technology trainer, author, and consultant. She is owner and CEO of TACteam, which provides white papers, marketing materials, product documentation, online training courses, and more, for companies such as Microsoft, Sunbelt Software, GFI, Network Engines, Hewlett-Packard, Intel, and 2X Software.

Deb is the author of Computer Networking Essentials (Cisco Press) and Scene of the Cybercrime (Syngress). She is also coauthor of or contributor to 26 other technology books including the bestselling Configuring ISA Server 2000 and Configuring ISA Server 2004 with husband Tom Shinder.

Deb has published hundreds of articles in TechRepublic, CNET, Windows & .NET Magazine, Windows IT Pro Magazine, ComputerWorld, and other print and online publications. She is editor of WXPNews, Win7News, a lead author at Windowsecurity.com and ISAServer.org, and a contributor to several technology blogs.

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.
Microsoft réalise une enquête en ligne pour comprendre votre opinion sur le site Web de. Si vous choisissez de participer, l’enquête en ligne vous sera présentée lorsque vous quitterez le site Web de.

Souhaitez-vous y participer ?