The Right Stuff

The Web Proxy Auto Discovery Protocol, WPAD for short, simply does what its name implies. An application connecting to the internet may search the local network to find information about proxies and rules which proxy to use when connecting to specific (i.e. local or remote) servers. WPAD leverages a JavaScript file called wpad.dat that is located on a WPAD server. The file itself is retrieved using HTTP. WPAD has been implemented by Netscape in 1996 has not changed much since then.

Publishing WPAD Information

Basically there are two ways for an application to detect the URL to the WPAD server:

• There is a DHCP option that tells DHCP clients where wpad.dat can be found on a network. By virtue of DHCP this information is only available to DHCP clients. The DHCP option 252 can be used to return an URL to the wpad.dat file, e.g. http://wpad/wpad.dat. Note that URLs specifying non-standard ports are also possible: http://wpad:79/wpad.dat.
• The other way to retrieve the wpad.dat script is to do a DNS lookup for a host named WPAD and do a HTTP GET for /wpad.dat on this host. The DNS option, however, provides less information to the client application because it only specifies the server and has no way of transmitting information about the HTTP port to the client.

Different Clients

Although WPAD has not become an internet standard yet, both Internet Explorer and Firefox try to acquire the WPAD script if you configure automatic proxy configuration, but in a slightly different way. Internet Explorer prefers DHCP information over DNS whereas Firefox only uses DNS.

Also, Window's built-in WinHTTP Web Proxy Auto-Discovery Service uses either DHCP or DNS to obtain WPAD information.

Possible Problems

Typically, the wpad.dat script is generated and served served by firewalls and proxy servers like Microsoft ISA Server based on the network configuration (you could also write your own custom WPAD script). The WPAD HTTP server, like any other HTTP server,  listens on port 80 for incoming requests. Because this would lead to conflicting ports if you're running another ("workhorse") HTTP server on port 80 of the firewall/proxy, WPAD-enabled firewalls and proxies typically let you choose an alternative port to listen for WPAD requests. All you need to do is to change the DHCP URL accordingly.

But what about the DNS case? As stated above, DNS does not carry port information. A successful DNS lookup for the WPAD host is all to justify a subsequent HTTP request to the server on port 80. But there's not the WPAD server answering, it's the workhorse HTTP server not knowing about a file called wpad.dat: HTTP/404. Bummer.

Solutions

Of course, you could copy wpad.dat to your "real" workhorse web server. But if the firewall/proxy configuration changes, you would need to copy the file over and over again. Certainly nothing a good network administrator strives for.

1. One solution I tried was enabling URL rewriting on the workhorse web server and redirect requests for /wpad.dat to the WPAD HTTP server running on the alternative port 79. Although Firefox understands HTTP redirects, they were ignored, presumably for security reasons. Does not work.
2. A proxiing redirect on the server would come in handy, but I couldn't find free ISAPI components doing this. If you like to spend some money, ISAPI_Rewrite may be your choice as it has the RewriteProxy directive. Works, if you are willing to spend money.

Wanting a free solution, I a proxy web site on the workhorse IIS with an ASP.NET IHttpHandler.

1. Set up your WPAD configuration so that the WPAD HTTP server listens on a port that is not used by other applications.
2. Create a host (A) DNS entry for the WPAD host, pointing to the IP address of your proxy/firewall that also hosts IIS.
3. Set up option 252 on your DHCP server giving it a value of http://wpad/wpad.dat. The port can be omitted as we're proxiing requests to the real WPAD server.
4. Create a new IIS web site on port 80, specify host headers wpad and wpad.your-domain. The web site should run as an ASP.NET 2.0 application.
5. Add a script mapping for .dat files so that they are processed by %windir%\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll. Be sure to uncheck the "Check that file exists" option.
6. Put these files in the web site's root folder, allow NTFS read access for IUSR_<Machine Name> and NETWORK SERVICE.
7. Open web.config with a text editor and adjust the URL to the real WPAD server in the only key of /configuration/appSettings.
8. Test your WPAD configuration with wget:

   rem Test the real WPAD server, this is what the proxy web site uses.
   wget http://wpad:<alternative port>/wpad.dat
   rem Test the proxy WPAD server, this is what clients use.
   wget http://wpad/wpad.dat
   

9. Test with Internet Explorer, Firefox and other clients. Take a look at the IIS log files if requests were served with HTTP status code 200.

Now Playing [?]: Fujiya & Miyagi – Cassettesingle