Tuesday, October 19, 2010

Configuring and troubleshooting WPAD

This is not an exhaustive reference to WPAD. WPAD provides automatic configuration to Internet clients such as the firewall client and Internet Explorer. Internet Explorer has a number of options to either manually specify the WPAD.dat file or to automatically detect the wpad.dat file using either DHCP or DNS. When both DHCP and DNS are configured with the WPAD URL, DHCP clients will only try the DNS URL if the URL has not been configured in DHCP.

When using TMG, WPAD can be distributed in two ways: -
1. By using the TMG default mechanism. This does not use IIS in any way.
2. By manually distributing the WPAD file on an IIS server.

Manual distribution via IIS
To distribute via IIS, firstly attain the WPAD file that you want to distribute. It should be called wpad.dat. Place in in the IIS website. In order to allow clients to download wpad.dat, you will need to add a MIME type into the IIS website as follows:
Extension: .dat
Content Type(MIME): application/octet-stream

If you are unable to download the WPAD.dat: -
1. Check that the MIME type is correctly configured. If you rename the extension to .html then does it become downloadable? If so, then the MIME type is not correctly configured.
2. Perform basic IIS troubleshooting to ensure it is serving pages correctly.

Distributing via TMG
When distributing via TMG, the WPAD file is automatically created. It is administered by changing the settings within the TMG console. You can select the port that TMG will distribute the WPAD file on. You should be able to acces the WPAD using the URL http://TMGserver/wpad.dat.

If you are unable to download the WPAD.dat at all then ensure the TMG WPAD service is not conflicting with any of the following:
1. An IIS server on the same server. If you are serving WPAD on port 80 and IIS is also configured to listen on port 80 then you will not be able to access WPAD. Stop the IIS website and change the port from 80 to 81 (just in case someone starts it up again). The assumption here is that IIS is not required for any purpose. TMG itself does not require IIS to be started.
2. A Web Listener configured in TMG to listen on the same port and on the same network. For example, if a Web Listener is listening on port 80 on the Internal interface, then you will not be able to publish WPAD on port 80.
3. Another third party service is listening on port 80.
4. A firewall may exist between the client and the TMG server.

If you are able to download the WPAD.dat but clients are not able to use it to access the Internet - it could be due to a bug in TMG 2010! If you configure VPN access to use an internal DHCP server, it will assign an internal IP address to the RRAS interface on the TMG server. VPN clients will also receive an internal IP address. Because the RRAS IP address is in the range of IP addresses listed on the "internal" network object, TMG will generate the WPAD.dat using the RRAS IP address. This means clients will be unable to connect to the Internet. Check the WPAD.dat for the IP address that is used. The workarounds are as follows: -
1. Use a static pool for VPN clients instead. This means the IP addresses are not in the internal IP address range.
2. Maintain the WPAD.dat on an IIS website - this requires manually updating the WPAD.dat each time a change is required.
3. 3. Run a short vbscript on the server that makes TMG generate the WPAD using the FQDN of the server instead. You then need to make sure that this FQDN resolves to the correct IP address for WPAD clients. This issue is mentioned here http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeIA/thread/2c4e342f-0ab7-4cd7-b007-0f2b0c559704. The solution script is here http://blogs.technet.com/b/isablog/archive/2008/06/26/understanding-by-design-behavior-of-isa-server-2006-using-kerberos-authentication-for-web-proxy-requests-on-isa-server-2006-with-nlb.aspx.

This is the script that needs to be run on the TMG server. It causes the firewall service to restart shortly after the script is run. This script has been tested by us and confirmed to resolve the issue.

Const fpcCarpNameSystem_DNS = 0
Const fpcCarpNameSystem_WINS = 1
Const fpcCarpNameSystem_IP = 2

Dim oISA: Set oISA = CreateObject( "FPC.Root" )
Dim oArray: Set oArray = oISA.GetContainingArray
Dim oWebProxy: Set oWebProxy = oArray.ArrayPolicy.WebProxy

If fpcCarpNameSystem_DNS = oWebProxy.CarpNameSystem Then
WScript.Echo "ISA is already configured to provide DNS names in the WPAD script"
WScript.Quit
End If

oWebProxy.CarpNameSystem = fpcCarpNameSystem_DNS
oWebProxy.Save true

WScript.Echo "ISA was configured to provide DNS names in the WPAD script..."

No comments:

Post a Comment