With an SSL VPN, users can access corporate resources from any remote device through a Web browser, eliminating the need for IT to install VPN client software. Some VPN vendors are trying to expand the use cases for SSL VPN technology by adding support for site-to-site SSL VPN links as an easy alternative to the more common IPsec tunneling. While this alternative is unlikely to displace IPsec tunnels in the enterprise WAN anytime soon, there are some specific applications where an SSL VPN might be the only choice for creating secure site-to-site links.
SSL VPN offers a simple approach to creating VPN links
The ubiquity of the Secure Sockets Layer protocol makes the site-to-site SSL VPN appealing. SSL VPN connections travel over the same protocols and encryption used by every secured website on the planet. Many enterprises leave port 443, the encrypted version of port 80 used for Web traffic, open on firewalls to support secure Internet transactions like online banking and online retail. An SSL VPN takes advantage of these open ports, enabling both remote access and site-to-site VPN support from just about anywhere in the world. Conversely, some ISPs, corporate firewalls and even foreign governments restrict access and block ports 50, 51 and 5000, the ports that IPsec tunnels commonly use.
Building and configuring an SSL VPN is simpler than doing so for its IPsec equivalent, according to Bill Prout, senior technical engineer at Astaro. For example, within Astaro’s Security Gateway, an administrator can create a configuration file and upload it to remote gateways to form the SSL VPN link. This level of simplicity is particularly appealing for small enterprises that may lack the IT skillset to adjust firewall policy and set up IPsec tunnels between sites.
SSL VPN vendor lock-in and performance concerns for site-to-site links
There are, however, a number of drawbacks to using SSL for site-to-site VPN connections. Unlike IPSec, there are no industry standards for site-to-site SSL VPN connections and no interoperability between vendors’ products. Although Astaro based its SSL VPN product upon the open source OpenVPN project, Prout admits that administrators may struggle to connect Astaro's product to a server running OpenVPN.
“Site-to-site SSL VPN is completely non-standard between vendors, which means getting locked into a single vendor,” said Joel Snyder, senior partner for the consulting and information technology firm Opus One. Alternatively, nearly every firewall on the market, including the smallest of SMB solutions, can create an IPsec tunnel to any other product from any other vendor.
Along with interoperability issues, the network overhead associated with site-to-site SSL VPN connections can translate into poor performance in a branch deployment. “Tunneling TCP traffic over IP is generally a bad idea, but the issue is compounded in a site-to-site VPN,” Snyder said.
While the traffic overhead also exists in remote access deployments, the impact is less obvious to the individual remote user. And that overhead is offset by the convenience that browser-based login access provides. IPsec VPNs, on the other hand, are designed to minimize overhead and are much more efficient in moving traffic between locations.
When to use SSL VPN over for site-to-site connections
Given the interoperability and performance concerns, most experts and vendors agree that site-to-site SSL VPN should not be the first choice when architecting WAN links for branch offices. However, there are several scenarios where a site-to-site SSL VPN connection makes sense, especially where ports 50, 51 and 5000 are blocked. International or geopolitical restrictions or port blocking by an ISP can lead an enterprise to try an SSL VPN connection. Also, if an enterprise is creating a secure branch within another organization’s corporate firewall, a standard IPsec VPN tunnel won't work, but an SSL VPN tunnel might. For WAN managers struggling with making traditional IPsec tunneling work in their unique network environments, an SSL VPN is a compelling alternative to connecting these atypical remote locations.