VPN Client Security Part 1: Split Tunneling Issues

VPN Client Security Part 1:
Split Tunneling Issues

If you been following my articles here at www.isaserver.org, you might have noticed that I’ve done quite of few of them on VPNs. The reason for this is that VPNs are an integral part of your security infrastructure and that they work so nicely with ISA Server. You’ve seen how the ISA Server Wizards make configuring a VPN server or VPN gateway a virtual no brainer.

But there is a problem with VPNs that can get you into a lot of trouble if you aren’t aware of what’s going on. That problem is related to how the VPN clients are configured. The default configuration of Microsoft VPN clients is quite secure. If you or your users don’t mess with the default configuration, then you’ll be in good shape. You will only run into problems when the default configuration is changed. Sometimes you need to make this change, and sometimes the change is made to subvert your network security.

The important VPN client configuration option is the use default gateway on remote network. This option appears in various locations, depending on the version of Microsoft VPN client you’re using. On a Windows XP Professional Computer, you’ll find it this way:

1. Right click the My Network Places icon on the desktop and click Properties.
   
2. Right click on of your VPN client connections in the Network Connections window and click Properties.
   
3. Click the Networking tab, and then click on the Internet Protocol (TCP/IP) entry and click the Properties button.
   
4. On the General tab of the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.
   
5. On the General tab of the Advanced TCP/IP Settings dialog box, note the Use default gateway on remote network option.

This is a very significant setting, because it can make the difference between having a secure VPN client connection or allowing your VPN clients to become hacker gateways.

By default, the Use default gateway on the remote network option is enabled. When the VPN client establishes a link with the VPN server, a new default route is created on the VPN client and appears in the VPN client’s routing table. You can view the new route by opening a command prompt and typing the route print command. This new default route replaces the old default gateway that may have been set on the VPN client when the dial-up connection was established. If a dial-up connection is used, the default gateway is typically the ISP’s router. This allows the dial-up clients to access the Internet.

However, when the new default route is added, the VPN clients that have the Use default gateway on remote network cannot access the Internet, because the clients now use the VPN interface to route packets to remote (non-local) networks. As a VPN administrator, this is exactly what you want. You do not want VPN clients to be able to access your private network and the Internet at the same time. Doing so creates a significant security risk since the VPN client can become a gateway between the Internet and the private network.

While this is the best configuration for you and your network’s security, it will lead to many calls to the help desk. VPN users will complain loudly that they can’t surf the Web, connect to their AOL sex chat rooms, and perform any of the other unsavory activities that you have dutifully prevented them from doing through the corporate ISA Server.

The best solution to this problem is to configure the VPN clients to use the ISA Server as their proxy server. You can do this by configuring the browser on the VPN client to use the internal IP address of the ISA Sever for the VPN client’s Web Proxy connection. Perform the following steps on the VPN clients Internet Explorer to allow the VPN client to use the ISA Server as its Web Proxy:

1. Open Internet Explorer, click the Tools menu and then click Internet Options.
   
2. Click on the Connections tab. In the Dial-up and Virtual Private Network Settings list box, select the connection that represents the VPN connectoid. Then click the Settings button.

3. In the Settings dialog box, place a checkmark in the Use a proxy server for this connection checkbox. Enter the IP address of the internal interface of the Proxy server in the Address text box and 8080 in the Port text box. Click OK, and then click OK again.

Now the Browser is configured to use the Web Proxy service. You might be able to get away with the Automatically detect settings option if the machine has its domain name set to a domain on your internal network (and you have a WPAD entry configured for that domain). Forget about using DHCP. For a good explanation of why using DHCP is a dead-man’s option, check out Q312864.

Access to other Internet services that don’t work through the Web Proxy service, such as NNTP, SMTP and the dreaded IRC, requires the use of the Firewall client on the VPN client machine. You can not configure the VPN clients to be SecureNAT clients by using the internal interface of the ISA Server as their default gateway, since the clients already have a default route created for them by the VPN server. If you replace this default route manually, you won’t be able to use the VPN link to access corporate network resources through the VPN.

Note:

You can configure VPN clients to be SecureNAT clients, if the clients call a VPN server that is NOT the ISA Server. If the VPN server is configured to use the internal interface of the ISA Server as its default gateway, the VPN/RAS clients will be able to connect to the Internet through the ISA Server.

Now, I can already hear howls about how users won’t be able to handle the configuration requirements on the Web Proxy and enable or disable the Firewall client. I do not consider these valid complaints. If you provide the users simple instructions, as I have presented in this article, then making simple configuration changes are not difficult at all. If the users can do the following:

Then they can also make these configuration changes themselves. Keep in mind that allowing users to access the corporate network from a remote computer is a security decision. If a user cannot perform these simple tasks, can they be trusted with secure corporate data?

Indeed, balking at these simple security configuration steps may be a good measure of the “security trustworthiness” of an employee. If they cannot do these simple things to secure corporate information resources, what other “shortcuts” are they taking to subvert corporate security measures?

I belabor this point because it is an important one. I read a lot of questions on how to automate or otherwise hide very simple configuration steps to allow ISA Server clients to work, so as to make things easier or more transparent to users. I say forget about it. Unless you’re running a home for the mentally challanged, you don’t need to do these things. And if users actively, or through passive-aggressive actions, attempt to subvert your security infrastructure, they should be reported to the corporate security officer and flagged as a potential corporate security risk.

It makes no sense to do background checks on employees (on the assumption that background checks actually have some degree of external validity), if you choose to ignore actual proof that these employees are security risks. If you feel differently, act with the knowledge that you have lessened your overall level of network and corporate security.

We run into bigger problems if users decide they want to actively harpoon network security by disabling the Use default gateway on remote network option. When users disable this option, a network route is added to the VPN client’s routing table, but it is not a default route. The route added sends requests for the classful network ID the VPN client was assigned for its VPN interface.

For example, if the VPN client is assigned an IP address 10.0.1.100, a default route for network ID 10.0.0.0/8 is set on the VPN client. All packets for that network ID (and all subnets of that network ID) are sent to the VPN server via the client’s VPN interface. All other non-local packets are sent to the ISP’s remote router. The VPN client now has a direct link to both the Internet and the corporate network, and can effectively become a gateway between the Internet and the corporate network. Do you see a problem with this?

There may be ways to prevent users from changing the gateway setting. The Connection Manager Administration Kit allows you to create VPN connectoids and there may be a feature that allows you to prevent users from changing this option. I know that on a Windows XP Professional machine, an administrator can create a VPN connectoid and set the option that it is available to all users. When an average user logs in, they cannot access the Properties dialog box. However, if users configure their own VPN connectoids, they will be able to make whatever changes they like to the connectoid.

Perhaps a better way of ensuring the safety of your internal network is to design the IP addressing and routing scheme in such as way so that if users are able to set their VPN clients to not use the default gateway on the remote network, they still won’t be able to access anything other than resources on the ISA/VPN server itself.

The best way to do this is to assign the VPN clients off subnet IP addresses. An off subnet IP address is one that is not on the same network ID as the internal interface of the ISA/VPN server. For example, the internal interface of the ISA/VPN server is connected to network ID 10.0.0.0/16 and the VPN clients are assigned IP addresses in the 169.254.0.0/16 range. With this setup, VPN clients that are configured to not use the ISA/VPN server as their default gateway will be able to access resources on the ISA/VPN server, but won’t be access to access resources anywhere else on the internal network.

The reason for this is that that when the client is configured to not use the default gateway on the remote network, the actual default gateway on the client points to the ISP (the Internet). Therefore, any non-local requests (including those for network ID 10.0.0.0/16) will be forwarded to the Internet, which obviously won’t work. Even though the ISA/VPN server contains the proper routing table entries to forward requests to all the network IDs on the internal network, the off subnet VPN client won’t be able to take advantage of them because they are not using the ISA/VPN server as their default gateway.

There is another advantage of using off subnet IP addresses for the VPN clients. Consider the following scenario:

The VPN client is configured to not use the default gateway on the remote network. However, the VPN client is assigned an IP address that is valid on the network ID that is directly attached to the ISA/VPN server’s internal interface. Suppose the ISA/VPN server is directly attached to network ID 10.0.0.0/16, and the VPN client is assigned the IP address 10.0.0.100/8. Why is the VPN client assigned a different network ID? The reason is that VPN clients are always assign classfull addresses, as the route on the VPN client is a classfull route.

If you have configured a nice, hierarchical routing infrastructure, your internal network IDs and all subnets of 10.0.0.0/8, with network ID 10.0.0.0/16 at the top of the hierarchy. You’ll have a number of subnet IDs, such as 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 and so on. These are all subnets of the classfull network ID 10.0.0.0/8.

Now think about how you would summarize your internal network ID. You would create a route to network ID 10.0.0.0/8, which is exactly what the VPN server does for the VPN client. Therefore, even though the VPN client isn’t using the VPN server as its default gateway, it doesn’t need to. The reason for this is that all of your internal subnets are nicely summarized by the routing table entry created on the VPN client. If the client needs to get to network ID 10.1.0.0/16, it can do so because the routing table entry for the VPN interface is valid for routing requests to that network ID through the VPN interface.

It’s for this reason that you should configure the VPN clients with off-subnet addresses. The scenario above shows that if you don’t configure the clients with off subnet addresses, those clients can reach all internal subnets under certain circumstances. If the client were assigned on off-subnet address, it wouldn’t be able to reason any of the internal networks.

For optimum control over rogue VPN clients, you should configure them to use off subnet IP addresses. There is one drawback to this approach, and that is you won’t be able to use DHCP to assign addresses to the clients, as the DHCP server should be on the same network segment as the internal interface of the ISA Server. The VPN clients can still obtain WINS and DNS server addresses based on those set on the internal interface of the ISA/VPN server, so this should not present too much of a problem. However, if you require the assignment of DHCP options, then you’re out of luck.

If you do configure the ISA/VPN server to assign off subnet addresses, you must make sure that your routing infrastructure is set so that the off subnet network ID is reachable for all internal network clients (or at least those you wish the VPN clients to connect to). This means adding routing table entries on your network routers that point to the internal interface of the ISA/VPN server for the off subnet network ID. You can add these manually, or have a routing protocol such as RIP or OSPF do the heavy lifting.

One last way to dealing with the problem of VPN clients routing traffic from non-authenticated machines across the VPN connection is to take advantage of Remote Access Policies. You can configure your VPN Remote Access Policy Profiles to use packet filters to limit communicates only to the VPN client. This effectively prevents the VPN client from acting as a router between the Internet and the internal network.

Configure the following Remote Access Policy packet filters to limit communications to only the VPN client:

1. Open the Routing and Remote Access console.
   
2. Expand your server name and click on the Remote Access Policies node in the left pane of the console.
   
3. Double click on your VPN client Remote Access Policy. In this example we haven’t configured a special VPN Remote Access Policy, so we’ll use the default policy.
   
4. On the Settings tab, click the Edit Profile button.

5. In the Edit Dial-in Profile dialog box, click on the IP tab. Then click on the From client button.

6. In the Input Filters dialog box, click on the Add button.
   
7. In the Add IP Filter dialog box, select the Destination network checkbox to remove the checkmark. Leave the Protocol set as Any. Click OK.

8. In the Input Filters dialog box, select the Deny all traffic except those listed below option. Click OK.

9. On the IP tab, click the To client button.
   
10. On the Output Filters dialog box, click the Add button.
    
11. On the Add IP Filter dialog box, select the Source network option and remove the checkmark. Leave the Protocol as Any. Click OK.

12. Click OK in the Output Filters dialog box.

13. Click Apply and then click OK on the Edit Dial-in Profile dialog box.
    
14. Click OK in the Allow access if dial-in permission is enabled Properties dialog box.
    
15. Restart the Routing and Remote Access Service.

These filters should prevent Internet intruders that compromise the VPN client from routing requests through the VPN client.

VPN client security is integral to the success of your VPN networking solution. In this article we discussed several methods you can use to prevent your VPN clients from becoming significant security risks to your internal network. In future articles we’ll discuss some other methods you can use to secure your VPN client connections.