I spent some time yesterday chaining two ISA Server 2000 proxy arrays. As there doesn’t seem to be a lot of information about on the subject, I thought I’d provide some here (most of what can be found easily is about using proxy chaining for anonymity, and mostly reads as if it’s intended for nefarious purposes).

Both Microsoft Proxy Server and Microsoft Internet Security and Acceleration (ISA) Server can be configured in a chain to distribute the web cache, forming hierarchical configurations with other proxy servers. One example of where this might be useful is for networks with geographically separated segments, such as branch offices. The proxy chain allows servers to query an upstream server’s cache before accessing resources on the Internet. Using this type of configuration, the clients in the branch office benefit from a local cache as well as the cache at the main office.

Proxy chaining is also known as proxy cascading or hierarchical caching and it is primarily used to improve cache performance and balance the caching load by placing information closer to proxy clients (note that only client requests for the web proxy service can be routed upstream because only the web proxy service uses caching).

My client’s scenario was slightly different. They have two proxy arrays – one for the Americas and another for Europe, the Middle East and Africa (EMEA) but they also need to access resources in their parent company using that company’s proxy server (accessed across the private network). Using this configuration, any requests that are not cached in the local proxy will require Internet access, unless the domain name matches the internal domain name for the parent company in which case they need to be forwarded to the parent company’s proxy servers.

This is fairly straightforward to configure but it is important to check first that the proxy server(s) can perform a DNS lookup for the upstream proxy server(s) and access the appropriate network. When I originally configured the proxy array, I had secured the network interfaces and added a static route to the organisation’s internal network using the route -p add networkaddress mask subnetmask gatewayaddress command but I also had to add a route to the parent company’s network, otherwise all requests that didn’t match the internal network were routed via the external (Internet-facing) default gateway. Once I could both resolve the upstream proxy server names in DNS and ping them I was ready to configure the routes in ISA Server.

I already had a destination set for the internal domain, based on the IP address range for the internal network (10.0.0.0-10.255.255.255), so I added another one for the parent company’s internal DNS domain name (*.companyname.countrycode). Once this was complete, I could establish a new routing rule in the ISA Server network configuration. Leaving the default rule in place as the last to be applied (routing all destinations directly to the specified destination), I added another rule with a higher rank order which applied to my new destination set and routed them to a specified upstream server (i.e. the parent company’s proxy server), with no caching in this case. Verifying the configuration was as simple as accessing the sites from a browser and reviewing the access logs, where access requests for the parent company’s internal sites were shown with an s-object-source of “upstream”.