Enterprise disaster recovery strategies have the common goal of maintaining business continuity under nearly all circumstances. It is therefore imperative to include failover communications mechanisms in case connectivity should be compromised. For everything from natural disasters to terrorist activity to pandemics, numerous contingencies compel detailed disaster recovery plans. Using a VPN as a failover mechanism when a primary communications link may be unavailable is certainly a smart move -- as well as an easy one to implement -- because so many different VPN options are available.
Numerous tunneling technologies are used in VPN frameworks, but two protocols dominate secure VPN technologies: IPsec and SSL/Transport Layer Security (TLS). Their relative strengths and merits depend on the circumstances surrounding their deployment, the equipment involved, and varying levels of availability that must be delivered.
IPsec VPN strengths and merits
On the positive side, IPsec is integrated into some enterprise routing equipment and public-facing servers, which gives IPsec VPN solutions a distinct competitive advantage. With an IPsec-capable router, an organization can establish one of several failover arrangements that can provide various levels of availability and redundancy.
Furthermore, IPsec-capable communications equipment can facilitate a variety of dedicated circuit and backup leased line configurations with multi-path redundancy, high availability and cost-effective WAN extranet connections. Primary circuits can be established with doubled-up routing devices and with or without backup links to ferry VPN clients to VPN gateways with minimal service interruptions.
IPsec VPN weaknesses and faults
A dispersed mobile workforce remains a constant challenge for IPsec-derived VPN solutions because its infrastructure is designed to work best for site-to-site business connectivity. As such, IPsec solutions -- in order to work properly -- often require a site-specific configuration for both clients and servers, which makes advance configuration and testing absolutely essential. In fact, IPsec's inflexibility makes it surrender first place to SSL-based VPN solutions, many of which may be accessed easily from any Web-enabled browser on just about any computing platform.
With ever-increasing workforce mobility and end-user demand, an IPsec infrastructure has become almost impractical simply because it's cumbersome to implement and costly to maintain. To complicate matters further, frequent use of incompatible vendor-specific extensions and implementations to the IPsec infrastructure means that IPsec products that manage to interoperate with those from other vendors usually do so in a way that limits overall scope, scalability or capacity.
On the other hand, IPsec is widely distributed at the enterprise level within industrial-grade devices such as Cisco's 7200 Series routers. These routers also support Generic Routing Encapsulation, which permits an unusual rearrangement in the way networks are interconnected and may also be used to tunnel VPN connections in the event of an emergency.
SSL VPN strengths and merits
SSL VPN solutions are generally more universal than the IPsec variety because SSL is standardized and implemented on so many platforms. Unlike Microsoft Windows' inherent reliance on LT2P for IPsec, SSL implementations also work across BSD, Linux, OS X and Solaris platforms, any or all of which might be essential for supporting business-to-client interaction where mismatched IT equipment, protocols and procedures cannot always be easily resolved or rationalized.
Managing communications within a mobile and portable workforce is best handled with highly flexible SSL VPN configurations -- for several reasons. First and foremost, they are easy to implement and maintain. Second, SSL VPNs are ideal for equipment that lacks remote manageability (such as home PCs, PDAs, smartphones and so forth). Third, SSL VPNs work on just about any device that supports Internet access and a Web browser. SSL is much better at NAT traversal than IPsec (though many modern implementations remedy IPsec addressing issues) because no critical information in SSL packets is lost in the address or port translation process.
Some VPN solutions, such as OpenVPN, can push site-specific information to clients, including DNS server addresses and preferred client-side settings. This lends plenty of transparency, speed and flexibility to emergency-planning failover procedures. Connecting clients can be redirected to alternative gateways as they connect in the wake of a disaster or emergency, and they can then be redirected back to primary gateways as they come back online, without manual reconfiguration on client machines.
SSL VPN weaknesses and faults
SSL VPNs produce overhead with additional layers of encapsulation. Also, when tunnel/tap devices are involved in establishing VPN links, diagnosing connectivity problems can become unnecessarily complicated. For starters, the IP and Ethernet frame headers become encapsulated within the SSL protocol data unit, which may then itself become encapsulated within TCP or UDP protocols. This arrangement is less than ideal for low-speed links and conservative processing resources where a kernel-integrated IPsec solution might deliver better native performance than SSL solutions.
Conclusion
IPsec and SSL VPN technologies adapt differently to similar sets of circumstances, each with its own distinct advantages and disadvantages. IPsec and SSL solutions work at different levels of integration, interoperability and implementation when it comes to delivering failover VPN connectivity. Depending on the circumstances and scenarios that an enterprise may plan to accommodate in its disaster recovery operations, one choice may certainly adapt better than the other, but neither is inherently superior.
About the authors:
Justin Korelc is a longtime Linux hacker and system administrator who concentrates on hardware and software security, virtualization, networking and unusual Linux configurations. Justin has contributed to books on Linux-based home entertainment and TCP/IP course material and writes semiregularly for several TomsHardware sites.
Ed Tittel is a freelance writer who specializes in information security, IT certification and markup languages. He created the Exam Cram series and has contributed to more than 130 computer books. He writes regularly for numerous TechTarget Web sites. Email Ed at etittel@techtarget.com.
