Web Filtering for DirectAccess users

Many companies rely on web browser content filtering to protect their businesses from malware or other unwanted content from appearing on their computers, and they commonly do so using services such as Microsoft’s Threat Management Gateway (TMG) which is a great HTTP proxy server. When the client computers are in one location or share a single internet connection, a proxy server is a rather elegant solution, but when the workforce is mobile and use remote connectivity solutions like VPN or DirectAccess, forcing the web browser through a proxy can be troublesome. In this article, I’ll show you how you can leverage TMG as an HTTP proxy for your mobile users yet still allow the users to use their browser if the proxy is unavailable.

The Challenge: Captive Portals

What is it about “Mobile Users” that make an HTTP Proxy a potentially difficult implementation for content filtering? For starters, the proxy server will typically be located inside a corporate network and depends on the client having some kind of tunnel connection like VPN or DirectAccess to establish link to that corporate network. If the browser if forced to use the proxy but that tunnel is not available, then the client cannot communicate with the proxy and then cannot access any web pages, including those which are local to the client computer.

When or why would the tunnel not be available? In the case of VPN, that would happen whenever the user has not opened the VPN connection. DirectAccess on the other hand is “always on” so it should always be available, but there is at least one caveat that also affects both tunneling solutions: Captive Portals.

When visiting a location like a coffee shop or a hotel and connecting to a wireless network, most service providers present a “captive portal” login web page that requires a visitor to either log in or click through an agreement page before being granted access to the Internet. This click through prevents the DirectAccess (or VPN) tunnel from coming online until the connection to the Internet is granted, and without the tunnel, the proxy server cannot be reached, and without the proxy server no web pages can be loaded, and that prevents the user from accessing the captive portal page. So the user is stuck with a connection that doesn’t allow them to establish the tunnel to the corpnet where the proxy server is.

So how do you break out of this chicken and egg scenario?

The Solution: Automatic Proxy Configuration

In most deployments of HTTP proxies that I see, companies are using a Group Policy to directly configure the proxy server address. This works great when the proxy is local and always available, but mobile users will effectively be broken when they can’t find the proxy server (as illustrated above). What can be done instead is configure the browser to use an Automatic Proxy Configuration Script which will configure the proxy settings for you, as the name suggests.

The real benefit of using this is when the configuration script cannot be found, the browser is allowed to access the network without the proxy, and that answers the “no tunnel to the corpnet” conundrum.

Of course this also offers a potential opportunity for the clients to access the unfiltered Internet, but you can use Group Policy to attempt rediscovery of the configuration script at a regular interval which will minimize the opportunity window for non-proxy browsing.

Pretty straight forward right? It is! so how do you implement it?

The Setup: TMG

Microsoft Threat Management Gateway can function as your web proxy as well as generate and host the configuration script for you. The script is a simple text file that includes the various settings you define the TMG console, which includes things like sites to exclude from the proxy as well as where to find the proxy itself. By default this script will use an IPv4 address as the proxy name, and that will not work for DirectAccess clients because they must use Hostnames / DNS in order to traverse the DirectAccess tunnel. So the first order of business is to tell TMG to use a Hostname instead of IP in the script.

Ori Yosefi wrote a blog post that includes the VBS script below. You’ll need to run this on your TMG server, and it will restart the firewall server, so be aware that there will be a momentary outage while it restarts.

Now configure TMG as a WPAD server by opening the TMG console and edit the Properties of the Internal Network. On the Tasks tab check the box to “Publish automatic discovery information” and optionally change the port to use 80 (http).

Once that is complete and you’ve applied the changes to TMG, you should be able point your web browser to http://yourtmgserver/wpad.dat to download the configuration script to examine it in Notepad. Any changes you would like to make to the script, such as sites you want to bypass the proxy (like your own web site perhaps) can be made on the Web Browser tab of the Internal Network properties page.

If you are curious, the Web Proxy tab will also show you which port the web proxy is listening on (usually 8080).

At this point you should be able to manually configure a test client computer to use the auto-proxy configure script and validate that the web traffic is indeed using the proxy server and content is getting filtered. Open Internet Explorer, go to Internet Options, Connections, LAN Settings and check “Use automatic configuration script” and then enter the address to your script.

Once configured, you can use the TMG Monitor to examine connections to the web proxy and see http requests that are being allowed or denied. Now is a good time to create your groups of filtering rules if you haven’t already. If you think you are having problems getting the script to apply, you can also try manually setting the proxy on your test client to ensure that TMG web filtering is working.

The Setup: Group Policy

Once the wpad script and web filtering is working for you, it’s time to configure the proxy settings using Group Policy. Configuring a proxy server is a User setting, not a computer setting. This means the policy will apply to Users regardless of where they log in and not just their workstation, which might be something to consider if your people are using multiple computers or remote desktop environments. Another option would be to create the policy and enable loop back processing to apply the policy to a set of computers if you prefer.

Once you’re done, apply the GPO to a user (or computer if using loop back) and test it out!

The Catch: Dial-up Users

By now, everyone that is getting the new group policy and it accessing the Internet via a network (LAN or WLAN interfaces) will automatically start using the proxy server, but there is potential that a certain group of your mobile users might not not fit that description: Users with cellular modems, or EVDO devices. These devices are considered modems and are not subject to the LAN settings and instead have their own Dial-up Settings. This means that computers that use a dial-up connection will not attempt to use the atuo-proxy config script and will browse the unfiltered internet. Let’s address that one too!

Note: If you have a “mobile hot spot” like a MiFi or an iPhone or Droid that you connect via Wireless LAN in order to get access over a cellular network (sometimes called wireless tethering) then you are not using a “modem” and do not need to worry about this scenario. Only those connections that appear in the “Dial-up and Virtual Private Networking setting” portion of the Internet Options / connections tab need special consideration, such as embedded or usb cellular devices.

There is no Group Policy to configure this directly, so the best solution I have found is to manually configure one computer that already has the dial-up connection to use the auto-proxy script, export the registry settings it creates and then apply those settings to other computers via Group Policy.

Now open Regedit and navigate to HKCUSoftwareMicrosoftWindowsCurrentVersionInternet SettingsConnections where you should find a new key with the same name as your dial-up connection. This name is important as the dial-up connection name on the client computers must match the name in your policy in order to apply the proxy setting. You can always change the name on the client computers by renaming the interface from the Network Control Panel to make them match your policy.

It make sense that this would be another setting of the same policy you created earlier, so edit the previous policy and navigate to User Configuration Preferences Windows Settings Registry. You can right click and use the Registry Wizard to import the key, or create a new REG_BINARY key for your encoded proxy settings.

Now you can apply these settings and any user with a matching dial-up connection will use the auto-proxy script just like users who are connecting from a wired or wireless network.

The Conclusion: Filtered Web Browsing with a Split Tunnel

And there you have it, a flexible way to provide a safer Internet browsing experience to your mobile users yet not hindering their ability to use their browser in scenarios where they might not be able to immediately reach the proxy server.

Another advantage to this deployment model is you are not requiring that all network traffic be brought back to the corporate network (forced tunneling). Only the web traffic comes over the tunnel and all other traffic is still able to use the split tunnel network. This allows users to reach local file shares or local intranet services and really delivers a well rounded functional device for your users.

Infrastructure Architect and Server Team Lead at Concurrency. Shannon is an MVP in Forefront and Enterprise Security, MCSE in Private Cloud and MCSA Windows Server 2012. He's also a self-professed media junkie. Just ask him about MediaCenter!