Home / server / Questions / 69804
In Process
jhaar
Asked: 2009-09-30 18:10:56 +0800 CST

enterprise alternatives to WPAD proxy configuration?

  • 772

We have 40+ sites in 20+ countries. We use egress filtering and force most users through proxy servers via WPAD.

WPAD is great and works 99.9% for us. However, we have had a few cases where WPAD support issues has caused browsers (only MSIE - on rare occasions) or 3rd party apps (WebEX voip) to fail to work as they do not correctly figure out where the local proxy is - try direct - and fail.

So are there any other mechanisms for enabling enterprises with a plethora of egress points/proxies to be able to support all browsers (ie not just MSIE) and other web-clients - besides WPAD? As I mentioned, WPAD actually works 99.9% for us, but the trouble with that situation is that people only "see" the failures - and grizzling begins...

PS: no, "use DHCP" is not a different option. That is merely an alternative mechanism to deliver WPAD (the primary being DNS). Just thought I'd answer that before someone else does ;-)

Thanks

Jason

web

1 Answers

  1. Your only choices that I'm aware of are:

    • Configure the client software to "know" where the proxy is "by hand". This is probably a losing battle, since you can't possibly anticipate all potential client software. You end up with a mess of scripts, registry merges, MSI transforms, and a whole host of glue-and-tape to try and pre-configure client software, and then something new slips in under the radar and doesn't work.

    • Use standard automated configuration mechanisms like Windows Proxy Auto-Detect (WPAD). As you're seeing, this is not 100% reliable.

    • Use a client-side "shim" into the TCP/IP stack, such as Microsoft's "Firewall Client" for ISA Server. The only product that does this that I'm aware of is the Microsoft ISA Server / Firewall Client product. This works very, very well, but is highly proprietary and Windows-specific.

    • Use transparent proxying hardware / software to cause traffic to be proxied. This works well in many cases (using ebtables under Linux you can actually create a layer 2 HTTP proxy that's totally transparent to clients, for example), but has the side-effect of preventing the use of HTTP proxy authentication (since the browser / client doesn't know it's being proxied -- it won't handle it properly).

    It's a "pick your poison" type of scenario.

    • 2