In remote access VPN solutions, one of the long standing discussions is around split tunnelling.  When a remote access VPN solution is built, there are two methods of routing traffic.  A dedicated
tunnel is, in english "when you are VPN'd in, all of your traffic goes through the VPN".  A split tunnel, also in normal speak, is "when you VPN in, your corporate traffic goes through the VPN tunnel, and your internet traffic goes the way it would go without any VPN at all”.

Both approaches have pros and cons, with IT pro’s lining up on either side.

If you split tunnel, then your internet traffic does not go to head office then back out again.  This should result in a faster internet session, especially if you are a few timezones over from the VPN gateway.  The problem with this is that their direct internet access bypasses all the corporate controls on internet security.  They are able to browse to any site, with no corporate firewall or IPS between them and the internet.   In the worst case, your remote user might be directly attached to the internet with no firewall at all.

If you have a dedicated tunnel, you very likely have a proxy server on the inside network as well.  This is because many firewalls will not take inbound VPN traffic and turn it around to send it back to the internet.  In many cases, having a dedicated tunnel may mean that your users are forced to use a proxy for their browser.  This means that they do not have internet access for their browser at all until they establish a VPN tunnel.  This may seem great to a security expert, but if your user is at a hotel, trying to use the hotel’s web portal to get internet access in preparation for getting internet access, that poor user is in a catch 22.  They won’t get internet access for the browser until the vpn tunnel is established, but they need a general purpose browser session in order to authenticate to the hotel’s system before they have enough internet access to start a VPN session.  To get around this, you’ll inevitably have to give some users “at home” and “at work” desktop icons, which will point to scripts that turn the proxy settings on and off.  Microsoft Group Policy has some nifty features in this area, where if you are at work (ie on a corporate subnet), you can have one set of workstation firewall rules and proxy settings, and if you are away (on any other network), you can have a different set of firewall and proxy settings.

As in all things, the final approach that is taken is a trade-off between security requirements and usability for the users (aka the business requirement).  What I’ve laid out above is by no means the whole story – I’ve seen other problems and solutions, and I’m sure you have as well.  We’d be very interested in the approaches you’ve taken, challenges you’ve seen, and what your final solution ended up being.  Please use our comment form to share.

=============== Rob VandenBrink Metafore