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 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.
ISPs 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 4.59 shows an example of a Web Proxy chain and the flow of information through the chain.

Figure 4.59: WebProxyChaining.vsd
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.
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 the simple hardware packet filter firewall in front of the unihomed ISA firewall.
The unihomed Web caching-only ISA firewall forwards the connection request through the simple hardware packet filter-based router.
The Internet Web server returns the response to the unihomed ISA firewall through the simple hardware packet filter-based firewall.
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.
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.
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.
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.
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.
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, but 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.. Figure 4.60 shows how a Web-caching array could be set up for an organization.

Figure 4.60: A Web-cached Array Configured for an Organization
In this example, the downstream ISA firewalls are 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 the 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:
In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and then expand the Configuration node. Click the Networks node.
In the Networks node, click the Web Chaining tab in the Details pane.
Click the Tasks tab in the Task pane, and click Create New Web Chaining Rule.
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.
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.
In the Add Network Entities dialog box, click the Networks folder, and then double-click the External network. Click Close.
Click Next on the Web Chaining Rule Destination page.
On the Request Action page (Figure 4.61), inform the ISA firewall how requests for the destination you configured on the last page should be routed. You have the following options:

Figure 4.61: Configuring the Request Action
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? 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 while accessing internal Web sites, but we can't commit to that answer. We'll keep you updated when we find out what this option means.
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 an also specify the HTTP Port and the SSL Port.
Use automatic dialup 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 4.61 shows Configuring the Request Action.
In this example, we'll use Redirect requests to a specified upstream server and disable the Allow delegation of basic authentication credentials. Click Next.
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. The SSL Port is used when you want to secure the Web Proxy chain link between the upstream and downstream ISA firewall using SSL. We don't have space in this book to include the details of this type of configuration, but we'll include it in an upcoming article on www.isaserver.org, so be on the lookout for it.
Figure 4.62 shows how to route to the upstream Web Proxy.

Figure 4.62: Routing to the Upstream Web Proxy
I highly recommend that you require authentication on the upstream Web Proxy. When authentication is forced on 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 4.63), 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 4.63 shows setting the credentials.

Figure 4.63: Setting Credentials
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 was 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)
Select the Ignore requests option, and click Next on the Backup Action page.
Click Finish on the Completing the New Web Chaining Rule Wizard page.
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.
Tip | 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. |