Systura Where information becomes knowledge...

I have been doing a lot of work with Blue Coat SG appliances recently.  For those who are not familiar with the Blue Coat SG appliances, the Blue Coat SG appliances are proxy appliances.  In working with the deployment of the Blue Coat SG, I have had to work with several Proxy Auto Configuration(PAC) files.  PAC files are javascript files which are evaluated by the browser to determine if the browser should use a proxy and which proxy.  The document that I typically use as a reference for PAC files can be found here.

In the process, I have written a generic PAC file that I normally start my customers with.  I have found so far that this PAC file covers 90% of my customers with little or no changes to the actual code, just changes to the configuration variable section.

My sample.pac

My sample PAC file is broken into three sections; configuration variable, internal functions, and the main proxy function.  The configuration variable section allows for the setting of variables that are specific for the customer environment, the internal functions process the information to make a determination, and the main proxy function is actual proxy function, FindProxyForURL.

For most customers, they only need to make changes to the configuration variable section.  My configuration variable section is the following:

//
// Define the internal domains.  This is a list of the internal domains that you want the client to go direct.
//
var internal_domains = new Array( ".systura.off");
//
// Define a list of internal hosts.  This is a list of the internal hosts that you want the client to go direct.
//
var internal_hosts = new Array( "internal.systura.com" );
//
// Define the internal networks.  This is a list of the internal networks that you want the client to go direct.
//
var internal_networks = new Array( "192.168.125.0/255.255.255.0", "192.168.102.0/255.255.255.0");
//
// Define the proxy
//
var internal_proxy = "PROXY bluecoat.systura.off:8080";
var internal_proxy_host = "bluecoat.systura.off";

These are the main variables that are used to determine if the proxy should be used or the client should go direct. "internal_domains" is a list of the customer's internal domains. The customer should list here the domains where the client should go direct versus using the proxy. "internal_hosts" are similar to the "internal_domains", except these are specific host names that the client should go direct. This is a recent addition to my sample PAC file as I had a client that had a few internal hosts with the same domain as they use on the Internet. The "internal_networks" are the customer's internal networks. For any host within any of these networks, the client should connect directly to the host.

Finally, the final two variables are "internal_proxy" and "internal_proxy_host".  The "internal_proxy" is what should be returned to the client to access the proxy.  The "internal_proxy_host" is the host name of the proxy.  This variable is tested to see if the name can be resolved, if resolvable, the client will use the proxy.  If not, the client will go direct.  Why define "internal_proxy_host"?  I did this as a test for laptops and notebooks.  When the client is connected to a client VPN or the internal network, "internal_proxy_host" should be resolvable and the client will use the proxy.  If not, like when they are working at home, they will go direct and still be able to surf.  Otherwise, you would have to allow the client to enable and disable to use of the PAC file.

My sample-loadbalance.pac

I have also created a second PAC file which will allow the load balancing of a set of proxies based on the URL the client is attempting to connect to.  The difference between the sample.pac file and the sample-loadbalance.pac file is mainly in the configuration.  The proxy is now defined by the following section:

//
// Define the proxy
//
var load_balance_flag = true;
var internal_proxy = new Array( "PROXY bluecoat01.herjavecgroup.off:8080",
                                "PROXY bluecoat02.herjavecgroup.off:8080"
                               );
var internal_proxy_host = "bluecoat01.herjavecgroup.off";

The "load_balance_flag" indicates if the proxies listed in "internal_proxy" would both be used or just the first one. The load balancing is based on the URL, specifically, the domain name in the URL. Based on the domain name, the algorithm will determine if client will receive proxy1/proxy2 versus proxy2/proxy1. The benfits of this approach is that all cnn.com sites will use the same primary proxy.

Testing a PAC File

Besides putting the PAC file on a server and executing it in a browser, Google has a pactester program.  The pactester program is available for several platforms, including Windows.  The pactester program has a lot of configuration options, but lets you specify a PAC file and a url and will output what your PAC file would tell a browser.  If there is a problem with the PAC file, the pactester program will spit out an error and at which line in the PAC file.  I have found this tool to be very helpful in testing my PAC files, expecially when I went and developed the load balanced PAC file.

The Files

My sample PAC files are attached to this blog entry below.  sample.zip contains sample.pac and sample-loadbalance.zip contains sample-loadbalance.pac.