I wrote a blog post on WPAD some time back to be specific this one http://blogs.technet.com/b/sooraj-sec/archive/2011/07/07/wpad-is-working-or-not.aspx and I got case on a subject related to this ,I thought the post and the details in it ,will be good enough to completely resolve this issue ,but it turned out that there were more interesting things to be discovered. Once again we were dealing with an issue, where autodetection with WPAD was not working as expected, using DHCP option 252 and it was falling back to DNS, so objective was to find out why autodetect was not picking up WPAD DHCP option 252 ,although it was configured properly.
So while doing testautodetect of FWCtool , we collected network traces and to my surprise we were seeing following in the DHCP response
– Dhcp: Reply, MsgType = ACK, TransactionID = 0xxx
OpCode: Reply, 2(0x02)
HardwareAddressLength: x (0xx)
HopCount: 0 (0x0)
TransactionID: x (0xx)
Seconds: 0 (0x0)
+ Flags: 0 (0x0)
+ ClientHardwareAddress: xxxx
+ MessageType: ACK – Type 53
+ ServerIdentifier: x- Type 54
+ SubnetMask: x- Type 1
+ DomainName: suraj.contoso.local- Type 15
+ Router: x.x.x.x – Type 3
+ DomainNameServer: x.x.x.x.x – Type 6
– WPAD: http://surajisa.suraj.contoso.local:80/wpad.dat – Type 252
OpCode: Web Proxy Auto Detection (WPAD), 252(0xFC)
Length: 55 (0x37)
which means that DHCP server was replying with option 252 for WPAD and the URL of the ISA server i.e.
but twist was that client machine was not consuming this and was not able to detect WPAD from DHCP.
I gave procmon a try(while doing autodetect) ,to see if there is issue with permissions on files, on the machine but answer was no, I could not find any permission issue with files/registries etc.
Following article explained the this issue http://support.microsoft.com/kb/2738141 and we applied this article and we were able to detect the WPAD settings using DHCP option 252.