The ISA Firewall’s Web Proxy Feature

I don’t spend a lot of time discussing the ISA Firewall’s Web proxy feature set because I spend most of my time writing about the ISA Firewall’s firewall capabilities so as to disabuse the pot-head network guys who think that the ISA Firewall is a “proxy server”, as if they even understood what a proxy server was. So, in spit of my jihad against the hardware firewall infidels, I think I should give some time to some of the Web proxy features that are useful but don’t get discussed much.

For example, did you know that you could configure the ISA firewall to use a backup route if the primary connection attempt fails? You can configure the ISA firewall to use a upstream Web proxy server if its currently using a direct connection to reach Web sites, or if the ISA firewall is already using an upstream Web proxy server, you can configure it to use another Web proxy server, or use a direct connection (via its default gateway).

Something I noticed a few years ago is that if you configured the clients to be Web proxy clients using the autoconfiguration script, you could have them automatically use their default gateway configuration if the Web proxy went down but configuring the Web proxy settings on the ISA firewall. I haven’t tried this for a few years but I’m sure it still works in ISA 2004 and ISA 2006.

Another thing you can do is Web proxy chaining. This a neat setup where you set up a chain of ISA firewalls, all of which perform Web caching. The goal is to have each downstream ISA firewall member in the chain be able to leverage the cache of the ISA firewalls upstream in the chain.

For example, suppose you have the following:

  • 100 small branch offices with 1.5Mbps site to site VPN links to 10 regional offices
  • 10 regional offices with 15Mbps site to site VPN links to the central office
  • 1 central office with a 50Mbps link to the Internet

All Internet connections for all offices are made through the central office Internet connection. All Web sites accessed by the central office users are cached on the main office ISA firewall array.

Connections made from the regional offices are also made through the regional office ISA firewalls. If the content requested is already in cache, its served from the regional office ISA Web cache. If the content isn’t cached at the regional office ISA firewall, then the connection request is sent to the central office ISA firewall array. If the content is cached on the central office ISA firewall array, then its returned from the central office ISA firewall array cache to the regional office ISA firewall, which puts it in its cache, and then returns the content to the user. If the content is not cached on the central office array, then the central office array retrieves the web content, put its in it’s cache, and then returns it to the regional office, which then put it in it’s cache and then returns to the content to the user who requested the information.

As you can see, from the above, the cache content can get very large at the main office array, since both users at the central office and the regional offices is cached on the central office array. The regional offices benefit from this cache, which is larger than the caches at any of the regional offices, and they access the cached content fast than if they had to go directly to the Internet.

The same applies to the branch offices. Requests for Web content go first to the branch office ISA firewall. If the content is in the branch office ISA firewall cache, then its returned from the branch office ISA firewall cache to the client. However, if the content is not contained on the branch office ISA firewall cache, the request is sent to the regional office ISA firewall. If the content is contained in the regional office cache, then it’s returned to the branch office firewall, where it is cached and returned to the client.

If the content is not contained on the regional office cache, then the request is forwarded to the central office ISA firewall array. If the content is contained in the central office cache, it is returned to the regional office ISA Firewall and is cached there, and then returned to the branch office ISA Firewall, which then caches it and returns the content to the client. If the content is not contained in the central office array, the central office array will retrieve the content, put it in its cached, return it to the regional office ISA Firewall, which will put it in its cache, and then regional office ISA Firewall returns the content to the branch office ISA Firewall, which then caches the content and returns it to the client making the request.

The end result of this Web proxy chained configuration is that the total amount of bandwidth required on the central office Internet connections. In addition, the clients at end point benefit from cached content from requests made by other clients on the network by bringing cached content closer to them.

I’ll do an article in the near future on how to create Web proxy chaining arrays to show you how all these Web proxy stuff works.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: [email protected]

MVP — Microsoft Firewalls (ISA)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top