IPSec Vs. SSL: Picking The Right VPN

You're comfortable with the security of your network inside the office, but how do you feel about a salesman using his laptop to access your network from the local Starbucks?

It's easy to control security within the physical walls of your plant, but providing secure remote access to internal resources for externally connected users is more difficult. IPsec (IP security) and PPTP (Point-to-Point Tunneling Protocol) VPNs, and sometimes SSH tunneling, are enough, but these setups often have problems with NAT (Network Address Translation) traversal, firewalls and client management. An SSL (Secure Sockets Layer) VPN should solve those problems while still providing robust and secure remote access. However, an SSL setup comes with its own difficulties, such as problems with browser support, required increased privileges on the client computer for anything other than pure HTTP applications and the inherent security problem of cached data on the browser. For more information, see "ABCs of Remote Access".

Compare and Contrast

IPsec is a Layer 3 VPN: For both network-to-network and remote-access deployments, an encrypted Layer 3 tunnel is established between the peers. An SSL VPN, in contrast, is typically a remote-access technology that provides Layer 6 encryption services for Layer 7 applications and, through local redirection on the client, tunnels other TCP protocols. From a purely technical standpoint, you may be able to run both IPsec and SSL VPNs simultaneously, unless both the IPsec and SSL VPN products use installed client software on the user's computer. In that case, you may have stack conflicts.

Organizations often base their VPN choice on cost, configuration and usability. If you're looking for a network-to-network VPN, the only real choice is IPsec. Check Point Software Technologies, Cisco Systems, Juniper Networks, Nortel Networks, Sonicwall and WatchGuard all offer IPsec VPNs with integrated firewalls. If you go this route, look at the vendor's customer-support track record, determine if security is built into its product and find out what features will be available down the line.

The Easier Path?

IPsec VPN solutions generally are a lot easier to manage. The client-to-gateway tunnel forms a network connection similar to that of dial-up networking. Ephemeral TCP/UDP ports are natively supported. If your traveling users are employing SIP (Session Initiation Protocol)- or H.232-based applications, IPsec has a clear advantage over SSL VPN because it's hands-free on the client side. Once the software is running, users interact with their software and remote services seamlessly.

The IPsec VPN is an open network from the desktop client to the destination network, but that doesn't mean the desktop is just an IP router. Because of the possible split tunneling problem--simultaneous access to a trusted and a nontrusted network--you can limit access through policies set on the IPsec gateway. However, as SQL Slammer demonstrated, a worm-infected host that connects to an internal network over IPsec can infect the internal network. Use the embedded IPsec gateway firewall or place a firewall between the gateway and the rest of the network for added protection.

The leading IPsec VPN gateways from Cisco and Nortel are easy to manage and offer hierarchal group management, tight integration with external authentication servers and extremely useful and detailed event logging on the gateway. The latter is critical when troubleshooting remote-user connection problems. However, an IPsec VPN may cost you more in the long run. Let's consider license costs: An IPsec VPN typically costs between $10 and $25, while an SSL VPN ranges from $50 to $120 per seat for a 500-user license. At first glance, IPsec VPN seems appealing costwise. But once you factor in the costs for deploying and managing an IPsec client, the additional testing required prior to patching an OS client (remember the Windows XP Service Pack 2 broke many client applications including IPsec) and the lost productivity from users who can't connect to the gateway over IPsec, it may not look like such a bargain. Additionally, many IT managers have found IPsec VPNs to be time-consuming for their staffs to maintain, because end users often need help when downloading software or maintaining their connections.

Going SSL

Most users make the jump to SSL VPNs when building extranets because of the attractive price and reduced security risks. SSL can restrict remote access to only those resources a user needs.

In fact, one out of every three major companies was using an SSL VPN this year, according to Meta Group. By 2006, 80 percent of companies will use SSL VPNs as one means of connectivity, the researcher says. There's no doubt SSL VPNs are selling like gelato in the summer and perhaps the biggest drivers are universality over Port 443 and reduced management overhead.

Take your laptop anywhere--home, a customer site, the coffee shop--and Internet access over TCP 443 (the default HTTPS port) should be available, unless you're on a network with a strict egress policy. With SSL VPN's ubiquitous access, any computer with a browser and Internet access can be a client. We're not convinced most organizations want to open their critical business applications to users at public kiosks, but being able to let remote or traveling users access their Web mail and other applications is compelling. Nearly every SSL VPN product enables and encourages tight access-control policies--in fact, it's often difficult to allow open access. When a resource is added, specific access rights for it must be defined. For non-HTTP applications, that typically involves a quick address/port definition. However, depending on the product, HTTP application access can be controlled down to the URI (Uniform Resource Identifier) and the method used to access the resource. For example, if a user can access a Web server, but not the /admin directory, the SSL VPN gateway won't grant the access, thus adding another layer of protection to Web server permissions. Similar access controls can be applied to ftp and Windows file sharing.

Typically, access to resources can be granted or denied based on the client's location, whether it is up-to-date on OS patches or whether it can load the SSL VPN gateways mobile code for cache cleaning. Advanced protection features, such as URI access control and dynamic ACL (access control list), vary by vendor.

For those users who need secure access to non-HTTP applications, SSL VPN products offer two methods. With the so-called "clientless" method, the user downloads a Java or ActiveX component within his or her browser, setting up a proxy on a local-host address (for example, 127.0.0.1), and temporarily modifies the local hosts file to resolve host names to the local-hosts address. The user access level required on the client to start the local proxy on a port below 1023 and change the local hosts file varies with each product--most require local administrator access. Additionally, UDP protocols are rarely supported by SSL VPN products, so be sure you have a firm grasp on your application requirements and ensure the SSL VPN gateway will support them. Don't overlook in-house developed applications. The best practice would involve a detailed log of all applications, testing SSL VPNs with as many as possible.

If you want to go the tried-and-true route, use installed clients on the client and forward sensitive packets over the SSL VPN. Aventail and Juniper support this method. However, there's nothing to download or install and you don't need to jump through any hoops with the user's privileges.

Having It Both Ways You can use both IPsec and SSL VPN. If your primary applications are Web-based and you support only a few non-HTTP applications, SSL VPN is a good option: The ease of use is far greater and the fine-grained access control for remote users is superior to IPsec products. But if your organization must support more complex applications and site-to-site VPN, you really can't axe the IPsec just yet.

Mike Fratto, Editor [email protected]Myth Understandings

Myth #1: IPsec VPN opens an unrestricted pipe into the network. This depends on the VPN gateway. IPsec works over Layer 3 to transport IP packets bound for the protected network. So in one sense, it is an open pipe. However, most IPsec VPN gateways have internal, stateful packet-filtering firewalls so traffic can be restricted to specific destinations. To achieve the same results, you could place the VPN in a DMZ with strict access rules.

Myth #2: IPsec VPNs don't play well with NAT. For several years, vendors have been encapsulating IPsec traffic into UDP before putting it on the network, so NAT problems aren't as prevalent as they once were. Standardized NAT traversal is an optional component of IKE (Internet Key Exchange) 2, and many vendors have adopted proprietary traversal methods.

Myth #3: SSL VPN is a clientless VPN. This is true only for straight HTML traffic. Web applications that use mobile code components (such as Java applets or Flash), which make connections back to the server, or non-HTTP apps often require a client browser component to tunnel traffic over the SSL VPN. In many cases, the remote user must be logged on as a local administrator to run the component dynamically or it must be installed by an administrator. Myth #4: SSL VPNs provide secure access from any computer. Again, this is only true of HTML traffic. Many kiosks don't let users run as administrators or install components into the browser. Besides, do you really want your users to download confidential company data to an unmanaged computer?