Split Tunnel VPN problems

Two high-end attorneys went out of the country to work on a case. Problem was, they were not able to use their firm laptops to VPN in. We use Cisco's IPSEC VPN on our ASA 5500's and, to allow both firm access and Internet access simultaneously, we use split tunneling. Not every router support IPSec split tunneling. The symptom is the user can connect to VPN (locked icon in taskbar) but, once connected, they can not see firm resources, nor can they see any Internet resources either. If they disconnect, Internet access is restored. We've seen this problem before primarily with AT&T's dsl routers. The problem is the cheaper router's implementation of NAT modifies the packet envelope. IPSec is very particular about packet integrity and discards any packets that appear to be tampered with. Usually, we can get the attorney to spend $50 on a D-Link wireless router and move on. The situation with the two attorneys was not going to be as easy.

I decided to utilize SSL VPN. SSL is supported by virtually every public router out there. Our Cisco ASA comes with two included SSL VPN licenses and there are two attorneys needing remote VPN access. Perfect. I've worked with SSL VPN appliances before, most do application level tunneling. To give the attorneys a similar experience (and to keep from having to determine what ports every application of ours uses) I was hoping Cisco had a full-VPN SSL solution. They did, it's called Tunnel Mode.

Using the example from Cisco's site, I was able to create a profile that auto-installed a client on the user's computer and initiated a remote connection tunnel.

One of the problems with clientless setups like WebVPN is it is easier to masquerade as a firm user. This opens up password hack attempts on the server side, and phishing attempts for the user. User's passwords, even with policies in place, are typically not that secure. If user/password were the only authentication method, it would most likely not take long for a hacker to gain access to at least one of our accounts. Also, using a man in the middle attack, a user could be entering their username and password on a page that looks like ours but is someone else's (yes, they would get a certificate error, but users don't ususally read/care about those.)

Following our "protect the user from themselves" guideline, they best solution was to use our already existing Microsoft Enterprise CA infrastructure for server and client-side authentication. This ensures the client is coming from a firm computer. The private key on the user's computer (auto-installed via GPO) is far stronger than any password a user would have and, if compromised, could be revoked almost instantly.

Now, the two attorneys need only to go to a web site in their browser and then the (ahem, clientless) client asks them to select a certificate. Once selected, the VPN "just works (TM)". Again, if you haven't done so already, I highly recommend looking into what a Certificate Authority can do for your environment. Thanks for reading.