If you would like to read the other parts in this article series please go to:
- Forefront Threat Management Gateway (TMG) 2010 Web Proxy Client Redundancy Deep Dive (Part 1) - DNS Configuration
- Forefront Threat Management Gateway (TMG) 2010 Web Proxy Client Redundancy Deep Dive (Part 3) - Enable Kerberos Authentication in Load Balanced Scenarios
Forefront TMG 2010 Enterprise edition allows an administrator to configure clustered arrays of TMG firewalls to provide redundancy, high availability, and scalability. In a forward (outbound) web proxy scenario there are several options to configure redundancy for the web proxy array, and choices to make when configuring web proxy clients. In part one of this series on web proxy client redundancy we covered the DNS configuration options in detail. The manner in which web proxy clients are configured has a dramatic effect on the performance of the web proxy. In part two of this three-part series I’ll review the different explicit proxy client configuration options and examine how they potentially impact performance.
Automatically Detect Settings
Using Microsoft Internet Explorer as an example, navigate to Tools / Internet Options / Connections and click the LAN Settings button. Here you can choose one of two automatic configuration options - Automatically detect settings or Use automatic configuration script. In addition you have the option to explicitly define a web proxy server to send requests to. Internet Explorer, and most third-party web browsers, automatically detects settings by default, as shown here:
In this default configuration, when a request is made the client will query DNS in an attempt to resolve the hostname WPAD to an IP address. If successful, the client will connect to this IP address and retrieve the proxy automatic configuration script from the TMG firewall.
Once the client has successfully retrieved the script it will be parsed and the request delivered directly to one of the array members identified in the function MakeProxies() section of the script.
Note that the automatic configuration script returns the IP address and not the hostname or Fully Qualified Domain Name (FQDN) of the individual array members. If authentication is required, either by the access rule or by the web proxy listener, an interesting thing happens. When the web proxy client sends its request to an array member, the request will be authenticated by the TMG firewall using NTLM, not Kerberos. Since Kerberos authentication is more secure and robust than NTLM, it would be ideal if we could take advantage of this. In order to leverage Kerberos authentication the client must be configured to use the Fully Qualified Domain Name (FQDN) of the array member. To support this, TMG must be configured to return FQDNs of each array member in the automatic configuration script instead of IP addresses. This change can be made using a script that can be found here. Once this change has been made, the automatic configuration script will now return the FQDN for each array member, like this:
Use Automatic Configuration Script
Selecting the option to Use automatic configuration script will instruct the client to retrieve the script directly from the server you specify. From there it functions in exactly the same way as using Automatically detect settings.
You can specify the path to the script in either of the following formats:
http://<hostname, IP, or FQDN of proxy array>:<port>/array.dll?Get.Routing.Script
http://<hostname, IP, or FQDN or proxy array>:<port>/wpad.dat
Please note that Get.Routing.Script is case sensitive. However, the rest of the URL is not. Also, the <port> is the TCP port that the web proxy listener is configured to use, which by default is 8080. In my example here it will look like this:
Using either an IP address or FQDN is acceptable here because we’re only connecting to the proxy to retrieve the configuration script. Since we’ve configured TMG to return FQDNs in the script file, the client will parse the script, attempt a connection to an array member by FQDN, and use Kerberos authentication as desired.
Use Proxy Server
The web proxy client can also be configured to use a specific proxy server. Here we’ll configure Internet Explorer to use the proxy array name proxy.richardhicks.net and specify the port used by the web proxy listener.
Using DNS RR, the client will resolve proxy.richardhicks.net and receive multiple IP addresses in return. The client will choose one and send its request to that individual array member. If the proxy array name resolves to the NLB VIP, only that IP address will be returned by DNS and the client will send its request to the VIP. In either scenario, Kerberos authentication fails because the Service Principal Name (SPN) http/proxy.richardhicks.net is not registered in the Kerberos database. The client will fall back to NTLM for authentication, which is less than desirable.
The way to resolve this issue and have the client use Kerberos authentication is to configure the TMG firewall service to run in the context of a domain user and register that SPN in the Kerberos database. TMG Service Pack 2 (SP2) is required to enable this functionality. For more information, please read part three of this three-part series Forefront TMG 2010 Web Proxy Client Redundancy Deep Dive.
Firewall Client Considerations
When creating a load balanced TMG firewall array, TMG firewall clients must also be considered. The TMG firewall client makes use of a control channel and must be configured to communicate with the dedicated IP (DIP) address of the TMG firewall. Using WPAD with DNS RR or NLB VIP is acceptable, because in either of these scenarios the TMG firewall client resolves WPAD in order to obtain the automatic configuration script. The script provides the IP addresses (or hostnames) of individual TMG array members for the TMG firewall client to connect to. Manually configuring the TMG firewall client to connect to the VIP, or a hostname that resolves to the VIP is not supported.
Additional Client Considerations
When planning for web proxy client redundancy, be advised that the automatic configuration script returned by TMG is cached for 50 minutes by default. This could have an impact on the user experience in the event an array member is unavailable. Additionally, Internet Explorer includes a bad proxy list that expires after 30 minutes (or when browser is closed), further complicating matters.
Cache Array Routing Protocol (CARP)
There’s a lot of confusion surrounding Cache Array Routing Protocol (CARP) and its effect on load balancing. To be clear, CARP is NOT a high availability solution at all and provides no redundancy whatsoever. CARP is designed to make content caching more efficient in enterprise array scenarios by allowing multiple cache files that are distributed across the individual array members to be addressed as a single logical content cache. One of the benefits provided by CARP is the elimination of duplicate cached content existing on multiple array members. CARP can be implemented on the client side and/or the server side. Client-side CARP is most efficient as the client, using information provided by the automatic configuration script, selects the individual array member that most likely contains the requested web content in its local cache file and forward its request directly to this node. Client-side CARP is leveraged when web proxy clients are configured to use WPAD or configured to retrieve the automatic configuration script directly from the array. For web proxy clients configured to use a proxy server directly (as opposed to using automatic detection or retrieving the configuration script directly), the array member that receives the request will, instead of forwarding the request immediately to the Internet, perform CARP itself to determine which array member might already have this content in its cache. This consumes more processing power and generates additional intra-array network traffic, ultimately resulting in decreased performance. As you can see, server-side CARP is much less efficient than client-side CARP. Server-side CARP also suffers from negative scalability, as the busier the array becomes the more array processing resources are consumed by server-side CARP. Often the additional overhead of server-side CARP negates any potential gains that it might otherwise provide.
Web proxy and firewall client configuration have a direct impact on the operation and performance of the TMG web proxy array. When choosing between direct proxy configuration, automatic detection, and using the automatic configuration script, careful consideration must be made with regard to how the clients resolve hostnames to IP addresses and the potential impact this has on the authentication process. Additional consideration must be made if you have deployed the TMG firewall client or if you have enabled CARP on the array. Be sure to read the final part of this series where I’ll describe in detail how to configure TMG enterprise arrays to leverage Kerberos authentication in load balanced scenarios.
If you would like to read the other parts in this article series please go to: