IPsec has been the standard for encryption of VPN traffic for some time, but there are alternatives to IPsec. This article takes a look at some of the differences between IPsec and another possible solution, SSL.
Though inclusion of IPsec protocols in the Wizard-based client set-up and install on modern Windows desktops and servers makes them a candidate for VPN use, IPsec isn't the only game in town when it comes to making VPNs work. Essentially, IPsec works as a "shim" in a typical IP protocol stack, and when outbound traffic passes through the shim at the network layer it's encrypted and then becomes the payload of an outbound IP packet whose contents are essentially opaque. Incoming packets reverse this process, so that only a designated recipient with the right decryption keys can decipher packet contents before shipping them further up the protocol stack.
When evaluating IPsec VPN options, networking pros should consider the following:
- IPsec works best for site-to-site connections with sizable, ongoing data exchanges
- IPsec VPN clients work best when network access occurs using IT-managed PCs where configuration, software applications, and sites visited can be monitored and restricted
- IPsec VPN clients do not offer the best solution for distributed users at multiple sites who all need access to the same centralized applications and data repositories
- Individual VPN client software must be installed and maintained on every PC that requires remote access; remote clients must also be reconfigured whenever the network grows, changes its access approach, or introduces new or different IP addresses
Another leading technology for secure remote access uses Secure Sockets Layer (SSL) communications through a Web browser to establish VPN connections across the Internet. When IPsec and SSL mechanisms are compared, the following observations emerge:
- Initiating an IPsec session requires establishing and validating IP associations, and involves numeric addresses as well as numerous other settings. This requires more user training and helpdesk involvement than opening a Web browser and logging into a remote access server.
- NAT and IPsec can pose problems, because many IPsec sessions require that secure end-to-end associations be established. This requires public IP addresses on both sides of any connection across the public Internet, and necessitates various workarounds. SSL-based VPN sessions are not subject to such limitations.
- Not all IPsec-based VPNs are completely interoperable, and integration of products from multiple vendors can be difficult. SSL-based VPN sessions use standard browsers (all of which support SSL) without difficulty.
- To enable IPsec traffic to transit a firewall, additional configuration is sometimes required. This is more problematic in home or small office environments where device-based firewalls are incredibly common, but the expertise to configure and maintain such devices is not. SSL-based remote access requires no such special handling.
- When IPsec-based VPN clients open a remote network session, they function as peers on the remote network. This makes it more difficult to manage what resources they can see and access, and opens more doors than one might want to any unauthorized users who succeed in establishing such access.
Perhaps some of the most serious issues surrounding IPsec based VPNs have to do with overhead. IPsec VPNs can require substantial processing resources for encryption and decryption, and the multiple envelopes added in its "protocol shim" architecture can steal bandwidth as well.
What gives SSL-based VPNs an advantage is that Web service interfaces are mediated and managed on the server end. Administrators can control exactly what applications, services, and information is exposed to remote VPN clients and can even erect multiple layers of security where and as it's needed. The browser-based connection works like a thin client across a conventional network and needs to move only user input to the server, and display output to the client, substantially lowering bandwidth and processing requirements on the client side.
SSL VPNs can offer a significant saving in cost, but does that mean that IPsec-based VPNs are about to become obsolete? With the aforementioned technical difficulties to consider and big changes to IPsec standards currently underway (that could render current IPsec devices and software unusable once a new standard is defined and deployed), it's tempting to speculate that IPsec may be superseded by other technologies. But I'm not inclined to predict an immanent demise: like other Internet protocols whose departure has been predicted for years, I believe IPsec will remain on the scene for the foreseeable future. That said, companies and organizations with substantial needs for secure remote access should be aware that other, less intrusive, and easier to manage alternatives exist (but also, that such alternatives typically cost more to purchase, if not to operate).
Ed Tittel is a regular contributor to numerous TechTarget Web sites, and the author of over 100 books on a wide range of computing subjects from markup languages to information security. He's also a contributing editor for Certification Magazine, and edits Que Publising's Exam Cram 2 and Training Guide series of IT cert prep books. E-mail Ed at etittel@techtarget.com.
