Overview of firewall policy

  • Article

This section provides information about how Microsoft Forefront Threat Management Gateway evaluates and allows traffic to flow between networks. Forefront TMG uses three rule sets:

  • Network rules. Network rules specify that resources in one network are allowed to communicate with resources in different networks, and they specify what type of relationship (either routing or NAT) exists between the source and destination. For more information, see About connecting networks.
  • System policy rules. Forefront TMG provides a number of predefined access rules that control traffic to and from the Local Host network (the Forefront TMG server). These rules allow traffic and protocols necessary for Forefront TMG to perform authentication, domain membership, network diagnostics, logging, and remote management. You can enable or disable these rules, and you can modify rule destinations. For more information, see About system policy.
  • Firewall policy rules. Forefront TMG provides a list of ordered rules that determine how traffic is allowed and filtered between sources and destinations. Firewall policy is made up of access rules, Web publishing rules, and server publishing rules.

How firewall policy works

When a request arrives, Forefront TMG does the following:

  1. Checks network rules to verify that a network relationship exists between the source and destination of the request. The only exception is for traffic handled by the Web proxy filter. Network rules do not affect this traffic. The predefined HTTP protocol is bound to this filter, and network rules are not checked for HTTP requests from internal clients using this protocol.
  2. Checks the system policy rules to determine whether one of these rules allows or denies the request.
  3. Checks firewall policy rules in the order in which they appear in the list.
  4. After matching the request with a rule, Forefront TMG checks the network rules again (except for traffic handled by the Web proxy filter) to determine whether to route or apply NAT to the traffic.
  5. If a Web proxy client made the request,Forefront TMG checks Web chaining rules in order to see whether the request should be routed to the destination network (usually the Internet) or to an upstream server. If a SecureNAT client or Firewall client made the request, Forefront TMG checks Firewall chaining rules that specify whether the request should be routed to the destination or to an upstream server. For more information, see About Web proxy chaining and About firewall chaining.

System policy rules and firewall rules are evaluated in a particular order. For more information, see Firewall policy best practices.

Outbound requests from internal clients

Generally, requests from internal clients are handled by access rules. Access rules can only be configured with outbound protocol definitions. When a request is received, Forefront TMG matches an access rule with the request by checking the rule elements in this order:

  • Protocol. The rule defines one or more protocols with an outbound direction.
  • From. The rule has a source address defined. The source can be an entire network, a set of networks, a computer or set of computers, an IP address range, or a subnet.
  • Schedule. The rule schedule controls when the rule is applied.
  • To. The rule has a destination defined. The destination can be an entire network, a set of networks, a computer or set of computers, an IP address range, a subnet, a domain name set, or a URL set. In some cases, a DNS lookup may be required to check that the request matches. For more information, see Processing domain name sets and URL sets.
  • Users. The rule applies to all users (for anonymous access), to all authenticated users (applied to any user who can authenticate successfully), or to a specific user group.
  • Content groups. The rule applies to specific content types.

If the request matches an allow rule, the request is allowed. After finding a matching rule, Forefront TMG does not evaluate further rules. Access rules that deny traffic are processed before publishing rules. If a request matches an access rule, the request will be denied, even if a publishing rule would have allowed the request.

Incoming requests

Forefront TMG uses Web publishing rules to make Web servers available for access from another network and uses server publishing rules to allow access to non-Web servers. Forefront TMG processes requests as follows:

  • For HTTP or HTTPS requests to a Web listener, Forefront TMG checks publishing rules and then Web chaining rules to determine whether the request is allowed and how it should be handled.
  • For non-HTTP requests, Forefront TMG checks network rules, and then checks publishing rules to determine if requests are allowed.

Name evaluation

When a client makes an HTTP request, it may be a name, a fully qualified domain name (FQDN), or an IP address. Forefront TMG handles these requests differently.

  • If an HTTP request uses a site name, such as https://www.fabrikam.com, Forefront TMG performs a forward name resolution to a DNS server to get the associated FQDN, aliases, and the IP addresses. Then Forefront TMG attempts to match these elements against a rule.
  • If an HTTP request uses an IP address, Forefront TMG first checks whether a rule matches that address. During this process, if Forefront TMG encounters a rule that requires a name, it performs reverse name resolution to obtain the FQDN for that IP address. Forefront TMG can then compare the FQDN to the access rule definitions.
  • If the reverse name resolution fails, only the original IP address in the request is used in comparison to the rule definitions.

Note that when a SecureNAT client requests a site by name, Forefront TMG first verifies that the host header content is not masking an unrelated IP address requested by the client. If this verification succeeds, the process continues as it would for a Web Proxy client.

Authentication

When rules requiring authentication are processed, Forefront TMG requires that the client present credentials. If the client cannot provide credentials, the request is dropped before the rule is evaluated. SecureNAT clients cannot provide credentials, and if a request from a SecureNAT client matches a rule that requires authentication, the request is dropped.