If you would like to read the first part in this article series please go to Optimizing Performance on the Forefront Threat Management Gateway (Part 1).
Introduction
The Forefront Threat Management Gateway (TMG) 2010 firewall is an integrated edge security gateway that provides advanced network and application layer protection services. Capable of performing low-level protocol inspection, deep application layer traffic inspection, authenticating users, providing reputation-based access control, and inspecting HTTPS communication. These advanced features consume valuable system resources (CPU, memory, disk and network I/O) that can potentially impede throughput and introduce delay if the system is configured incorrectly or improperly sized. In last month’s article we focused mainly on infrastructure services and networking configuration. In this article we’ll discuss some additional areas where performance can be improved.
Firewall Policy
In many cases, simply following firewall policy configuration best practices can result in significant improvements in performance. For example, it is a good idea to place access rules that include simple elements at the beginning of the firewall policy. Simple elements are anything that can be evaluated quickly by the firewall, such as protocols, source port, schedule, or any IP address-based object (computers, computer sets, subnets, networks, and network sets).
By contrast, rules that include complex elements should be placed at the end of the firewall policy. Complex rule elements are anything that takes an additional or indeterminate amount of time for the firewall to evaluate, such as Domain Name Sets, URL Sets, or any rule that requires authentication or applies to specific content types.
In general, access rules should be configured in the following order:
- Global deny rules
- Global allow rules
- Rules for specific computers
- Rules for specific users, destinations (Domain Name Sets or URL Sets), or MIME types
- Publishing rules
- All other allow rules
Here are some firewall policy best practices that will ensure optimum performance on the TMG firewall:
- Place rules that do not require authentication before any rules that apply to specific users and/or groups. Authenticating users takes additional time and consumes more system resources, so having anonymous access rules at the top of the firewall policy avoids authenticating requests needlessly and reduces processing overhead.
- Use IP addresses whenever possible. IP addresses can be evaluated quickly by the TMG firewall without having to perform name resolution. Additionally this reduces load on DNS servers.
- Use Fully Qualified Domain Names (FQDNs) in Domain Name Sets and URL Sets.
- Avoid using RADIUS for authentication. RADIUS authentication is much slower than using Integrated authentication. Integrated authentication leverages native Active Directory authentication protocols such as NTLM and Kerberos, which are more secure and higher performing.
- Avoid using deny rules that include ‘all outbound traffic’ and use a Domain Name Set for the destination. When an access rule is configured in this manner, the TMG firewall will be forced to perform a reverse DNS lookup for every single request that it receives in order to determine if the destination IP address is included in the Domain Name Set. This will severely degrade performance and likely overwhelm the DNS server.
Authentication
Enforcing user and group-based authentication on web proxy traffic is an excellent idea. The process of authenticating users can be expensive in terms of system resource usage, however. By default, the TMG firewall will use NTLM to authenticate users. With NTLM, the TMG firewall establishes a secure channel to a single domain controller in the Active Directory site to which it belongs. Each request that the TMG firewall must authenticate will be processed via this single secure channel. In a scenario where the TMG firewall is extremely busy, this single connection can quickly become a bottleneck, resulting in serious delays retrieving web pages and authentication prompts for previously authenticated users.
Using Kerberos authentication solves this problem. With Kerberos, the authentication process is handled by the client instead of the TMG firewall. When the client makes a request for which authentication is required, the client will contact a domain controller and obtain a Kerberos ticket to present to the TMG firewall to obtain access (complete details regarding Kerberos authentication can be found here). Kerberos authentication is available only to Web Proxy clients, and those clients must be using Internet Explorer 7 or later. If the web browser is configured to use Web Proxy Auto Discovery (WPAD) or the autoconfiguration script, the TMG firewall must be configured to provide the FQDN of the proxy server in the autoconfiguration script as described here. If the web browser is configured manually, the proxy server must be specified using an FQDN, not an IP address.
Logging
By default, TMG logs all requests to a local instance of SQL Express that is installed with the TMG firewall software. The logging infrastructure is much more robust in TMG than in previous versions of the product, making logging performance less of an issue that it has been in the past. [See my article Logging Enhancements in Forefront Threat Management Gateway (TMG) 2010 for more details.] There are, however, a few best practices to follow to ensure optimum logging performance.
The logging database files should be located on a separate partition; ideally on a partition other than the system partition. Preferably this partition should be on a separate physical disk.By default, TMG stores the log database files on the system partition. To relocate the log database files to another partition, open the TMG management console and highlight the Logs & Reports node in the navigation tree, then click Configure Firewall Logging in the Tasks pane. Click the Options… button next to SQL Server Express Database (on local server), then select This folder (enter the full path): and enter the new drive and path to store the log database files. For enterprise arrays this folder must exist on all array members.Once complete, repeat the process by clicking Configure Web Proxy Logging.
Figure 1
If the TMG firewall is extremely busy, it may be necessary to switch to text file logging. One drawback to using text file logging is that viewing historical log data in the TMG management console is no longer available. However, in terms of performance this is the best option as text file logging consumes the least amount of system resources. To configure text file logging, follow the steps above and select the File option. Clicking the Options… button will allow you to specify where the log files are stored.
Figure 2
Caching
The TMG firewall has the ability to cache frequently requested web objects and store them in memory and on disk. Subsequent requests for these objects are then retrieved from the cache and delivered to the client at LAN speeds, without requiring a trip to the origin server to retrieve the content. Caching is certainly less effective that it was five to ten years ago when most web content was static, but enabling caching can still yield 10 to 20 percent cache hit ratios in most environments today. Having up to 20 percent of your web traffic being served from cache is a quick and easy way to reduce WAN utilization and improve performance for end users.
To enable caching, highlight the Web Access Policy node in the navigation tree, and then click Configure Web Caching in the Tasks pane. Select the Cache Drives tab, highlight an array member, then click Configure…. Highlight a disk drive to store the cache, enter a value in the Maximum cache size (MG): and click Set.
Figure 3
HTTP Compression
HTTP compression support in TMG enables the firewall to request and deliver web content in a compressed form using GZip. Enabling HTTP compression consumes additional CPU, but it can significantly improve network throughput when the TMG firewall is connected to a slow WAN link.
To enable HTTP compression, highlight the Web Access Policy node in the navigation tree, and then click Configure HTTP Compression in the Tasks pane. On the General tab check the option to Enable HTTP compression, then select the Request Compressed Data tab and add a network from which to request compressed HTTP content.
Figure 4
Summary
There are myriad factors that affect the overall stability and performance of the TMG firewall. In this article we looked at the effects of firewall policy configuration and authentication on system performance. Optimizing firewall policy by placing simple rules before complex rules and configuring clients to use Kerberos authentication will yield significant improvements in performance. By making changes to the default logging options and enabling content caching and HTTP compression (where applicable) we can ensure that the TMG firewall will be performing at its peak.
If you would like to read the first part in this article series please go to Optimizing Performance on the Forefront Threat Management Gateway (Part 1).
