Configuring Web Proxy Chaining with Forefront Threat Management Gateway (TMG) 2010 (Part 2)

If you would like to read the first part in this article series please go to Configuring Web Proxy Chaining with Forefront Threat Management Gateway (TMG) 2010 (Part 1).


In last month’s article, I demonstrated how to configure web proxy chaining with Forefront Threat Management Gateway (TMG) 2010 in a basic deployment scenario. In this second installment of a two-part series we’ll look at a more complex chaining scenario where authentication and conditional forwarding are required.

Access Control

Before we continue, it is important to understand that controlling access on the upstream proxy servers is critical to the overall security of your proxy solution. If access controls are in place on the downstream proxy servers, but the upstream proxy servers are open, users will eventually discover this and connect directly to the upstream proxy server. This effectively allows them to circumvent any access polices in place on the downstream proxy servers. Access rules on the upstream proxy server should restrict access only to the IP addresses of the downstream proxy servers. In some instances, for example when the upstream proxy server also handles direct requests from local clients, it may be necessary to require the downstream proxy server to authenticate.


If the upstream proxy server requires authentication, either because an access rule allowing the traffic requires authentication, or because the web proxy listener is configured to authenticate all users, it will be necessary to configure the downstream proxy server to provide authentication credentials to the upstream proxy server. To accomplish this, open the TMG management console, highlight the Networking node in the navigation tree and select the Web Chaining tab in the main console. Double-click on the web chaining rule, select the Action tab, then click the Settings… button.

Figure 1

Select the option Use this account: and specify a user account with permission to access the Internet on the upstream proxy server. The user account used for authentication can be a domain account or a mirrored local account (the account must be a user account; it cannot be the machine account of the downstream proxy). Select the appropriate authentication method to use when authenticating to the upstream proxy server.

Figure 2

It is recommended that Integrated Windows authentication be used. If you must use Basic Authentication, it is highly recommended that you configure SSL on the upstream web proxy listener. To do this, open the TMG management console on the upstream proxy, highlight the Web Access Policy node in the console tree, then right-click and choose Configure (Related) then Web Proxy…

Figure 3

Select the option to Enable SSL, then click the Server Certificates… button.

Figure 4

Select a firewall from the list, then click the Select… button.

Figure 5

Highlight the machine certificate you wish to use, and then click the Select button. [Note: This step assumes that a machine certificate has already been installed on the system.]

Figure 6

On the downstream proxy, highlight the web chaining rule in the main window and then click Define SSL Bridging for Selected Rule in the tasks pane.

Figure 7

Select the options to Redirect HTTP Requests as SSL requests (establish a secure channel to the site) and Redirect SSL Requests as SSL requests (establish a new secure channel to the site).

Figure 8

Conditional Forwarding

By creating additional web chaining rules we can implement conditional forwarding based on the destination of the request. This may be desirable in some cases where only a portion of the traffic should be routed to the upstream proxy server. An example of this might be a scenario in which there is a main office in the U.S. and a remote office located in the U.K. that has a local Internet connection. In this case we can create a more specific web chaining rule that routes requests for the * domain directly, instead of routing those request to the upstream proxy servers located in the main office. To accomplish this, create a new web chaining rule as you did previously, this time creating a domain name set that includes * and specify that as the destination for the new web chaining rule. For the Request Action select the option to Retrieve requests directly from the specified destination.

Figure 9

Web chaining rules are processed in order, so be sure to place more specific rules ahead of less specific ones. Here we have placed the rule to route requests for * locally (retrieve request directly using the local Internet connection) before the more generic rule that will route requests destined for the External network to the main office proxy servers. If the order is reversed, requests for domains ending in will be processed by the first rule that matches the request, resulting in our requests being forwarded to the upstream proxy servers instead of using the local Internet connection as we intended.

Figure 10

Name Resolution

The TMG firewall is responsible for providing hostname resolution for web proxy requests that it receives. In chaining scenarios where the downstream proxy server is configured to use a local DNS server that perhaps forwards requests over a slow WAN link to another DNS server, or in cases where local DNS servers cannot resolve public hostnames, it may be necessary to configure the downstream proxy server to skip name resolution. Refer to this KB article for information on how to implement this change. If you intend to perform URL filtering on the downstream proxy server, those servers must be able to resolve public hostnames.


Web proxy chaining can be a powerful tool for managing web proxy traffic in your environment. Using web proxy chaining we can control web traffic more efficiently by placing downstream proxy servers closer to users in remote locations, and then forwarding those requests to a central upstream proxy server. Downstream proxy servers can be configured to authenticate to upstream proxy servers, and multiple web proxy chaining rules can be configured to intelligently route traffic based on the destination, taking advantage of local Internet connections when available. With caching enabled on the downstream proxy servers, bandwidth utilization on WAN links is reduced and response times are improved, resulting in overall improved end-user experience.

If you would like to read the first part in this article series please go to Configuring Web Proxy Chaining with Forefront Threat Management Gateway (TMG) 2010 (Part 1).

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