How automatic proxy detection really works

(*) We’re speaking about Internet Explorer on Windows XP here.

Everybody knows (ok, not everybody but at least those who have ever wondered and tried to set this up) that:

1. Proxy auto detection is configured in DHCP by setting Option 252 for a respective scope;

2. String value set in that option has format http://servername/filename.pac and points to a file with a script that browser runs against every URL requested;

Microsoft’s description (that you can easily “google” on TechNet) will kindly tell you the same BUT the only thing they won’t tell you is WHEN Internet Explore tries to get that link, HOW it does that and what PREREQUISITES are.

Many people also presume that the aforementioned option is communicated to the client along with IP address and other options in initial DHCP Offer message. This is a WRONG assumption! I have seen endless amount of posts on different forums where people blamed particular versions of their DHCP servers, blamed Microsoft for glitches in IE and Windows,  blamed their network administrators and the like for non working option 252 and consequently the whole proxy auto detection process.

IN FACT the process looks as follows (fire up the Wireshark and check it out yourself!):

1. First of all you have to set up Option 252 in DHCP. This is done as follows (all examples here are for Cisco IOS, refer to documentation for your particular Windows- and Linux-based DHCP services) #option 252 ascii http://servername/filename.pac
2. Then, obviously, you would need to create a script and put it on a web-server accessible via that linkfor all your clients. Scripts can become quite sophisticated and look like this one:
   
   function FindProxyForURL(url, host) {if (isInNet(host, “192.168.0.0”, “255.255.0.0”) ||
   isInNet(host, “10.11.0.0”, “255.255.0.0”) ||
   dnsResolve(host)==”127.0.0.1″ ||
   isPlainHostName(host)) { return “DIRECT”; }if ( shExpMatch(url, “*193.195.121.106*”) ||
   shExpMatch(url, “ftp://*.site1.co.uk/*”) ||
   shExpMatch(url, “http://*.site2.com/
   *”)     )    { return “DIRECT”; }
   if (isInNet(myIpAddress(), “192.168.40.0”, “255.255.255.0”) ||
   isInNet(myIpAddress(), “0.0.0.0”, “255.255.255.255”) ||
   isInNet(myIpAddress(), “192.168.50.0”, “255.255.255.0”)) { return “PROXY proxy2.yourdomain.com:3128”; }
   if ( isInNet(myIpAddress(), “10.20.0.0”, “255.255.0.0”) ||
   isInNet(myIpAddress(), “10.30.40.0”, “255.255.255.0”)    ) return “PROXY proxy1.yourdomain.com:8080”;

   else         return “DIRECT”; } 

3.  Then, the most interesting thing, how IE gets the information above:
   1. Browser broadcasts DHCP Inform message and waits for an answer from a DHCP server. Answer is sent by DHCP server in a form of DHCP Acknowledgement message. If you have more than one DHCP servers on the client’s subnet it is likely that you’ll get responses from all of them but the browser will use only the first one. Do pay attention to this fact otherwise you may come across quite weird issues when some of your clients work as expected and some just do not work.
   2. As I already said above that Option 252 is NOT INCLUDED into standard DHCP Offer message sent to client as part of standard process of dynamic host configuration. I find this quite illogical but this is true. Although you will find a lot of other options sent in that message by default, our favourite one won’t be there.
   3. Browser DOES NOT send DHCP Inform every time it starts or every time you tick/untick respective box
      
   4. Moreover, browser DOES NOT send that message AFTER every REBOOT of the operating system. Which is really confusing and is an excellent example of BAD SOFTWARE DESIGN from my perspective.
   5. Before shouting “- Hey, are there any proxy servers on this network??” browser will actually check how long it has been on this network. And it makes an assumption based on the current IP address lease status.

      If it has just received an IP address (in other words if there was a standard full sequence of DHCP Discover > Offer > Request > Ack since (or during) Windows startup then the browser will send DHCP Inform as soon as it is started. If that sequence has not been present (which will be the case most time Windows boots on the network with say 8 days lease, default on many DHCP-servers) browser will be assuming that it is still on the same network and nothing has changed on it (WHY ON EARTH DID THEY DESIGN IT LIKE THIS?! Ohhh, Microsoft! We adore you! You give us job!) and will be using cached copy of the PAC file!

      Obviously, you can force the aforementioned sequence having issued “ipconfig /release” followed by “ipconfig /renew”:

      

   6. By the way, to see only DHCP messages you can set a filter in Wireshark as shown on the above screenshot

So, this is what it looks like, briefly… 🙂

Another life/time saver tip for Cisco network admins (it took me a lot of time to troubleshoot this one being on “fully managed” WAN without any ability to have a look at the running-config of routers at remote sites).

Cisco IOS interprets quotes around the link in Option 252 differently depending on IOS version!!!

On some versions you may put in config the quoted string and it will be sent correctly – WITHOUT QUOTES, on others you will put quotes and your router will send them along with the actual string thus totally confusing internet browsers (IE will simply fail to recognize the link sent and won’t detect proxy).

So, DO CHECK HOW IT WORKS ON YOUR VERSIONS OF IOS.