WPAD madness
Monday, September 24, 2007
Our firewall at work does not yet support transparent proxying. As a result I had to reconfigure my browser 2 times a day : when I start my laptop at work and in the evening when I do the same at home. But why do something yourself if it can be automated ? So, as a “workaround” for transparent proxying I set up wpad on one of our backoffice webservers today. I chose the dns based solution, so I set up the following :
- A CNAME that poins wpad.lan to webserver.lan
- A vhost on webserver for wpad.lan serving wpad.dat
- A proper wpad.dat
I’ve set up wpad more then once and already knew that it’s very important to force the mime-type of wpad.dat to “application/x-ns-proxy-autoconfig”. The only thing left to do was to configure my browser to automatically discover it’s proxy settings. Et voila, wpad up and running, worked like a breeze in my firefox.
Enter $colleague and happy internet explorer (7) user. He was also tired of having to configure his browser twice a day, so naturally he tried the same. Result : nothing. I didn’t work ?!? But it still worked for me, so the setup can’t be wrong, can it ? After some testing the reason became clear to me.
Normally you’d expect that when you fetch http://wpad.lan/wpad.dat and, like in my setup, wpad.lan is a CNAME for server.lan, the webserver will get a request for /wpad.dat on the vhost wpad.lan. At least that’s how it works with normal virtual hosting. And that’s exactly how firefox does it.
But not in the world of Bill Inc. In that universe, the browser will try to fetch http://server.lan/wpad.dat. So after making the wpad script available in the webroot of server.lan everything worked.