Data Center

Overcome Remote-Access Obstacles With Windows Server 2008

Making the move from IPsec to SSL virtual private networks with Windows Server 2008 can ease COOP preparations.

Illustration: Elizabeth Hinshaw Dr. Thomas W. Shinder, a Microsoft-certified system engineer, is a Microsoft Most Valuable Professional and author of books on Microsoft Internet Security and Acceleration Server, Windows networking and Windows security.

A major weather event, an earthquake, even a terrorist attack could make it impossible for government employees to get to work to do their jobs. This presents a significant threat to continuity of operations because at these times key employees may be needed more than ever to perform their duties.

To solve this problem requires some method of remote access to give employees a gateway to their agency network if they are at offsite locations, such as home offices, field offices or even hotel rooms.

Traditionally, most organizations have relied on Internet Protocol security (IPsec) virtual private networks for such remote services. But the flexibility of the Secure Sockets Layer VPN makes it a promising alternative, particularly if set up properly for Microsoft Windows Server 2008.

IPsec VPN Hurdles

An IPsec VPN lets employees connect to a system as if they were tapping the agency network directly through an Ethernet connection. Besides being virtual and encrypted, the connection is also private; intruders can’t intercept the contents of the communication between the VPN remote user and the VPN server at the agency.

But an IPsec VPN solution for providing continuity also presents obstacles to its use as a universal remote-access service for all key employees who must work from remote locations in the event of a disaster:

• IPsec often has problems with Network Address Translation (NAT) traversal, which can create hiccups if the client system is behind a NAT device.

• IPsec requires that a specific collection of protocols be allowed through the network firewall. This is true whether or not NAT traversal is required.

• IPsec does not work over Web proxies.

• In many cases, the end user’s system requires vendor-specific IPsec VPN client software to connect to the VPN server.

SSL VPN Problem-Solvers

To solve the problems inherent in the IPsec approach, a network security administrator needs a remote-access tool that overcomes the NAT traversal and firewall issues, works through Web proxies and preferably uses a client that is included with the operating system or that can be quickly deployed as a self-installing software download.

In contrast to IPsec VPNs, Secure Sockets Layer VPNs allow connections over TCP 443, which is the default port used for SSL connections. No other ports or protocols are necessary. Almost all firewalls allow outbound SSL so users can access secure Web sites. In addition, many agencies use Web proxies for inbound SSL connections. Finally, many SSL VPN solutions are “clientless” so that any client software required to make the SSL VPN solution can be downloaded as needed, without requiring the user to visit another site to install any software.

Using Server 2008’s SSL VPN

Windows Server 2008 includes a network-level SSL VPN server. The server is available in all versions, although different editions support different numbers of simultaneous VPN connections. The Server 2008 server uses the Point-to-Point (PPP) protocol to support authentication and network-level connectivity and the SSL protocol to provide NAT, firewall and Web-proxy traversal as well as encryption.

But before deploying a Server 2008 SSL VPN, there are a few things to consider:

fact: An SSL VPN requires only that a user run a standard Web browser; for an IPsec VPN, each user’s system needs specialized client software.

• If end-user systems run Windows Vista, the operating system has an SSL VPN client that supports PPP/SSL. Client systems running other OSes will have to use alternative VPN protocols, such as Point-to-Point Tunneling Protocol or Layer 2 Tunneling Protocol.

• To manage multiple remote users, standardize your end-user configuration in advance of the SSL VPN client configuration for your remote-access users. The best way to do this is to use the Connection Manager Administration Kit, which is included with Server 2008. The kit creates an executable file that users can easily install.

• Consider the authentication method you want to use. Because the Server 2008 SSL VPN server uses PPP/SSL, you can take advantage of authentication methods using the Extensible Authentication Protocol (EAP), which supports a wide variety of certificate-based and two-factor authentication.

• Server 2008 supports Network Access Protection for remote access VPN client connections. NAP lets you check the security configuration and integrity of a VPN client system before allowing the machine network access. If the user’s system doesn’t clear the integrity checks, it can be granted a quarantined access that lets the user update the machine or allows the machine to automatically update itself.

• Take into account the agency’s availability requirements for the SSL VPN server. If the remote-access SSL VPN server must be available around the clock, you can use the Windows Network Load Balancing Services to evenly distribute the connection across a number of VPN servers. More important, NLB can be set to automatically reassign connections among VPN servers should one or more go offline.

• Consider using a firewall behind the SSL VPN server that gives you control over what systems VPN users are allowed to access. In addition, consider using an application-layer inspection firewall that will block malware and other exploits from moving over a VPN connection into the agency’s network.

Using PPP/SSL, agencies can provide secure remote access to pivotal systems without having to worry about NAT traversal, Web proxies, firewall configuration or complex client-side setup. Combined with Server 2008’s EAP, NAP and NLB tools, SSL VPNs can help IT enhance security and availability for extended remote-access services.

SSL VPNs by Type

Reverse Web proxy: This type supports only Web applications’ and proxies’ incoming requests to the Web server.

SSL encapsulated protocol gateway: This type lets other protocols be encapsulated with an HTTP SSL-encrypted header. The Outlook RPC/HTTP protocol and the Windows Server 2008 RDP/SSL protocol are examples of this type of SSL VPN server. The protocol gateway removes the SSL encrypted SSL header and forwards the connection using the application’s native protocol.

Port- or socket-forwarding SSL VPN gateway: This type can encapsulate, on-the-fly, almost all protocols to the SSL VPN server. This depends on client-side software that intercepts requests, encapsulates them in an SSL header and forwards them to the SSL VPN server.

Network-layer SSL VPN gateway: This type works like a typical IPsec VPN; the server assigns the VPN client a valid address on the agency network to provide network-level access and access to all protocols and services.