TMG Firewall Access Control Policies and Rules (Part 2)

If you would like to read the other parts in this article series please go to:

In the first article in this series about access control in the TMG firewall, we talked about the different types of policies that are used to control access to and through the firewall. We also talked about how these different policies are processed and how ultimately allow and deny decisions are made. In this part 2 of our series, we’ll continue to discuss access control and this time we’ll delve a little deeper into the various components of the three access control policies that we introduced to you last time.

Let’s start today with Access Rules. Access Rules are used to control the allow/deny decisions made by internal clients. What I mean by “internal” is anything that isn’t “external”, with external being defined as anything that is considered to reside outside the corporate network. For example, you might have a TMG firewall that has three DMZ networks and a default Internal Network. These four networks would be considered internal, and everything else is considered external. Another way to think about Access Rules is that they are responsible for controlling outbound access (sometimes referred to “egress traffic”).

Access Rules have several elements to them and each of these elements will be evaluated in a specific pre-determined order to make the outbound access allow/deny decisions as efficient as possible. The elements of an Access Rule include the following:

  • Protocol. Each Access Rule is assigned one or more protocols. A protocol can be based on ICMP, UDP or TCP. The TMG firewall comes with over 120 pre-defined protocols supported out of the box. And even better, If the protocol that you need isn’t included, you can create your own custom protocol.
  • From. This is the location of the networked device that is initiating the request. You can define the From location as an IP address, a collection of IP addresses, a subnet, a Network object defined in the TMG firewall, or even as a collection of Networks.
  • Schedule. This component of an Access Rule defines the time of day that the Access Rule is in effect. There are a few pre-defined Schedule definitions. However, if none of the pre-defined schedule definitions work for you, you can always create your own custom schedule. It’s important to note that existing connections will not be dropped based on a schedule. For example, if you have a schedule that allows outbound connections during 9 AM to 5 PM, new connections will not be allowed after 5 PM. However, existing connections that were made prior to 5 PM will not be dropped. Those connections will have to drain out as users disconnect.
  • Users. This defines the identities to which a particular rule applies. You can configure the rule to apply to all users, to all authenticated users, or to a subset of authenticated users, which would be to a particular group of users.
  • Content Groups. Content Groups are used to control what types of content are to be accessible through the rule. These Content Groups are defined for web pages, for the most part.

The TMG firewall will go through the Access Rule set that is included in firewall policy and it will run through all the Access Rules until it finds one that matches an allow rule that enables access. If an allow rule is not found, then the connection will be dropped. The connection will also be dropped if there is a specific deny rule that denies a connection. An interesting scenario can exist whereby there could be a publishing rule (such as a Web Publishing Rule or a Server Publishing Rule) that allows the connection and there is also a deny rule that applies to the same parameters. In this case, the deny rule will always take precedence over the allow publishing rule.

Another type of rule that you can create in Firewall Policy is publishing rules. In contrast to Access Rules, publishing rules are used to control access from (in general) an external location to an internal location. I say “in general” because it is also possible for you to create a publishing rule that allows access from one internal location to another internal location. There are two types of publishing rules:

  • Web Publishing Rules. Web Publishing Rules are used to allow inbound access for web protocols. You can think of Web Publishing Rules as reverse proxy rules. You can publish the HTTP, HTTPS and FTP protocols using Web Publishing Rules. An interesting note is that in the case of FTP, you’re actually publishing the FTP site to an external user who will use HTTP/S to access the FTP site, so you’re not exactly (technically) doing FTP publishing in this scenario.
  • Server Publishing Rules. Server Publishing Rules allow inbound access for any protocol, including HTTP and HTTPS. Server Publishing Rules provide a sort of reverse NAT connection (if you choose to use NAT instead of Route), which enable inbound access to the resources on your corporate network. Server Publishing Rules use server publishing protocols that are included with the TMG firewall. As with protocols for Access Rules, if there isn’t a server publishing protocol available for the protocol that you’re interested in, then you can create your own custom server publishing protocol. Many of the built-in server publishing protocols have security filters attached to them to ensure things such as protocol normalization and other security controls. Remember that in contrast to Web Publishing Rules that are handled by the web proxy filter, Server Publishing Rules do not perform application layer inspection on HTTP and HTTPS connections.

In many cases, the TMG firewall will perform name resolution on behalf of the client that is connecting to resources through the TMG firewall. This happens when you have a web proxy client or a Firewall client connection to external resources through the TMG firewall. In all cases, the TMG firewall will attempt to perform name resolution of its own, since it needs to know whether or not the destination is allowed.

The name resolution process looks something like this:

  • In the case of HTTP access, if the TMG firewall receives a URL for the destination, it will try to resolve that name to an IP address. It will also try to determine whether there are any CNAME records for that address. After obtaining this information, the TMG firewall will then try to match this information to a rule in order to determine whether the destination is allowed or denied.
  • When a user makes an HTTP request using an IP address, the TMG firewall will need to know whether the destination IP address is associated with a URL that is denied by a rule. In this case, the TMG firewall will attempt to perform reverse name resolution if it needs to. To be more efficient, the TMG firewall will check to determine whether any of the rules deny the destination IP address. If there is no rule that denies the destination IP address, the TMG firewall will perform reverse name resolution in order to determine whether that IP address resolves to a FQDN (fully qualified domain name) that is included in a deny rule.
  • Given that DNS databases are notoriously woefully poor at maintaining their address lists (reverse lookup zones), if the TMG server is unable to perform reverse name resolution, it will have to settle for using the IP address only. For this reason, you should take extra care to check your logs for requests that are made to IP addresses only and determine why an IP address was used as well as the nature of the destination site using that IP address.

In the special case in which a SecureNAT client makes an outbound request through the TMG firewall, the TMG firewall will check the host header on the response that is returned to make sure that there isn’t any content being masked that might contain an IP address that is unrelated to the URL being requested.

Finally, Access Rules can be configured so that authentication is required. When no authentication is required, those rules are called anonymous access rules. When you do require authentication (which is obviously the best security practice), the user must be able to authenticate to the TMG firewall. Only web proxy and firewall client configured system can authenticate to the TMG firewall for outbound access. For inbound access (using publishing rules), only connections that use Web Publishing Rules are capable of being authenticated. Server Publishing Rules do not support authentication.

The TMG firewall will request that the client sends credentials if it encounters a matching rule that requires authentication. If the client is not able to authenticate (for example, in the case of SecureNAT clients) or if the client cannot provide credentials that match the authorization requirements for the rule, then the connection will be dropped.


In this article, Part 2 of a series, we took a closer look at the components of the rules that enable both inbound and outbound access. In addition, we discussed some of the details of request processing and name resolution. In the next article in this series, we’ll look at some details of network relationships and then we’ll examine System Policy. See you next time! –Deb.

If you would like to read the other parts in this article series please go to:

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