When IP VPNs came on the scene in the late 1990s IPSec quickly established itself as the standard to provide secure network-layer connectivity over insecure IP networks, typically the Internet.

The appeal was obvious: it is less expensive to buy Internet access and make WAN connections over it than to buy dedicated circuits or a frame relay or MPLS service.

But IPSec is complex. The more sites that connect to each other, the more secure links or tunnels need to be defined and maintained. If IPSec is used for remote access, it requires software on every remote machine that must be installed and maintained.

Then SSL VPNs entered the scene offering application-layer secure access over the Internet using capabilities common to most browsers. The implication was that businesses interested in remote-access VPNs no longer needed to distribute and maintain client software on the remote machines.

The limitation of SSL was that the browsers could access only Web-based applications, but this challenge was met by Webifying non-Web applications or pushing Java or Active X SSL VPN agents to the remote machines on the fly. These plug-ins gave the remote computers the ability to create network layer connections comparable to IPSec, but without having to distribute dedicated VPN client software.

As a result, SSL VPNs are making great headway against IPSec VPNs for remote access and seem likely to win out in the end.

IPSec is still the preferred method of site-to-site VPNs because either technology requires a gateway anyway, IPSec is better established in this arena and many SSL vendors don’t even offer site-to-site connections. For site-to-site, IPSec carries the day.

< Return to the list of arguments >