Use a PAC file to make proxy settings dynamic

June 23, 2009

in Applications

ProxySettings

Are you deploying browser proxy settings by setting a proxy server and attempting to manage a proxy bypass list? There is a better way..

Fortunately Jason Curnow, who’s had many years experience working with PAC files, has a website where he’s documented his experiences and shows you how to create your own – The Proxy PAC File Guide.

Any proxy server or firewall (a firewall is going to understand the network topology better than a proxy server) worth it’s salt will do this type of work for you. I know my favourite firewall, ISA Server does – Automatic Detection Concepts in ISA Server 2006 (I’m sure other proxy servers or firewalls do too).

In complex environments you may not be able to rely on your proxy server to handle browser configurations completely, so you’ll need to roll up your sleeves and roll your own PAC file.

So why a PAC file? Here’s a couple of scenarios that demonstrate the awesomeness of a PAC file:

  • Laptop users don’t need to disable their proxy settings when they’re outside the corporate network (OK, the ISA Server firewall client can do this too); and
  • If you have internal web applications hosted across WAN links (e.g. your users are in London but SAP is hosted in Ireland), you can use a PAC file to direct specific URLs to proxy servers that handle that SAP traffic only, whilst every thing else goes via your Internet proxy.

So go and check it out, Jason has done some excellent work – The Proxy PAC File Guide.

{ 4 comments }

1 Appreciative June 29, 2009 at 2:10 pm

So, what’s the advantage of a complex .pac file over good routing, proper DNS zone configuration, and GPO for browser control?

Even Jason’s reason for it seem more simply solved with private network exceptions and proper DNS configuration. How big can a bypass list really need to be? Can you give a detailed example where .pac files would be the easier method?

2 Aaron Parker June 29, 2009 at 2:59 pm

That’s a great question Appreciative, and I would also agree that a PAC file is no substitute for good DNS and proxy server configuration; however bringing those together may not be a simple thing for some large organisations. Our bypass list is currently fairly big because no-one has been managing it.

The best examples that I can give for a PAC file are those that I’ve listed in the article:
- Laptop users don’t need to adjust their proxy settings
- If you need to route some URLs through specific proxy servers you can with an auto-config script

Some other that I can think of:
- Instead of multiple GPOs for different BU’s or domains – centralise proxy settings in the script
- An auto-config script can change proxy settings based on client IP (e.g. VPN connections)
- Browsers will auto-detect by default, so with correct DNS configuration, you don’t need to deploy GPO at all

Ultimately, if you can make hard setting a proxy server work for you and a bypass list is manageable, then perhaps an auto-config script may be more work to implement. I would still recommend being familiar with PAC files as I think they’re pretty cool stuff.

3 David July 8, 2009 at 12:07 pm

Good routing and DNS are essential, without those it doesn’t matter how or why you are applying proxying.

Another way to look at this situation: Group Policy (GP) is designed to look after the internal enterprise through Group Policy Objects (GPO’s). In todays world, many corporate users will use a company laptop outwith the enterprise at least some of the time.

In a GP assigned environment, if the user wants to go on-line outside the corporate network they have to start manually disabling proxy settings, as GP is not clever enough to realise the laptop has left the corporate environment and should, therefore, turn off the proxy setting.

It is also becoming more common in industry to see companies performing remote filtering – i.e. continuing to police the web-content available on the laptop outside of the enterprise network. This can be achieved in several ways. One is to open port 8080 (or whatever port you are using for proxy) to the outside world with an associated public DNS entry. This, however, exposes a rather large (and somewhat unsavoury) hole in your firewall for the delivery of variable HTTP content.

The second is to use a remote-filtering system (such as that offered by Websense). The problem with the Websense system is that it will detect and filter when the system is outside the network, but will not swap the connection to the internal address when brought back in to the enterprise.

In the first scenario, you would be asking for trouble – opening the proxy port is providing potential attackers with lots of bi-directional obscure data traffic to hide within. The second scenario would still require the user to manually intervene with the proxy settings at some stage.

By introducing a PAC file, you do not need to trust users to make the correct changes. Trust me, there are some people who simply cannot grasp this – even though it is only un-checking a box. PAC files make the administration much easier . As a text file, it is much more straightforward to navigate than GPMC when adding exceptions. With GP, you must wait for the changes to replicate throughout the enterprise, then you need to wait for the client PCs to update their policies. This can take hours, depending on your replicate / update scehedules. With a PAC file, you modify it, save it and the changes are live – much more flexible!

david.

4 Brian September 9, 2009 at 2:19 am

If you are looking for a free http proxy list, check out http://www.pxylst.info

They check proxies every hour and display them to the public. Free.

Comments on this entry are closed.

Previous post:

Next post: