When a VPN does its job correctly, remote users don’t notice it’s there. Packets move from site to site, user to user. Encryption
algorithms scramble the data and then safely unscramble it at the other end. Information flows. Work gets done.
But this unseen extension to the enterprise network is in the midst of a major technology shift — the biggest since the mid-’90s,
when VPNs first provided inexpensive Internet alternatives to carriers’ proprietary private networks. For years, software
solutions based on IPSec have ruled VPNs. But new SSL appliances are changing all that.
Tried-and-true IPSec provides a layer 3 VPN solution that terminates at the firewall and grants remote users access to the
entire network. On each remote computer, a client must be installed and configured — either third-party software (typically
licensed from a network hardware vendor) or a client built into the operating system, such as L2TP (Layer 2 Tunneling Protocol)
and PPTP (Point-to-Point Tunneling Protocol) in Windows 2000 and XP.
SSL solutions, on the other hand, operate at the application level and terminate at an appliance inside the firewall. Network
administrators use the box to control user access application by application in conjunction with network authentication and
authorization services. And because SSL is browser-based, users can log on securely with a Web browser using almost any device.
A host of vendors now offer SSL appliances, including Array Networks, Aventail, F5 Networks, Neoteris, and Netilla. According
to research firm In-Stat/MDR, a mere $21 million in SSL devices was shipped in 2002. That number is expected to rise to $1.3
billion by 2007.
More Options for Mobility
Away from the office, users may need to tap data stored behind the firewall using various devices; not just the corporate
laptop, but handhelds, computers at customer sites, or a PC in the bedroom. The need for multiple entry points was a key reason
Tom Paceck, Virtua Memorial Hospital’s assistant vice president of technology, chose an SSL.
“For us, it all comes down to mobility,” he says. “We never know where our people will be to access applications.” Many of
the physicians on the hospital staff are mobile, and many more lack the patience to carry around a laptop or sign on through
a VPN client.
SSL VPNs are picking up steam mainly because, unlike established IPSec VPNs, client software needn’t be installed on the user’s
computer. Jeffrey A. McConocha, president of NCS DataCom, a VPN solution provider using Neoteris SSL appliances, says switching
his customers to an SSL-based VPN “has virtually eliminated client [tech] support for mobile users.”
Another plus is that remote users don’t need to worry about local firewalls when they log on via SSL VPNs. By contrast, attempts
to connect via IPSec client behind a NAT firewall usually fail. “SSL provides a nice, clean solution for NAT transversal,”
says Steve Schall, director of security application product management at Nokia.
One more reason to choose an SSL VPN is that security policies can be very granular. Because SSL VPNs work at the application
layer, network administrators can specify access control sets and rules based on such criteria as application, TCP/IP port,
and user. That level of control cannot be wrung out of an IPSec VPN without installing additional firewalls behind the tunnel
end point and messing with lots of tedious rule sets.
Tunneling Through the Browser
The “client factor” is at the heart of the IPSec vs. SSL debate. When evaluating remote VPN solutions, network managers need
to define exactly what applications they want to “webify” for users. For applications that are Web-based, SSL is the clear
choice for secure access; most SSL VPN appliances are reverse proxies that easily connect to internal servers. The choice
is not so clear when there’s a greater mix of applications, such as Citrix MetaFrame or Microsoft Terminal Services; 5250
or 3270 “green screen” hosts; or X-Windows or other fat client applications.
For non-Web applications, both IPSec and SSL offer workable solutions. The trade-off boils down to IPSec client support vs.
SSL proxy configuration. With SSL, this situation exposes a dirty little secret — SSL VPNs aren’t really “clientless.” With
the exception of Web traffic, all other application support requires that the browser automatically download and run either
an ActiveX or Java applet. For example, Paceck explains, when a user fires up the SSL VPN service from Netilla for the first
time, three Java applets download. Normally, this is undetectable.
Just as with IPSec client issues, there can be SSL applet compatibility issues to consider, such as which Java virtual machine
has been installed. Running applets may also conflict with browser security settings and require additional client support.
Paceck claims, however, that these potential pitfalls have never posed a problem for his users.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
