How to use automatic proxy discovery with a Smoothwall web filter

Article #: Product Castle
1643 / KB-24 Guardian All

Summary

Using Automatic Proxy discovery with a Smoothwall web filter.

Problem

Most desktop browsers support a feature called "Automatic Proxy Discovery". This feature is an easy and efficient way to configure proxy settings on most desktop browsers simply by enabling the automatic proxy discovery in the proxy settings of the browser.

One benefit of using this feature is that users on laptops will automatically configure proxy settings in their browser on the local network. When the user is outside the local network, proxy settings will not be implemented. This means that there is no need to allow users control over proxy settings in order for them to be able to disable the proxy when they are outside their local network. Another benefit is the ability to quickly configure guest user browsers - just ask them to enable automatic proxy discovery. No need to enter proxy host or IP and port numbers and exceptions on the guest system.

Firefox automatic Proxy setting.

Internet Explorer Automatic Proxy Settings

The automatic proxy discovery feature relies on using a configuration script which is automatically generated on the Smoothwall. This script is configured in the Web proxy > Web proxy > Automatic configuration page. A script can be setup for each interface that has a proxy running. The generated script will only contain information for one proxy in case there are multiple proxies on the same interface. A manually created configuration script can be uploaded to the Smoothwall in case of more complex scripts being needed. The exceptions field should be populated with internal subnets, local domains and other destinations that require direct access, bypassing the Smoothwall web filter.Once the configuration scripts have been created, we can start configuring the network services needed to provide clients with the location of the configuration script.

Solution

In order to provide clients with the information needed to locate the scripts we need to add a CNAME entry to your DNS server for the hostname wpad. When a browser has the automatic proxy discovery enabled the browser will try to resolve the hostname of wpad on your local network. If this name resolves to an IP address, the browser will request the script file called "wpad.dat" over http. You can download the file from the Smoothwall directly to see the contents of the file by using the URL:

  • http://ip.address.of.smoothwall/proxy.pacor
  • http://ip.address.of.smoothwall/wpad.dat

On a Microsoft DNS server the hostname of wpad is in the global blocklist by default so this entry needs to be removed so the DNS server will allow clients to resolve the wpad hostname. The reason for the wpad hostname being in the global blocklist by default is to prevent a dynamic DNS entry of the name wpad being generated by a system receiving IP over DHCP. If this entry is added as a static entry that risk is negated.

In order to remove the wpad entry from the DNS server global blocklist, open a command prompt on your DNS server systems and run the following commands:

  • To show the global blocklist entries issue the command:

dnscmd /info /globalqueryblocklist

This command will likely show 2 entries: isatap and wpad

  • To write a new list:

dnscmd /config /globalqueryblocklist isatap

This will write a new blocklist just containing the name isatap — check that wpad is no longer in the list by issuing the list command again.

Once done, we need to add a CNAME entry to your DNS using the name of wpad and pointing to the Smoothwall hostname. Here is an example from a test domain where the Smoothwall hostname is utm.training.local - I have added an alias, a CNAME entry called "wpad" which points to the Smoothwall hostname:

Always use CNAME if a system needs additional hostnames. Only one regular hostname entry should exist for any IP — if a system needs multiple hostnames, add CNAMES for the additional hostname entries.

Now it's time to test if the wpad name can be resolved by your clients. Open up a command line on a local system and run this command first to flush the DNS cache on the system:

ipconfig /flushdns

Then try to ping wpad:

It is important that the hostname wpad only can be resolved without adding the local domain. The client should be adding the domain as part of its local domain settings or as part of the search domains set in the DHCP server.

If the wpad hostname resolves correctly, start up a desktop browser, enable the automatic discovery and test that the browser is using the proxy.

Your network is now ready to use Automatic proxy discovery.

The following Microsoft articles may provide further information:

Attribution:

Last updated: Author: Contributions by:
6th December 2016   TE