3

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

jhaar
  • 181
  • 1
  • 1
  • 5
  • This question is more relevant than ever: WPAD is now considered a serious security risk: Ars: http://bit.ly/2QFuHts auth0: http://bit.ly/2QIFVxh – Mei Nov 15 '18 at 17:25

1 Answers1

2

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.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331