Remote Access VPN and a Twist on the Dangers of Split Tunneling
By Thomas W Shinder MD, MVP
Have Questions about the article?
If you’re not familiar with split tunneling and what it is, you might wonder what the big deal is. Split tunneling allows the remote access VPN client to connect to the corporate network via the VPN link, and connect to the Internet via the interface the VPN connection was established over (not the VPN channel itself).
For example, suppose you have a remote access VPN client connecting to the corporate network over a hotel wireless network. The user with split tunneling enabled is able to connect to file servers, database servers, mail servers and other servers on the corporate network through the VPN connection. In contrast, when the user connects to Internet resources (Web sites, FTP sites, etc), the connection request doesn’t go through the VPN link, it goes through the wireless connection and out the gateway provided by the hotel network.
Split tunneling is enabled on the Microsoft VPN client by removing the checkmark in the VPN client’s Networking Properties dialog box for the Use default gateway on remote network setting. Note that Microsoft uses this as the default configuration, as they realize the security concerns involved with split tunneling.
The problem is that when a remote access VPN client connects to both the Internet and the corporate network, it has routes that allow the VPN client machine access to both networks. This creates the possibility that a malicious user on the Internet could use the VPN client’s link to the corporate network to access resources on the company’s LAN through the authenticated VPN connection. This is possible if the VPN client computer has IP routing enabled. IP routing is enabled on Windows XP-based computers by setting the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip \Parameters\IPEnableRouter
Registry entry to 1 (data type is REG_DWORD)
Split tunneling was an issue with the ISA Server 2000 firewall because remote access VPN clients that were not configured as Firewall and/or Web proxy clients could not access the Internet through the same ISA firewall to which they established their VPN link. ISA firewall admins and users tried to get around this issue by enabling split tunneling on the clients instead of taking the security high-road by configuring the remote access VPN clients as Firewall and Web proxy clients.
The good news is that for the ISA Server 2004 firewall, you don’t need to enable split tunneling. Non-Web proxy/Firewall clients can connect to the ISA firewall’s VPN server and access the Internet without problems, and you can even implement user/group based access control by leveraging credentials the user used to log onto the VPN server. The typical split tunneling issue is no longer a problem with the new ISA firewall can you never need to configure the VPN clients to allow split tunneling to access the Internet.
Have Questions about the article?
A New Twist on VPN Split Tunneling Risks
However, there is a “twist” on the split tunneling issue that can still pose a problem. Remember, the issue with split tunneling is that the VPN client can access the corporate network and another network simultaneously. This twist is on the split tunneling issue exists even when you leave the Use default gateway on remote network setting enabled. This variation of split tunneling is related to the Windows Internet Connection Sharing (ICS) feature.
When Internet Connection Sharing is enabled on the VPN link, the remote access VPN client machine becomes a NAT router between any network to which the VPN client is currently connected and the corporate network.
For example, the VPN client machine might be a Windows XP machine on a home LAN or hotel LAN and has a single Ethernet adapter installed in it. The Windows XP machine has a valid address on that network and connects to the corporate network through the VPN connectoid in the Network Connections window. At this point, any host that sets its default gateway to the IP address of the Windows XP computer can now access the corporate network resources.
The figure below shows the VPN connectoid’s Properties dialog box. When you put a checkmark in the Allow other network users to connect through this computer’s Internet connection and click OK, the computer becomes a NAT router for hosts that set this machine as their default gateway.
Consider the network configuration in the figure below. In this example an employee enables ICS on the VPN link. The user establishes a VPN connection to the corporate network. The machines on the users home LAN are configured to use the IP address of the Windows XP computer with ICS enabled as their default gateway (maybe they have a WAP on the home LAN assigning IP addressing information to the hosts on the home LAN). Now all non-local connections (connections to any resources not located on the home LAN network ID) are routed through the Windows XP computer to the corporate network.
Connections routed to the corporate network are all NATed from the home LAN, so the only source IP address seen on corporate network is that of the remote access VPN client computer that established the initial connection, regardless of which host on the home LAN initiates the connection. In addition, all the connections from hosts located behind the Windows XP computer with ICS enabled is done within the security context of the user who logged on to the VPN server. Access controls on the ISA firewall are applied based on the user account that logged onto the VPN server.
Security implications of this configuration should be clear. Any host on the home LAN can access resources on the corporate network (or the Internet) under the security context of the VPN user. The laptop on the home LAN that has the P2P software installed surely has worms, viruses, spyware and trojan applications installed on it. Outbound connections will be forwarded to the corporate network. The “family friend” (with aspirations of becoming a hacker) who brings his laptop onto the home LAN can use the connection to test his fledgling hacker skills on devices on the corporate network.
HaveQuestions about the article?
Solving the ICS Split Tunneling Problem
The solution to this problem is to disable Internet Connection Sharing on all devices that are authorized to connect to the corporate network through the remote access VPN link, or if you allow non-managed machines to connect to the corporate network through a remote access VPN connection, then you should have a mechanism in place that checks whether ICS is enabled on the calling VPN client device and drop VPN connection attempts from hosts with ICS enabled.
How do you accomplish this task? Some options include:
The CMAK is a very effective and efficient method of configuring and distributing VPN client connections to your users. Users will not be able to change the settings you configure in the CMAK VPN connectoid you distribute. However, if the users are local admins on their machines, they will be able to create their own VPN connectoids to connect to the corporate network.
You can configure Windows Active Directory Group Policy to turn off ICS. This works well for machines under your administrative control. However, if you allow non-managed machines to VPN into the corporate network, then Group Policy won’t be of much use in controlling the ICS settings on those machines.
Using some method to test remote access VPN clients for configuration compliance is the best solution, as it can be applied to domain and non-domain members. The ISA firewall comes with built-in support for remote access VPN quarantine and control (VPN-Q). The problem with the built-in VPN-Q feature is that while its relatively easy to get the client and server pieces in place, the configuration scripts to make it functional requires that you have either programmers or sophisticated scripting professionals on staff. And even if you have those resources, there is a significant amount of research required on your part to figure out exactly what should be included in the scripts.
A better solution is one that has the same level of functionality as the ISA firewall’s VPN-Q, but also provides a level of usability that doesn’t require the same level of administrative and coding overhead. One solution I’ve found that doesn’t require that you get a Ph.D in VPN remote access client quarantine is Frédéric Esnouf’s Quarantine Security Suite (QSS). Frederic is an ISA Server MVP and a friend of mine, and I can tell you that his product is very slick, very easy to use, and does the job without requiring you to be a programmer or scripting guru.
Have Questions about the article?
I highly recommend that if you’re using the ISA firewall to provide secure remote access VPN connections to your corporate network, and you don’t have time to figure out the built-in VPN-Q feature, that you give Frédéric’s QSS a look. Check it out and download a trial version at http://fesnouf.online.fr/qss_main.htm
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, ask them at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000775. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy