How DHCP/DNS Server Works in Web Proxy Autodiscovery Protocol (WPAD) for Today’s Browsers
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.
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.
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
wpad.some-company.net. Following the tail of
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
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
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
http://wpad.some-company.net/wpad.dat, it should iteratively try to find within the higher domain e.g.
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.
For trailing character in WPAD value mentioned earlier, I once configured option 252 value with “
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):
- IE 6
- IE 8
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)"
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)"
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.