In life, rarely is anything black or white, and when designing and building an enterprise data network, remote access and security are no exceptions to this fact of life.

For networking managers seeking to define the “right” VPN (or protocol) choice or direction to avoid a potential misstep, there is good news. The prevailing VPN protocols—IPsec and SSL— are actually complementary, not competitive, as many industry manufacturers might lead enterprise customers to believe.

In fact, many IT managers will find they’re better off not trying to move in one specific direction to standardize on one VPN access type. This narrow view will most likely lead to shoe-horning one technology or protocol type beyond its acceptable use.

The emergence of SSL VPN as a secure and highly flexible means to providing secure access to enterprise resources has clearly changed the traditional enterprise remote access VPN landscape. The ability to provide a customized and dynamic Web portal front-end for users, without having to deploy and configure a traditional VPN client to either managed (employee) or unmanaged (partners) user and devices, is an extremely compelling value proposition for a wide enterprise audience.

It is when enterprises begin to consider SSL VPN for broader deployment requirements with wider application support, coupled with the increased need for security, that some of the initial SSL VPN advantages start to become far less compelling from a deployment perspective.

Let’s take a closer look at some of the deployment considerations enterprises need to be aware of when considering using SSL to provide secure access to non-Web enabled applications.

Because SSL was designed to encrypt Web traffic only, getting non-Web applications to work through SSL requires some help on the local PC to “redirect” the application traffic through the SSL tunnel. That help is often provided via a temporary JAVA or Active X “client” download. The Active X client download listens for certain application traffic, captures it and redirects it back through the SSL tunnel to the SSL VPN gateway back at the enterprise. Some vendors even offer another SSL VPN access method that provides network level (IPsec-like) secure access. This feature provides the client PC with a downloadable virtual IP adaptor with an internal address that allows all user traffic destined for the internal network to be directed through the SSL VPN tunnel.

So, what can often initially start out as a “client-less” SSL VPN design promising vastly simplified management can often lead to an enterprise trying to overextend, customize and actually having to “manage” remote users and devices. Let’s take a closer look at why.

First, although one of the biggest value propositions around SSL VPN is the notion of “client-less” VPN access, in reality the end devices still require a recently updated and supporting Web Browser client — not to mention a recently updated version of Java to be able to run both port forwarding applets (to make non-web applications work over SSL) and to run the client security host checking process. The assumption here is that the end users device is up to update and if it’s not — that the end user will take it upon themselves to go off and download and install an updated version of Java.

Second, in order for user PCs to “run” or accept these temporarily downloaded applets, the user most likely will need administrator rights or privileges on their devices for both the port forwarding and security host checking processes to function. For many enterprises that do roll out managed corporate laptops to their employees, providing administrator privileges on these devices is often a non-starter because of corporate policy guidelines around security. Unmanaged devices that enterprises don’t control may also be relegated to limited and specific types of access base on this same limitation.

Third, even though many SSL VPN vendors typically offer some type of endpoint security and host checking prior to allowing SSL access to the enterprise, these same hosts still require vigilant management in terms of security. Clearly any enterprise considering this broader application access and/or deeper access into the enterprise mother ship must also consider how they will address user and device endpoint security to ensure that the hosts accessing their network have an updated Anti-X, personal firewall, IDS, etc., installed and activated. In short, these users and devices need to be managed to provide constant updating to meet the ever evolving security threat and device vulnerabilities.

So where does this leave us? Traditional IPsec remote access solutions have provided a proven, highly secure, and transparent native user desktop experience to enterprise applications for over a decade. Although IPsec still provides the default remote access method for the vast majority of enterprises in the world, enterprises are clearly faced with a migration challenge when it comes to evolving or augmenting their current IPsec secure remote access infrastructure with SSL VPN. More often than not the migration to any new technology can take anywhere from 6 months to several years plus depending on the size of the organization and number of user involved. And even at the end of a migration — many companies often still have “legacy” users and devices that they will still need to support.

Should enterprises seriously consider and begin to deploy SSL VPN based solutions? Absolutely, the benefits of SSL VPN are clear and compelling. Should enterprises also be skeptical when a VPN vendor suggests to them that SSL VPN can provide a wholesale replacement of their current IPsec deployment? Absolutely — they should be skeptical.

Enterprises should demand that their VPN vendors support a broad range of access options and VPN protocols (IPsec and SSL), on a common security and VPN platform, rather than introducing yet another appliance into their networking mix, adding additional cost and complexity to the enterprise deployment. This type of blended support for a wide range of secure access types and options will allow enterprises to migrate to newer technologies as it makes sense for their business, while at the same time protecting their current deployment investment.