WPAD not working with "Auto detect settings" but works with "Auto Config script"
-
I am trying to setup WPAD, I have the correct DNS and DHCP settings.
wpad.dat
wpad.da
proxy.pacAll the files are available on a webserver. I can download them from the browser.
DNS lookup is working
Though when I try the "Automatically detect settings" it does not work in Chrome or IE
My web server log shows the file was downloaded by the client, also when DHCP is renewed the web server log shows the proxy.pac or wpad.dat file download from the server, mostly proxy.pacMy config looks like this
function FindProxyForURL(url,host)
{
return "PROXY 192.168.1.1:3128";
}Oddly when I select "Use automatic configuration script" and point to the wpad.dat file with either FQDN or IP it starts to work
What can I do to fix this.
-
What can I do to fix this.
Nothing, really. You already found a workaround. Unless you're going to try and fix how the browsers do things, I'm afraid there isn't much you can do.
-
The workaround does require doing the change manually on 120+ clients
I was wondering if the "Automatically Detect Settings" option would work by itself -
It's supposed to, but it's sometimes flaky. I have several Win7 boxes that work with wpad just fine, and one that absolutely must be manually configured. They're all the exact same make & model of PC, bought from the same store at the same time, all on the same network, same domain….
-
lol I did it the easy way. Domain machines. Group Policy. Just Saying :D
-
lol I did it the easy way. Domain machines. Group Policy. Just Saying :D
;D the "easy proprietary way" :P as it works only for Microsoft Windows domain and clients (and its emulations).
Better than nothing of course 8) -
Just like to share with you all things that I've tweaked to get "Automatically Detect Settings" working smoothly in my network of Windows 7 (IE and Chrome) and Mac computers.
My network has a very similar setup as polymathp i.e. there are the files — wpad.dat, wpad.da and proxy.pac, all served by vhosts running on pfSense and DNS and DHCP settings set accordingly. A user who was using Windows 7 Chrome highlighted to me that she surfed to https://login.live.com, and Chrome complained that it had a problem 'checking the certificate against the revocation server' and she asked whether she should continue logging in. However, when the site was accessed via IE, there wasn't such a problem. Weird! I also noticed that IE and Chrome weren't behaving very snappy; they would take more than a good few seconds to get to sites.
I tried the same site via Chrome and Safari on a Mac and there was no problem at all and there was no hint of a problem on the Mac accessing any website. Investigating the issue took me to http://findproxyforurl.com/deploying-wpad/ and in there it mentioned that webservers (the example on the site mentioned IIS and Apache) need to be configured such that MIME-type for files with extensions ".dat", etc is set as "x-ns-proxy-autoconfig".
So I looked at the config files for vhosts and noted that only ".pac" was set as such. And a bulb just lit in my head! No wonder Chrome and Safari running under the Macs weren't exhibiting the same problems, because the Macs use ".pac" file for Auto Detect, whereas the Windows machines use ".dat" or ".da" files. I added two more lines of MIME-type for ".dat" and ".da" in vhosts config, restarted vhosts and lo and behold the problem was gone for Chrome and IE under Windows 7. (To make the config a little more permanent in vhosts config, I have to hardcode the two lines in vhosts.inc. If any of you guys know the package maintainer for vhosts, I'd appreciate immensely if you could ask him/her to add this in the package. Thanks.)
Sorry for the long story, but I hope you get it working as well with this solution, which works for my setup.
-
Thanks torsurfer for pointing this out
I am using apache to serve the config file but I will move this to an IIS server and report back
