VPN Concentrators: IPSec vs SSL

I remember the days when you could set up dial-up modems and have users connect to your NT 4.0 Server using Remote Access Service (RAS). Combining multiple modems in a multilink to increase bandwidth … it seems so long ago, but it was only about a decade or so. With the Internet, we had the ability to create a VPN, providing a secure connection for users dialing in to their ISP from wherever. As time has passed,

I remember the days when you could set up dial-up modems and have users connect to your NT 4.0 Server using Remote Access Service (RAS). Combining multiple modems in a multilink to increase bandwidth … it seems so long ago, but it was only about a decade or so.

With the Internet, we had the ability to create a VPN, providing a secure connection for users dialing in to their ISP from wherever. As time has passed, the need for greater security over these VPNs has increased. Unfortunately, small businesses usually have a limited amount of funds and/or IT expertise. But that doesn't mean they should ignore the need to secure their VPNs properly. A VPN concentrator -- ideal when you require a single device to handle a large number of incoming VPN tunnels -- may be just what they need.

VPN concentrators typically arrive in one of two architectures: SSL VPNs and IPSec VPNs. Some concentrators only offer support of one protocol or the other, whereas Cisco and other vendors advertise the ability to utilize either with their concentrators.

The traditional tunnel for VPNs relies on IPSec, which resides at the network layer of the OSI model. At this level, a client is considered a virtual member of the connected network and can pretty much access the network as if locally connected. Therein lies a positive aspect of IPSec: Apps run without any awareness that the client is coming from outside the network. The drawback is that additional security controls have to be configured to reduce risks.

For a client to access the IPSec VPN, it must have the client-side software configured. While this adds security, it provides additional cost to implement and leads to additional time and energy spent by tech support. This is what leads many toward an SSL solution.

SSL is already built in to the capabilities of pretty much all computers through Web browsers. Thus, there is no additional work to install and configure the client side. In addition, rather than residing at the network layer, allowing access to all aspects of a network, SSL lets admins allow access a bit more precisely toward applications that are Web-enabled. In addition, admins can establish a finer level of control over uses with SSL VPN connections.

On the negative angle, however, being that you can only utilize SSL VPNs through a Web browser, only Web-based applications will work. With a little bit of work, you can Web-enable additional applications, but this adds to the configuration time and may make SSL an unattractive solution for some.

In addition, SSL applications will not have centralized storage, shared access to resources (like printers), or files and other options that you can achieve through an IPSec connection. Some worry about Web caching with private information being left behind. Thus, you might want to choose a VPN concentrator that lists within its feature sets "automatic cache cleanup after session termination to ensure privacy of data," as the NetGear SSL device does.

So, what do you use and why did you decide to go with that solution?

Copyright © 2008 IDG Communications, Inc.