One of the big use cases for having an SSL VPN is the ability to grant secure access to internal company websites to your remote users.
This is generally done by reverse proxying and when it works right it’s a great way of securing your internal sites that you would rather not have directly facing the internet.
However, it can be a challenge to successfully set up a reverse proxy that works perfectly and to do so often requires significant effort from either the poor admin who is trying to set up the resource, or the support team from the company supplying the VPN system. In my 9 years of working on SSL VPN technology, I would guess that up to 80% of all support was related to getting these proxied resources working.
Sometimes you get lucky as the VPN vendor may have templated a particular resource (like Microsoft Sharepoint for example) which has already had the hard work done by their development team with all the config required, although the point here is that it was still probably difficult to generate this.
Sometimes your internal website is very simple with nice static links that’s easy to catch and rewrite. Most of the time though you run into problems.
Here are some of the issues you may have to deal with:
You might start off with the proxy mapping requests for a single path off the root directly through to another path on your internal web site. But what happens when that internal site generates a link to itself such as a 302 redirect? Your client browser would then try to directly connect to the internal server’s URL and you would get an error (No such host for example).
So the proxy needs to rewrite that hostname in the HTTP headers.
What about simple links in pages? A relative addressed link (such as <a href=”index.html”>) would work just fine, but an absolute addressed link containing the full hostname (<a href=”http://www.host.com/index.html”>) would not.
Our proxy now needs to parse through all the html and rewrite any links it finds, replacing the hostname with the proxy’s own host.
For these simple two examples above, this is all pretty easy to handle so far. Where it can get really difficult is when you have to deal with dynamic web pages, which is probably most of them these days.
With dynamic sites, we now need to parse not just html MIME types, but also javascript, CSS, or any other number of files. Plus, links are very often not that easy to capture as they are concatenated from more than one variable in a script.
Here is where you normally start having to wrestle with the complexities of Regular Expressions and I think this xkcd cartoon pretty much sums up most people’s experience with these.
Even for those people who have a black belt in regular expressions, there can still be a lot of work involved in capturing http requests and viewing the source code to work out exactly which bits need replacing – and worse – it’s never the same thing on every site.
What if there was a way you could do away with all this fuss and make an internal web site available that works with minimal work and without having to set up a full blown client-to-site VPN?
Then it might be worth trying out our Hypersocket VPN, which has an alternative approach to this problem. The Hypersocket VPN uses an installable client that transparently tunnels directly through to your internal web sites, completely bypassing the need to do any replacements at all.
Even better, it combines this with some DNS interception, thus cleverly resolving what tends to be the biggest issue with SSL tunnelling websites, connecting to Virtual Hosts. With this DNS interception the host headers are always correct pretty much guaranteeing that if you can connect to a web site directly from inside your network, then you should be able to do the same from outside using the client.
This Blog post was brought to you by Hypersocket and Chris Dakin, Product Manager for Hypersocket Software. Chris has 20 years of industry experience in IT and the last 9 directly with Linux, Security and VPN. Chris is responsible for helping our customers understand and get the most out of our technologies.
