none
WPAD + dhcp + IE + CRL (+WinHTTP)

    Question

  • I'm having the following problem with WPAD distributed in my subnet with DHCP:

    My local subnet is part of a big company WAN. All PCs on all the subnets are members of a single AD domain, let's call it "thebigcompany.com". TheBigCompany created a simple "wpad.thebigcompany.com" host, with IIS and a wpad.dat which just return "DIRECT" as result.

    In my subnet I have a proxy server, and all clients internet requests are blocked at the firewall.
    Being unable to distribute the proxy server address to the clients via DNS as "wpad.thebigcompany.com" because it's already in use, I used DHCP: I setup option 252 with: http://mywpad.thebigcompany.com/wpad.dat.
    According to official docs, automatic DHCP has precedence over automatic DNS discovery.

    In this configuration IE is almost working: I left all IEs in autodiscovery mode (only the first checkbox enabled)  and all IEs in my subnet correctly can surf the Internet with my proxy.

    But there is a problem: when IE opens an https site, it wants to check CRLs also. And it uses WinHTTP to do this job. It seems that WinHTTP is still requesting http://wpad.thebigcompany.com/wpad.dat instead of honoring DHCP (this is confirmed by sniffing with network monitor). So WinHTTP gets the wpad.dat from TheBigCompany, wich returns "DIRECT" and IE hangs for half a minute in a SYN_SENT tcp connection.
    And the users complain :(

    I have tryed:

    1. proxycfg -p myproxyserver:port. It works: IE requests CRLs to proxy, but I loose my wpad.dat power, and I have problems with other WinHTTP based apps which are not able to be proxyed. And this is also a bad choice for laptops.
    2. Put a fake host in all clients:   192.168.X.X   wpad.thebigcompany.com
      where 192.168.X.X is mywpad server. Again, it works, but this will give problems to laptops moving from my subnet to other company subnet, because they will allways use my proxy when in the other subnets.

    So... what I'm doing wrong ? Is really WinHTTP proxy autodetection for IE CRLs giving precedence to DNS instead of DHCP ? Other solutions or workaround ?

    Thank you

    Giovanni

     

     

    Monday, December 06, 2010 11:33 PM

All replies

  • Hi Giovanni,

     

    Thanks for posting here.

     

    Which OS version running on DNS server ?

    If you are using widows server 2008 or above , have you removed WPAD from DNS block list?

     

    Please take look the article below:

     

    Removing WPAD from DNS block list

    http://technet.microsoft.com/en-us/library/cc995158.aspx

     

    You may also refer to the link below, it’s talking about the processing that how to implementing WPAD:

     

    About implementing WPAD

    http://technet.microsoft.com/en-us/library/cc995261.aspx

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, December 07, 2010 8:06 AM
  • As I wrote on my first post, all clients can resolve wpad.thebigcompany.com, so WPAD is removed from DNS blocklists. But I don't want to use the DNS record wpad.thebigcompany.com because it points to the WRONG wpad server, not the one on my subnet.


    I read A LOT of documents on WPAD implementation, but in no document I found reference to the way WinHTTP gives priority to DNS wpad autodiscovery or DHCP parameter 252 when cheching for CRLs (Certificate Revocation Lists).

    So, does REALLY WinHTTP (when used by IE CRL check) give precedence to DHCP parameter 252 ? In my case this is not happening and WinHTTP is reverting to the DNS autodiscovery, which is not correct for my subnet.

    In your second document: http://technet.microsoft.com/en-us/library/cc995261.aspx i read:

    "If you configure both DHCP and DNS, clients will attempt to query DHCP for automatic discovery information first and then query DNS."

    This is true for standard IE internet surfing, which is correctly working on my subnet. But it seems to be false when IE checks for CRLs revocation using WinHTTP.

     

     

    Tuesday, December 07, 2010 11:15 AM
  • Hi Giovanni,

     

    Thanks for update.

     

    I’d suggest you may take look automatic configuration script in this scenario .With customize and define conditions (for example the IP segment that acquired) you could restrict computers access internet through specific proxy server or directly. This script could also be easily distributed to entire company computers via Internet Explorer group policy.

     

    “JavaScript or JScript Auto-proxy Examples” paragraph in the article below:

     

    Chapter 26 - Using Automatic Configuration, Automatic Proxy, and Automatic Detection

    http://technet.microsoft.com/en-us/library/dd361918.aspx

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Wednesday, December 08, 2010 9:16 AM
  • I think it's a bug in cryptnet.dll.

    I did some low level debugging on cryptnet.dll (on windows XP), and I discovered that the function CryptRetrieveObjectByUrl() calls the function WinHttpGetProxyForUrl() of wininet.dll passing a constant value of "2" in the AutoproxyOptions.dwAutoDetectFlags.

    A value of "2" means WINHTTP_AUTO_DETECT_TYPE_DNS_A, which is wrong, because in the normal IE operations, IE would use DHCP also. So CryptRetrieveObjectByUrl() should use "3" instead of "2", and DHCP will start to work in CRL revocation check.

    I'm stuck.

    Wednesday, December 22, 2010 9:50 PM