VPN Client Security Part 2: Forcing Firewall Policy on VPN Clients

VPN Client Security Part 2:
Forcing Firewall Policy on VPN Clients

By Thomas W Shinder M.D.

Most of us put together a VPN to allow external network clients secure access to the private network. We usually think of the VPN Server as a security device that protects the internal network from external attack. But is that really what happens? In reality, the VPN Server is just a Remote Access Server that allows RAS clients to use the Internet instead of the Public Switched Telephone Network as the transit network. Putting together a VPN Server doesn’t automatically confer security for remote access connections.

One of the most important things you can do to secure remote access VPN client connections is to prevent split tunneling. By default, a new default gateway is set when a Microsoft VPN client makes its connection to the VPN server. This new default gateway routes all packets not on the client’s directly connected network to the VPN server. This prevents the client from being able to connect to the Internet via its ISP connection for the duration of the VPN call.

This causes problems for users who want to connect to Internet sites and services while remaining connected to the VPN. If the VPN client is connected to a VPN server that is co-located on the ISA Server, the VPN client will not be able to connect to Internet services while using the default settings.

This is a good security configuration because it allows you to maintain network security for the duration of the VPN call. Why would you allow a VPN client to bypass your firewall policy while at the same time expecting all other network clients to be controlled by that policy? The VPN client typically has the same level of access any other internal network host has, so it makes sense for you to enforce the same policy on VPN connections. You don’t let users bring in modems and hook them up to their desktops (which would allow them to bypass the firewall), so why would you allow VPN clients to perform split tunneling?

Split tunneling is allowed or disallowed depending on the VPN client configuration settings. The key setting on the client is the Use default gateway on remote network. When checked, split tunneling is disabled. When not checked, the client is able to access the Internet via its ISP (or other direct connection) and the corporate network via the VPN interface. For more details on the implications of split tunneling and VPN client security, check out http://www.isaserver.org/tutorials/VPN_Client_Security_Issues.html

What if you want to allow the VPN clients Internet access? The only acceptable solution is to disable split tunneling and force them to connect to the Internet through the ISA Server. It’s relatively easy to configure the VPN clients as Web Proxy clients. The VPN/Web Proxy client can access HTTP, HTTPS, HTTP tunneled FTP and Gopher through the ISA Server’s Web Proxy service. You can find the details of this configuration at http://www.isaserver.org/tutorials/Solving_the_Mystery_of_the_VPNRASWeb_Proxy_Client.html

Things get a bit more complicated when you want to allow access to other protocols. Let’s look at two difference scenarios: when the VPN Server is co-located with the ISA Server, and when the VPN server is located on a machine separate from the ISA Server.

It’s very easy to configure the ISA Server machine to be a VPN Server. All you need to do is run the VPN Server Wizard from the ISA Management console. Just right click on the Network Configuration node in the left pane of the console and click the Allow VPN client connections command. Follow the Wizard and the Routing and Remote Access service is started and configured for you. There are a few housekeeping measures you need to take care of after the Wizard starts RRAS, but it does do most of the work. For details on configuring the ISA Server as a VPN Server, check out http://www.isaserver.org/tutorials/Configuring_ISA_Server_For_Inbound_VPN_Calls.html

You might have already tried this and found the VPN clients can’t connect to the Internet through the ISA Server. The reason for this is that the VPN clients cannot act as SecureNAT clients. There is no way for you to configure the VPN client to use the internal interface of the ISA Server as its default gateway. The default gateway is already set when the VPN client connects and its clearly not the ISA Server’s internal interface. While the details are a bit more complex than this, the fact remains that there is no solution to this problem; you will never make the VPN client a SecureNAT client.

The only other option you have is to configure the VPN clients to be Firewall clients. This is easy to do when the VPN client computer can be brought into the internal network, as you can install the Firewall client when the machine is plugged into the local LAN.

It’s a little bit harder to configure the VPN client as a Firewall client when the machine is never connected to the corporate LAN. You’ll usually see this situation when the VPN clients are desktop computers connected to a remote LAN. This can still be accomplished, but it has to be done while the VPN connection is active and the VPN client must be able to access the mspclnt share on the ISA Server (or wherever else that share might be installed). Your name resolution infrastructure must be in place, and it must be working if you expect to connect to the mspclnt share successfully.

Name resolution issues for the VPN client are often problematic. The Firewall client needs to be able to resolve the name of the ISA Server to the internal IP address of the ISA Server. You might think configuring a WINS and DNS server would be enough, but I’ve found the results to be somewhat inconsistent, even when I’ve gone out of my way to create a WINS referral zone in DNS. The best solution is to configure the VPN client to receive an address of a DNS server that can resolve the name the name of the internal interface of the ISA Server to its internal IP address.

If you do choose to use WINS or DNS, pay special attention to the appearance of the Firewall client icon in the system tray. Do some testing using the command line FTP application. If you can’t connect and you don’t see a GREEN up pointing arrow, let the mouse pointer hover over the firewall client tray icon. If you see a message indicating that the ISA Server cannot be found, you know you’ve run up against a name resolution issue.

The problem with DNS clients is that if they are configured to use a single label name for the ISA Server in the Firewall client configuration (as seen in the figure below), then they’ll have to qualify the request before sending it to the DNS server. When the Firewall clients are provided with a single label name, the DNS client must attempt to fully qualify the request. This typically isn’t an issue on the corporate network, were DNS clients are configured with a primary DNS domain name they append to unqualified requests. But VPN clients often are configured with a different domain name or no domain name at all. In that case, the connection attempt to the ISA Server’s Firewall service will fail. Keep these issues in mind when troubleshooting name resolution issues for your remote VPN clients.

Another thing to be careful of is the Automatically detect ISA server setting (seen in the figure below). You can’t use the DHCP option to assign the WPAD entry to the VPN client (because the DHCP Relay Agent doesn’t work after you install ISA Server), and the VPN client must be able to resolve the wpad alias correctly if you use DNS. The client will use its own primary DNS suffix to fully qualify the wpad entry, so this can be a significant issue with your VPN clients. This can be solved with a HOSTS file entry, as described below.

If you don’t want to mess with name resolution via WINS or DNS, you can use one of two foolproof methods. You can configure the Firewall client setup to use the IP address of the internal interface of the ISA Server (seen in the figure below) or you can configure a HOSTS file entry that includes the FQDN of the ISA Server and the ISA Server’s internal IP address. Unfortunately, neither of these options scales very well, although you can easily provide a HOSTS file for users to copy to the appropriate location (SYSTEMROOT\system32\drivers\etc).

You’ll be able to connect to the Internet using any protocol once the Firewall client is installed on the VPN client. Note that you must disable the Firewall client when establishing the VPN connection. If you leave the Firewall client enabled when attempting to establish the VPN connection, the connection attempt will fail.

The situation is different when the VPN client connects to a VPN server not co-located on the ISA Server. In this case, a “pseudo” SecureNAT client configuration will work on the VPN client. I call this a “pseudo” SecureNAT client because you do not configure the VPN client as a SecureNAT client because the VPN server automatically assigns the VPN client a default gateway. But it will work if the VPN Server is configured as a SecureNAT client of the ISA Server.

The VPN client in this scenario can access non-Web Proxy protocols because the VPN server is responsible for routing requests sent to it from the VPN client. The VPN server doesn’t have a specific routing table entry to support Internet bound requests, but it does have its default gateway. When the VPN server is configured to use the ISA Server as its default gateway, it can route these Internet bound requests to the ISA Server and forward the responses back to the VPN client. Note that the VPN server does not need to use the ISA Server’s internal interface as it’s default gateway. The only requirement is that it be configured as a SecureNAT client.

While this setup sounds simple, think about how you configure the Internet interface on the VPN server. Since the VPN server must be configured as a SecureNAT client, it cannot be used an Internet access server. You’ll have to use the Internet connection only for incoming requests from VPN clients or other “known” clients for which you can create routing table entries. If you have a busy VPN server, this isn’t much of a problem as you can take advantage of all the available bandwidth. But you’re out of luck if you want to use the bandwidth not used by VPN clients for general Internet access.

Once again, the way around this problem is to make the VPN clients Firewall clients. When you make the VPN clients Firewall clients, you can change the default gateway setting on the VPN server and use it for general Internet access. You also benefit from the other advantages of the Firewall client, such as access to complex protocols and better performance.

Name resolution issues are the same as you see when connecting to the co-located VPN/ISA Server. You must be sure to configure WINS and DNS Server addresses that can properly resolve the name of the ISA Server’s internal interface or use a HOSTS file to simplify name resolution if you don’t have the DNS expertise in house.

VPN security doesn’t stop with installing and configuration a VPN server. Preventing split tunneling for the VPN clients is crucial to a secure VPN client/server setup. You can still allow VPN clients to access the Internet, they just have to do it through the ISA Server. If VPN clients only require access to Web Proxy protocols (HTTPS, HTTPS, and HTTP tunneled FTP), then you can configure the VPN client as a Web Proxy client. If the VPN client requires access to the full range of Internet services, then you should consider installing the Firewall client on the VPN client. VPN clients have different levels of Internet access depending on whether or not the VPN server is co-located with the ISA Sever.

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, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=13;t=001201 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom