Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SSL or IPsec VPNs: Considerations for comparison

Robbie Harrell discusses some of the questions one must consider when evaluating whether to choose Secure Socket Layer (SSL) instead of the more traditional IPsec.

With the advent of mobility as a key requirement for many enterprise organizations, it is becoming more and more...

critical for IT groups to provide the remote-access technology that allows for the greatest degree of flexibility for accessing corporate computing facilities remotely. Key to this is an easy-to-deploy, easy-to-manage, flexible solution that will allow multiple user groups to access a company's assets regardless of their access mechanism.

IPsec has been around for quite some time and is a well-known, well-understood technology with many tried and proven vendors. In fact, it is IPsec that allowed for a "bring your own Internet" offering that permitted access to a company's intranet locations via any Internet connection. This is the traditional solution that has served the corporate enterprise space well. As long as the company employees could get an Internet connection (such as dial-up, Wi-Fi or broadband), they could launch their VPN clients, set up an IPsec tunnel to the VPN concentrator, and access resources behind the corporate firewall. This has been very effective -- until now.

More on this topic

How do I choose a VPN for my small business?

IPsec vs. SSL

More VPN tips

Today's enterprises are extending IT services to multiple user communities. These communities can include contractors, guests, extranet partners, and users of guest PCs. The ability to interface with these user communities and provide secure access via the VPN is compelling not only from a business-enhancement perspective but also from a reach perspective. If a company can interface with all user communities via a communications portal, it allows for enhanced communications with direct remote access.

Traditional IPsec solutions require that all users of the VPN solution must have a VPN client loaded on their PCs/laptops. This is not a feasible solution for today's client device portfolio because there may be PDAs, phones, guest computers and contractor computers that would need an IPsec agent installed to support VPN connectivity. This has led to SSL becoming a major player in the VPN space. Organizations can now provide remote access to any of the user groups discussed above, as well as providing remote access over Internet-enabled kiosks or any end station that supports SSL-based Web browsers.

This degree of flexibility is driving many, many organizations to look at SSL as an alternative to IPsec. As you and your organization begin asking the question of SSL versus IPsec, the first thing that should be considered is the user community that will require and/or desire remote access to secure computing applications. Second, consideration should be given to the types of clients these user communities will leverage. The combination of user groups (employees, guests, contractors) and clients (PCs, laptops, PDAs, phones) will make it pretty clear from a capabilities perspective whether or not SSL is required. So the question of SSL over IPsec will answer itself, based on the results of the inquiries. If the asset is owned by you, or you are willing to install software on your users' computers, then IPsec makes sense. Otherwise, SSL is the way to go.

Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has more than 10 years of experience providing strategic, business and technical consulting services. Robbie lives in Atlanta and is a graduate of Clemson University. His background includes positions as a principal architect at International Network Services, Lucent, Frontway and Callisma.

This was last published in June 2006

Dig Deeper on Network Security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.