The following rule elements require simple networking information and therefore are evaluated quickly:

• Protocol definitions
  
  
• Schedules
  
  
• All IP address based network elements (computers, computer sets, subnets, networks, and network sets)
  
  

Also, source port information is evaluated quickly.

Rules that use these elements should be placed at the top of the rule list.

The following rule elements require additional networking information and therefore are evaluated more slowly:

• Domain name sets and URL sets
  
  
• Users (other than the built-in "All Users" user set)
  
  
• Content type
  
  

Rules that contain such elements should be placed at the bottom of the rule list.

Rules that use the SMTP filter, HTTP filter, or FTP filter slow performance.

It is recommended that you organize your access rules in this order:

1. Global deny rules—Rules that deny specific access to all users. These rules should use the rule elements that require simple networking information. An example of such a rule would be a rule that denies all users access from anywhere to anywhere on protocols used for peer-to-peer file sharing.
   
   
2. Global allow rules—Rules that allow specific access to all users. These rules should use the rule elements that require simple networking information. An example of this would be a rule allowing access on the DNS protocol from the Internal network to the External network.
   
   
3. Rules for specific computers—Rules that allow or deny access for specific computers, for example, a rule allowing UNIX computers access to the Internet.
   
   
4. Rules for specific users, URLs, and MIME types, and also publishing rules—Rules that contain rule elements that require additional networking information and that enforce policy for specific users, or for specific URLs or Multipurpose Internet Mail Extensions (MIME) types. Publishing rules should also occur at this point in the rule order.
   
   
5. Other allow rules—Rules that handle traffic that does not match rules that occur previously in the list of rules, assuming the traffic is allowed by your corporate policy. For example, a rule allowing all traffic from the Internal network to the Internet.
   
   

   Note:
   Server publishing and Web publishing rules can be placed anywhere in the rule order after global allow or deny rules.

Place rules that are based on user sets lower in the rule order. If you put these rules high in the rule order, you preclude further processing of traffic coming from unauthenticated users who otherwise match the rule definition. This may have the unintended effect of an allow rule functioning as a deny rule for unauthenticated users.

Forefront TMG drops traffic from unauthenticated users after rules based on user sets, to preclude the bypassing by unauthenticated users of the rules based on user sets.

Note:
Forefront TMG can only try to match authenticated users against rules that require client membership in a user set. Authenticated users include Forefront TMG Clients, virtual private network (VPN) clients, and authenticated Web clients.

Where possible, use IP addresses rather than DNS names in your firewall policies. This reduces the reliance of Forefront TMG on the DNS servers, which results in better performance. However, be aware that in some situations, you will not achieve the desired behavior by using IP addresses. For example, if you are trying to deny access to a site and the site’s IP address is assigned dynamically, or if the site has more than one IP address, blocking an IP address does not block the site reliably. In this case, you should use the fully qualified domain name (FQDN) to block the site. For extra reliability, you can use both IP addresses and FQDNs in a rule. Note that you have to create separate rule elements for the IP addresses and for the FQDNs. When you use IP addresses and FQDNs in a single rule, the Forefront TMG rule engine first evaluates the request using the IP addresses, so that if there is a match, there is no need to try to resolve the FQDN to an IP address. This improves the efficiency of the rule. For examples of how Forefront TMG evaluates names and IP addresses in HTTP requests, see Processing names and addresses.

Use fully qualified domain names (FQDN) in domain name sets and URL sets.

For examples of how Forefront TMG evaluates URLs and IP addresses in HTTP requests, see Processing names and addresses.

When a rule requires user authentication, it must rely on connectivity to and speed of the authenticating server, such as the domain controller or Remote Authentication Dial-In User Service (RADIUS) server. The authentication process can affect the performance of Forefront TMG. It is therefore recommended that rules requiring authentication be placed near the bottom of the list of rules (assuming that this conforms to your policy design), so that only traffic that is not matched by an earlier rule will encounter the authenticating rule.

Note:
You can use Forefront TMG connectivity verifiers to monitor connectivity with various servers. To read more about connectivity verifiers, see Monitoring server connectivity.

If the firewall policy includes a rule that refers to a user set (other than the default All Users), the Forefront TMG Client always tries to authenticate and will fail if in a workgroup or in an untrusted domain. The Forefront TMG Client will not be able to establish a connection with the Forefront TMG computer, and no traffic will be allowed.

Do not create protocol definitions that duplicate or overlap existing protocol definitions. This can lead to unexpected behavior. For example, you may create a rule that allows all traffic except for a specific protocol, and you may find that the traffic you meant to deny on that protocol is actually allowed because there is a similar protocol defined. We recommend that you check the list of existing protocols carefully before you define additional protocols.

MIME types should be used as a criterion only in rules that apply solely to HTTP traffic. Because MIME types are not applicable to other types of traffic, a rule that includes any protocol other than HTTP and refers to MIME types is effectively disabled for those protocols.

An access policy that defines access between two networks will not allow access unless there is also a network rule defining the relationship between those two networks. This is also true for server publishing rules, but not for Web publishing rules.

Do not create a deny access rule on all protocols that includes a source port restriction. Because source ports are not checked for secondary connections, all protocols will then be blocked on secondary connections (if the rule allowing the secondary connection is lower in the rule order than the deny access rule with the source port restriction).

Restrict membership in the Remote Management Computers computer set to computers that require remote administration access. For example, do not add entire networks, such as the Internal network, to the computer set. This helps protect the firewall from worms that affect those networks.

Create a network to contain computers that are infected. Do not create any network rules for the network, so that it will not have any access. When a computer is infected, move it into that network. Note that each computer that you move into this network creates a gap in the address range of the Internal network, thus fragmenting it. Fragmented networks have a negative performance impact on Forefront TMG Network Load Balancing (NLB), so this approach should be used carefully, and computers should be returned to their original network as quickly as possible.