Web Proxy Chaining as a Form of Network Routing

Web Proxy Chaining is a method you can use to forward Web Proxy connections from one ISA firewall to another ISA firewall. Web Proxy chains consist of upstream and downstream ISA firewalls. The upstream ISA firewalls are those closer to the Internet connection and the downstream ISA firewalls are those further away from the Internet connection. Downstream ISA firewalls forward Web Proxy requests to upstream ISA firewalls. The first ISA firewall in the Web Proxy chain is the one closest to the Internet and is the one responsible for obtaining the Internet content.

Web Proxy Chaining is useful in a number of scenarios:

• Branch office ISA firewalls can be chained to upstream ISA firewalls at the corporate office
  
• Departmental ISA firewalls, which protect department specific networks within the organization can be chained to upstream ISA firewalls located on a network services segment or upstream ISA firewalls that are directly connected to the Internet
  
• ISP’s or large corporate customers can chain downstream ISA firewall Web caching arrays with upstream ISA firewall or ISA firewall Web caching array

The advantage of using Web Proxy chaining is that you can reduce the overall bandwidth utilization on both the Internet link and all links between the downstream and upstream ISA firewalls in the Web Proxy chain. Figure 1 shows an example of a Web Proxy chain and the flow of information through the chain.

Figure 1

1. A client on a protected Network behind an ISA firewall makes a request for a Web page located on an Internet Web server. The connection request is sent through the ISA firewall protecting the departmental LAN.
   
2. The ISA firewall forwards the connection request to a unihomed ISA firewall located on the corporate backbone. The departmental ISA firewall is configured to use Web Proxy chaining to connect to the unihomed ISA firewall. Since the unihomed ISA firewall is able to protect itself from attack, there is little concern regarding attacks originating from hosts on the backbone network, or hosts located in from the simple hardware packet filter firewall in front of the unihomed ISA firewall.
   
3. The unihomed Web caching only ISA firewall forwards the connection request through the simple hardware packet filter based router.
   
4. The Internet Web server returns the response to the unihomed ISA firewall through the simple hardware packet filter based firewall.
   
5. The unihomed ISA firewall forwards the response to the departmental ISA firewall. However, before forwarding the response to the departmental ISA firewall, the unihomed ISA firewall places the Web content in its cache. The Web content in the response is returned to the departmental ISA firewall from the unihomed ISA firewall’s Web cache.
   
6. The departmental ISA firewall returns the response to the client that issued the request. However, before the departmental ISA firewall returns the content, it places the content in its Web cache. It is from this Web cache that the departmental ISA firewall obtains the content to return to the protected host that issued the request.
   
7. A host on another network makes a request for the same Web page. This host is also protected by an ISA firewall. The host makes a request for the Web page by going through its ISA firewall.
   
8. The ISA firewall is Web chained to the unihomed ISA firewall on the corporate backbone. It forwards the connection request to the unihomed ISA firewall. The unihomed ISA firewall checks to see if the content is contained in its Web cache before forwarding the request to the Internet Web server.
   
9. The unihomed ISA firewall has the requested content in its Web cache and returns the content to the departmental ISA firewall that forwarded the request. The unihomed ISA firewall did not need to send the request to the Internet Web server because that information was already contained in its Web cache.
   
10. The departmental ISA firewall forwards the Web content to the host that initiated the request.

You can see in this example that not only is bandwidth saved on the Internet link, bandwidth can also be saved on the backbone link. You would see this bandwidth savings when another host on either of the ISA firewall protected networks makes a request for the same Web content. In this case, the departmental ISA firewalls will have the information already in their local Web caches and they will not need to forward the request to the unihomed ISA firewall on the corporate backbone. This reduces overall bandwidth utilization on the corporate backbone.

Another powerful application of Web chaining is when you configure the downstream ISA firewalls to connect to a Web caching array. Web caching arrays are available with the Enterprise Edition of the ISA firewall. Figure 2 shows how a Web caching arrays could be set up for an organization.

Figure 2

In this example the downstream ISA firewalls can be configured in a Web chaining configuration with the array. The Web caching array provides configuration information to the downstream ISA firewalls, including the names of the machines participating in the array. If one of the array members goes offline for some reason, the downstream ISA firewalls will try another array member that is online.

In addition, when an array member goes offline, the array is aware that the array member is unavailable and removes the offline machine from the array. The remaining array members inform the downstream departmental ISA firewalls of the machines in the array that are online. This prevents downstream ISA firewalls from attempting connections with an offline array member.

Configuration of Web Proxy chaining is done on the Web Chaining tab in the Network node. Perform the following steps to configure Web Proxy chaining:

1. In the ISA Firewall console, expand the server name and then expand the Configuration node. Click the Networks node.
   
2. In the Networks node, click the Web Chaining tab in the Details pane.
   
3. Click the Tasks tab in the Task Pane and click Create New Web Chaining Rule.
   
4. On the Welcome to the New Web Chaining Rule Wizard page, enter a name for the rule in the Web chaining rule name text box. In this example, we’ll name the rule Chain to ISA-1. Click Next.
   
5. On the Web Chaining Rule Destination page you tell the ISA firewall what requests should be chained to the upstream firewall. You can choose to chain all requests to the upstream firewall, or you can chain requests for specific URLs to the upstream ISA firewall. In this example, we’ll chain all requests to the upstream firewall. Click the Add button to add the sites.
   
6. In the Add Network Entities dialog box, click the Networks folder and then double click the External network. Click Close.
   
7. Click Next on the Web Chaining Rule Destination page.
   
8. On the Request Action page (Figure 3) you inform the ISA firewall how requests for the destination you configured on the last page should be routed. You have the following options:
   
   Retrieve requests directly from the specified location This option configures the ISA firewall to send requests for the destination specified on the last page directly to the specified server and not send them to an upstream ISA firewall. What this means is if the ISA firewall is configured to connect to the Internet in some way other than via a Web Proxy chain, the ISA firewall will forward the connection via that link. If the ISA firewall does not have access to the Internet other than from a Web Proxy chain, then the connection will fail. This configuration option actually represents the default behavior of the ISA firewall, which is to not use Web Proxy chaining but instead to send the connection to the Internet site being requested.
   
   Redirect requests to a specified upstream server  This option forwards the request to an upstream Web Proxy server. This is the option that creates the Web Proxy chain between this server and the upstream ISA firewall. The Allow delegation of basic authentication credentials option is a bit of a mystery. What credentials? For what destinations? Who are we authenticating against? Are we authenticating with a Web site? An upstream Web Proxy? The downstream ISA Firewall? All of the above? None of the above? At this time we cannot definitively state what this option is for. It’s possible that this option is used when Web Proxy chaining is implemented when accessing internal Web sites, but I can’t commit to that answer.
   
   I’ve not used this option, but if I had to make a best guess, I would say that when you use basic authentication on the downstream ISA Firewall, basic credentials will be forwarded to the upstream ISA Firewall. Therefore, if you use transparent integrated authentication with the downstream ISA Firewall, no credentials will be forwarded to upstream ISA Firewall.
   
   Redirect requests to This option allows you to redirect requests for the site specified on the previous page to another Web site. For example, suppose you want to redirect requests for a list of forbidden Web sites to a specific site on your corporate network. You would select this option and then enter the IP address or FQDN for your internal site. You can also specify the HTTP Port and the SSL Port.
   
   Use automatic dial-up The Use automatic dial-up option allows you to use a dial-up connection for this rule. If your external interface is a dial-up connection, then select this option if you want to use the dial-up connection to reach the destination you specified on the previous page. You can also use this option if you have a NIC and a dial-up connection on the same ISA firewall. The NIC can be used for regular Internet connection and the dial-up connection can be used for chained connections.

Figure 3

9. In this example we’ll use the Redirect requests to a specified upstream server option and disable the Allow delegation of basic authentication credentials option. Click Next.
   
10. On the Primary Routing page, enter the IP address or FQDN of the upstream ISA firewall. If you enter the FQDN, make sure that the downstream ISA firewall can resolve that name to the correct IP address on the upstream. The Port and SSL Port text boxes contain defaults that work with all other ISA firewalls. Note that the SSL port is not used for SSL connections from clients behind the downstream ISA firewall in the Web Proxy chain. SSL connections from clients behind the downstream ISA firewall are tunneled in the Web Proxy connection to the upstream ISA firewall’s TCP port 8080 when you’re not forcing SSL between the downstream and upstream ISA Firewalls.
    
    The SSL Port is used when you want to secure the Web Proxy chain link between the upstream and downstream ISA firewall using SSL. In order to do this, you would need to make sure that the CA certificate is installed on both the upstream and downstream ISA Firewalls and that you have a machine certificate installed on the upstream ISA Firewall and that you specify the common/subject name on the certificate in the Server text box on this page and that the common/subject name resolves to the IP address of the upstream ISA Firewall.

Figure 4

I highly recommend that you require authentication on the upstream Web Proxy. When authentication is forced at the upstream Web Proxy, the downstream Web Proxy must be able to send credentials to the upstream to access the Internet.

You can configure credentials for the downstream Web Proxy in the Web Proxy chain by putting a checkmark in the Use this account checkbox. Click the Set Account button. In the Set Account dialog box (Figure 5), enter the user name in the User text box in the COMPUTERNAME\Username format. The user account is configured in the local user database of the upstream ISA firewall. If the upstream ISA firewall is a member of a domain, then you can use the DOMAINNAME\Username format.

Enter the password and confirm the password in the Password and Confirm password text boxes. Click OK in the Set Account dialog box. In the Authentication drop down list, select the Integrated Windows option. If you are configuring Web Proxy chaining to a non-ISA firewall Web Proxy server, then you will have to use basic authentication. If you use basic authentication, make sure that the Web Proxy chain link is configured to use SSL, because the basic credentials are sent in clear text. Click Next on the Primary Routing page.

Figure 5

11. On the Backup Action page, you have the following options:
    
    Ignore requests If the upstream Web Proxy in the Web Proxy chain is not available, this option will drop the request and the client will receive an error indicating that the site is not available.
    
    Retrieve requests directly from the specified location This option allows the downstream ISA firewall in the Web Proxy chain to use another method, outside the Web Proxy chain configuration, to connect to the Web site. This would be the case if the external interface of the ISA firewall is able to reach the destination site without going through the Web Proxy chain.
    
    Route requests to an upstream server This option allows the downstream ISA firewall in the Web Proxy chain to use another ISA firewall in a second Web Proxy chain. This option allows you to set a second Web Proxy chain configuration on the downstream ISA firewall, which is used only when the first upstream ISA firewall becomes unavailable.
    
    Use automatic dial-up This option should be enabled if a dial-up connection is used to connect the downstream ISA firewall to the Internet, or if you want requests for the destinations configured for this rule to use a dial-up connection instead of the ISA firewalls primary connection (which would be a dedicated NIC)
    
12. Select the Ignore requests option and click Next on the Backup Action page.
    
13. Click Finish on the Completing the New Web Chaining Rule Wizard page.
    
14. The downstream ISA firewall is now configured in a Web Proxy chaining relationship with the upstream. Remember to configure an Access Rule on the upstream ISA firewall that allows the account you configured in the Web Chaining Rule access to the Internet using the HTTP, HTTPS and FTP protocols.

When you configure Web Proxy chaining, the downstream ISA firewall can be configured with a user account it can use if the credentials the client used to authenticate with the downstream ISA firewall are not recognized by the upstream firewall. This is what we did in the scenario we configured above.

In this scenario, the logged on user name on the upstream ISA firewall will be the name you used to authenticate in the Web Proxy Chaining Rule. 

However, if the upstream ISA firewall can authenticate the user that issued the initial connection, because the upstream firewall belongs to the same domain as the client and downstream ISA firewall, or if the upstream ISA firewall has that user name located in its local SAM, then the user that issued the request will appear in both the downstream and upstream ISA firewall logs.

Summary

In this article we spent some time going over the basics of Web proxy chaining. In a future article I’ll build on the information and show you how to implement Web proxy chaining in a site to site VPN environment, where the downstream ISA Firewall is Web proxy chained to the upstream ISA Firewall, with the goal being to reduce the amount of bandwidth required on the site to site VPN link.