Many businesses are confronted with how mobile workers such as individual staff, vendors and consultants will gain remote access into their business, securely. On top of that, “how far into the network to allow these people” is likely the next question to be answered.
What is the difference, you ask?
Both SSL VPN and IPSec VPN are choice forms of secure, remote business connectivity, both with their own strengths and weaknesses. Below are key similarities and differences to help when deciding between SSL and IPSec.
IPSec
IPSec VPN (IP Security Virtual Private Network) is used for remote end users who need access into a business’s network (the Local Area Network commonly referred to as the LAN). It does so through using a “client/server” environment. Thus to set up the encrypted connection IPSec VPN requires the end user install a client. Having to install a proper client and configuration profile can be seen as an additional security step, however the downside is the challenge to configure, maintain and administer the profile and access remotely.
IPSec VPN operates at the network layer which means when someone is “connected” they have full blown access to the entire LAN they are connected to. In terms of network security, this type of access is quite similar to allowing them to plug their pc directly into that specific network with no other security restrictions. This may be fine for trusted users, but all users? What about your vendors, how much do you trust them? IPSec VPN “connections” use specific UDP port numbers which if not specifically allowed, are typically denied through a firewall. There can be occasional NAT difficulties transitioning across routers and firewalls and some carriers (internet providers such as AT&T, Verizon or XO) block IPSec traffic unless paid or convinced otherwise. The authentication and encryption that IPSec uses is the industry standard and “highly secure” algorithms of HMAC, SHA-1, Triple Des and AES. At this time however some vendors recently began a migration away from supporting IPSec VPN to newer and less cumbersome technologies such as SSL.
SSL
SSL (secure sockets layer) remote access can allow controlled, secure, and managed remote access to any application, from any device and location. It is commonly used for remote network access, remote “specific resource” access, web browsing secure sites, E-mail, IM and SIP amongst others. SSL access comes in two forms, clientless or client based. SSL operates at the “application layer”(of the 7 layer OSI model) which allows it to provide a high level of security in the form of granular network access and authorization and in some cases even provides End Point Control. SSL encryption also employs the high security standards of triple-DES, RC4 and AES ciphers to secure the traffic between the two endpoints. SSL encryption is very secure and used for most remote banking access.
Clientless access comes in the form of connecting through a web browser. Most web browsers support SSL and thus have these capabilities built in which means as a plus, most computers support SSL natively. The majority of online banking and transactional websites take advantage of SSL technology to encrypt personal information such as User IDs, passwords and account information over the Internet. Wells Fargo, Chase, B of A, EBAY and Amazon are a few of the many, many sites using SSL for their secure remote access. Consider accessing any of these websites, they handle all the security automatically leaving you with nothing to do but enter a username, security password and possibly a PIN to enter an encrypted and secure session with your bank. “Web based” SSL network access is great for connecting to or browsing resources on a network or website, but is limited by its relative inability to do remote printing.
SSL also comes in a client based form which gives client to server type access or secure tunnel access. This is similar to “putting the remote user on the network”. However, it can be done with a high level of security, pre-qualification and control through the pre-authentication interrogation of the remote end point devices to identify and secure the connecting device. It further allows you to manage remote user access through user identity-based access policies, offering granular network access to employees, partners and customers based on user identity and work profile. This allows you to manage anyone’s access just to a specific application, server or network; based on their credentials or credentials plus security integrity of their connecting machine. Example; if a machine’s Anti-virus or Microsoft update patches are not up to date the end-user can be relegated to read-only access to a specific server, zone or directed to specific remediation instructions. This negates allowing a vulnerable pc onto your network. Higher-end SSL appliances perform this “End Point Control” (AV scan/OS scan/ credentials etc). These same devices can employ key-logger security such as virtual keyboards when connecting from unsecure end point devices such as mall kiosks or airport terminals.
Which type of remote access is right for me?
There are benefits to be recognized between both IPSec and SSL as well as clientless vs. client based access. Clientless access users don’t need a company laptop per se, since they can just fire up a web browser on really any machine for access without proprietary software. Another benefit clientless access has going for it (vs. client based SSL or IPSec) is that some vendors “clients” do not play well with each other. Thus it is commonplace when installing a new “client” to have to completely uninstall any previous remote access “client” you had installed. This breaks whatever connection was dependent upon that client that was just uninstalled. A benefit of client-based remote access may be that it is already implemented throughout your company, thus negating the expenses of acquisition and training of new technologies.
Security is not typically a concern with either IPSec VPN or SSL VPN as they use similar “high” levels of encryption. SSL VPN provides an ease of configuration in that it is not required(but can be an option) to be configured on the end point machine by an administrator, as opposed to IPSec VPN which requires a remote client and profile. IPSec VPN operates at the “Network” layer and is a benefit whereas any application can ride across its connection since it is only a pathway. It does not pay attention to the higher layers. It is and only will be the pathway, similar to a freeway that cares not what vehicles traverse it. The benefit is that 0 traffic is ever blocked thus requiring no troubleshooting to find out what policy or rule-set is blocking it. “Higher-end” SSL applications lend themselves to controlling “vendor” and remote access by allowing them to just a specific machine or application but not fully into your network through the security of granular access and End Point Control based on corporate policy. Since SSL VPN operates at the application layer it can provide detailed auditing abilities thus helping compliancy with regulatory measures & reporting as well.
Now what?
Some vendors have already announced end-of-sale/end-of-life statements and began migrating away from supporting IPSec VPN. This creates a challenge for those businesses still using IPSec VPN technology who are trying to grow other aspects of their business such as adding additional PC’s or OS upgrades. However there are some vendors that still support IPSec and have yet to issue an End of Sale or End of Life statement.
Both IPSec VPN and SSL VPN are available as a dedicated hardware appliance solution or as a licensed feature on most enterprise level vendor’s firewalls. If either of these are ran as a licensed option on your firewall there is a lower total cost of acquisition and no need to learn a new management interface. When running SSL VPN as a licensed firewall option, it is similar to IPSec connectivity in that it is typically only network access, not resource based access. Stand-alone SSL VPN appliances typically draw their benefits from their richer feature sets allowing resource based access, a high level of End Point Control, problem isolation in troubleshooting and detailed logging and reporting.
So, you may be asking yourself…
Why would anyone want to stay with IPSec VPN after all? Although SSL VPN may seem like the obvious choice when enabling remote access, some company’s users simply do not need that level of access or security. Additionally, it would most likely be in the best interest of companies who are not upgrading their current technology infrastructure, and whose users are not upgrading to the latest computer software such as Windows 7(which has compatibility issues with some of the major IPSec vendors), to remain with IPSec.
As the year 2011 kicks off, it is clear to see that the rapid growth of innovation and intelligence in the field of technology is not slowing down. The creation of newer remote access options like IPSec and SSL are the first of many to come and the options will only get better and more plentiful. Companies are already running their financial transactions, email, internet, work documents and even their businesses voice phone calls over these connections reliably. The future of remote access is bound to continue solving problems for business today and present more options for the company implementing them. Most importantly it, will allow the end-user a richer, simpler and overall more enjoyable experience.
Reference:
http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci940324,00.html
http://www.networkworld.com/news/2007/102607-arguments-ipsec-ssl.html
http://www.juniper.net/us/en/local/pdf/whitepapers/2000232-en.pdf
http://www.thegreenbow.com/ipsecssl.html
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ssl_vpn.html
SonicWall: Practical Advice for Customers: Remote Access
http://www.checkpoint.com/securitycafe/readingroom/web_security/rise_of_ssl_vpns.html
Want more information on topics covered in this article? Contact us at sales@affant.com or check out our staff page for individual contact information.
Affant Director of Engineering since 2000. Management of engineering and support team, Escalation of all technical and client issues. Sales and design engineer.
