Remote Network Access Myths

While the demand for remote access has grown considerably, there are some persistent myths on the topic that won’t go away. These misconceptions (including that a clientless VPN is easier to manage or that large-scale remote access projects are impossible to manage) make some organizations shy away from remote access altogether and can cause confusion and inefficiency among those who embrace it.

So let’s set the record straight.  First of all a clientless VPN is not a true VPN.  You obtain an encrypted gateway into the company’s network, often with limited access to a handful of applications.   By definition, this is not a VPN.  Virtual Private Network means that you become part of a virtual network, where you can communicate with your company’s network and the other users as though you were inside the LAN, at the office.   For example, you should be able to communicate with another computer that is also on the VPN.   A clientless VPN on the other hand is basically no different than a web based application using HTTPS and requiring login credentials.

Both have merits, both are useful for their own reasons.   As an example, if I’m running a medical billing company and I have a thousand doctors who need to connect to my network to post their billings, there is no need to use the client based VPN.  An HTTPS based connection will do just fine.   But if the users connecting are my employees and I don’t know beforehand what they will need to go and which internal computers they need access to, then a client based VPN will be most likely more suitable to my requirements.

At Network Box, for instance, we use OpenSSL VPN, which requires a client.  The client is free and installs literally in minutes as it has a very small foot print.  You thus have two ways to deploy credentials – you can issue a private certificate and private key for each remote user; or you can integrate the authentication on the server side with the company’s LDAP (other such types of authentications methods are supported as well).

Simply put, you create a group and associate with it all the users that require remote access. The only files you install on the remote workstations are a “public” key and a configuration file; these are the same for all users, so there is really nothing to manage on the remote workstations.  If an employee leaves and is removed from an active directory, he/she is automatically removed also from the SSLVPN group, and longer has any access through the VPN.

This approach requires no key or certificate management of any kind.  Deploying the VPN this way has no impact of any kind on access management, except ensuring that those who are in the SSLVPN group actually do need VPN access.  The deployment is rapid and simple, the management painless, the results very flexible.

This type of VPN can also be deployed in site to site mode; and it has without doubt the advantage of being much more secure than the clientless version.   On a wireless connection, the clientless VPN can be intercepted and spoofed very easily and this makes it not really as secure as many people think it might be; the client-based VPN is not as easily exploitable – and some make the argument that it cannot be exploited yet.  The only thing that can happen is that someone trying to spoof it will cause your client session to disconnect; but it will not be able to take over that connection and gain unauthorized access to your network.