We asked NCP’s Joerg Hirschmann to take look at the arguments presented in Reliable Systems’ recent post, “Remote Access for Everyone,” and offer some respectful criticism of the case made for SSL versus IPsec. Quotations below are from the original article, with Joerg’s comments following.
The success rate for an average user being able to install an IPSec client and get the VPN tunnels to work, even with phone support, was around 15%. Most of the time the user had to bring in the computer or we had to send a tech on site.
Management based native VPN installations are pre-configured by central administration. Configurations will be created automatically using a leading internal database like Active Directory. Users do not encounter configuration issues at all! They cannot even change VPN related settings. Pre-installed basic settings, getting personalized at first connection = Plug & Play VPN.
Different physical network technologies – notably DSL – run into performance problems with IPSec in many configurations, requiring adjustments on the client, routers, or other things that you just can’t expect end users to understand.
A communication suite deals not only with the VPN part but also takes care of connecting the client safely and with the highest possible performance with the internet with only one goal: establish the VPN tunnel. The user does not even need to know the communication media; the client will select it automatically.
In general SSL VPN has much more performance issues than an IPsec based VPN which is primarily based on the protocol in use.
IPSec is very easy to block on a network. In fact, it took some time for most network routers to be compatible with IPSec. Now try to get it to work at 8 PM over a wireless network in a hotel in Buffalo.
For this reason the client must be able to provide alternative tunneling protocols. If IPsec is blocked it must be able to use SSL tunneling as well.
SSL is Simple, IPSec is complicated:
SSL is a single TCP/IP socket with a relatively straightforward, self-configuring, and invisible to intervening appliances.
IPsec is as complicated as the solution installed. It can be as easy as SSL and offers advantages on protocol level as it is UDP and not TCP based (much more overhead with TCP!).
SSL is essential, IPSec is a threat:
No one can afford to block SSL on their network without basically admitting to not having a network at all. It’s very expensive to proxy by decrypting and re-encrypting, so few companies do it. On the other hand, many networks view with suspicion the goal of establishing an encrypted connection out of their network, so blocking IPSec may sound like a good idea
SSL is encrypted as well, so where is the advantage if you do not want to introduce those “very expensive to proxy by decrypting and re-encrypting” servers? This message is very contradictory. However, a VPN client must be able to provide a solution for those blocking networks and then switch to SSL based tunneling. In non-blocking networks IPsec is to be preferred as far less bandwidth consuming.