How DHCP/DNS Server Works in Web Proxy Autodiscovery Protocol (WPAD) for Today’s Browsers

In General Linux on 15 May 2013 with 1 comment flame_ico 6110 views

Web Proxy Autodiscovery Protocol (WPAD) protocol draft expired in 1999, but today’s major browsers are still supporting it as will be shown later. Two types of DHCP server are tested to describe how WPAD behaves prior to/after starting up the internet browser. To be clear, uploaded packet captures are shared in CloudShark. DNS and domain resolution is a must for the WPAD to work when MS Windows Internet Options configured to “Automatically detect settings” (for IE 6 in Windows XP desktop, IE 8 in Windows 7 desktop, and Google Chrome) or Firefox to “Auto-detect proxy settings for this network“. As simplest DNS setting should work, this post will not cover its configuration.

Low level view of WPAD interactions involving DHCP, DNS, and HTTP servers in packet capture (shared in CloudShark)

In DHCP discovery-offer-request-acknowledgement cycle, WPAD information is given in option 252 (check section 4.4.1 of the draft). I used dhcpd3-server package in Ubuntu and setup /ip dhcp-server option add code=252 ... in Mikrotik 5.20 for example variations. For both, trailing “\n” are added to wpad.dat URL value as most howtos recommend.

"http://wpad.some-company.net/wpad.dat\n"

In the above example value, wpad.dat is hosted in Apache2 HTTP server resolvable by the DNS to the actual host IP of wpad.some-company.net. When the client use all DHCP offered items, it gets domain name (option 15) some-company.net besides other things e.g. router (option 3), DNS (option 6), etc. In a case where the client use its own DNS (only use IP from DHCP), WPAD likely won’t work unless it is able to resolve the example some-company.net or wpad.some-company.net. Following the tail of /var/log/apache2/access.log, successful wpad.dat request will appear as

192.168.40.75 - - [01/May/2013:21:51:15 +0700] "GET /wpad.dat HTTP/1.1" 200 1070 "-" "-"

In the above tail, I enabled a Windows 7′s network adapter (from previously disabled) and it would soon try to HTTP GET the wpad.dat even when no browser opened yet.

From testing with Windows XP, Windows 7, and Ubuntu (with different browsers mostly), DHCP Inform‘s WPAD behavior can be seen with Windows 7 test by analyzing the packet going out after some time since the initial DHCP stream (check the packet capture for 7 seconds after DHCP Discover). It asked for WPAD in one of the Parameter Request List Item (apply the filter bootp.option.request_list_item == 252 for a closer look), but received no answer.

I failed to reproduce other samples of DHCP Inform packet asking for WPAD. Hence, for the rest, it’s the browser who is doing the GET to http://wpad.some-company.net/wpad.dat with DHCP only supplied domain name instead of complete WPAD (check another packet capture, this time for Ubuntu with Firefox 20). The GET attempt isn’t actually one shot attempt. When it fails to find the wpad.dat in http://wpad.some-company.net/wpad.dat, it should iteratively try to find within the higher domain e.g. http://some-company.net/wpad.dat.

Getting proxy setting (WPAD) from DHCP or directly by browser iterative decision

DHCP server configuration used, wpad.dat file example (I simply use symbolic link to proxy.pac), and Apache2 VirtualHost config are available in my github, an attempt to integrate Squid3 cache with WPAD, PAC, and DHCP.

History

For trailing character in WPAD value mentioned earlier, I once configured option 252 value with “wpad.dat\?“, “proxy.pa“, and some other likely wrong variations. I also configured the browser in Windows XP and 7 with these variations of wrong values before getting the browser to use proxy auto-discovery again. Somehow it kept the wrong GET with trailing character resulting in 404 (page not found):

Firefox

192.168.40.78 - - [30/Apr/2013:16:20:39 +0700] "GET /wpad.dat/ HTTP/1.1" 404 478 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

IE 6

192.168.40.78 - - [30/Apr/2013:16:28:07 +0700] "GET /wpad.dat/ HTTP/1.1" 404 478 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

IE 8

192.168.40.77 - - [01/May/2013:20:07:24 +0700] "GET /wpad.dat/? HTTP/1.1" 404 534 "-" "-"

I was able to force it to GET the correct WPAD value by adding new network adapter which received different IP lease from DHCP server. Afterwards, connecting with the old adapter will also keep correct behavior.

I still don’t know how they keep the previously incorrect behavior. In short we can’t rely on WPAD alone, but there is probability that some portions of the network clients will find the proxy this way, automatically without technical assistance.

logIt Log Around The Clock