TMG Firewall Access Control Policies and Rules (Part 1)

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

The TMG firewall is a lot of things. It’s a web proxy server, a winsock proxy server, a remote access VPN server and a site to site VPN gateway. It’s also a network firewall, and in its day, it was probably one of the most secure firewalls in existence. Of course, with the TMG firewall out of development, a lot of changes have happened in the industry. However, the product is still supported by Microsoft, so you might still be using this “software” firewall. We still use it around here, and taking our time testing potential replacements in anticipation of the day our beloved TMG goes away for good.

In its role as a firewall, the firewall’s main job is to control network access. Let’s do a refresher on how it does that. There are two directions in which network access travels and controls can be applied to either or both directions of traffic.

Inbound access (some refer to this type of access as “ingress”). Inbound access takes place when someone outside of your organization tries to access information and resources within your network. Inbound access initiates connections from somewhere over the Internet.
Outbound access (some refer to this as “egress”). Outbound access takes place when someone within the confines of your network initiates a connection to a resource outside of your network.

Of course, there are some shades of gray that we encounter when we start to think about inbound and outbound access through the TMG firewall. Since the TMG firewall supports multiple types of networks, it would be technically correct to say that a user located on a “guest” network who tries to access resources on your production network is performing a type of inbound access. Similarly, users who initiate connections through the TMG firewall from a production network where the client systems are located to a network where servers are located could be considered to be performing a type of outbound access. However, in most cases when we refer to traffic using the labels inbound and outbound access, we are thinking in terms of inbound meaning from the Internet to the internal network and outbound being from the internal network to the Internet.

The TMG firewall is able to control inbound and outbound access by enforcing three types of policy:

Firewall policy
System policy
Network policy (technically known an Network Rules)

Firewall policy controls all traffic that moves through the TMG firewall. The way you can determine which types of traffic will be allowed to move through the firewall is by creating a rule set. There are three types of rules that comprise the firewall policy:

Access Rules – these rules apply to outbound connections through the TMG firewall. The outbound connections can be connections to resources that are located on the Internet, or they can be to resources that are located on networks that you control. The key issue is that the source of the request must be on a network other than one where the destination computer of the request is located.
Web Publishing Rules – these rules allow inbound connections. However, that doesn’t include just any old inbound connections; the inbound connections to which web publishing rules can be applied must use the HTTP, HTTPS or FTP protocols. The reason for this is that Web Publishing Rules are handled by the web proxy service, and thus they represent reverse proxy connections.
Server Publishing Rules – these rules also enable inbound connections through the TMG firewall. The difference between these and Web Publishing Rules is that Server Publishing Rules are not handed by the web proxy service. Instead, they are handled by the firewall service and essentially represent reverse NAT rules with NAT editor type functionality that also includes security inspection for some of the protocols. Thus these are the rules you can use to control inbound traffic that uses protocols other than HTTP, HTTPS and FTP.

Sometimes admins get confused about the difference between Firewall Policy, System Policy, and Network Policy, so let’s take a minute to talk a little about each of these. It’s really pretty simple.

Whereas Firewall Policy controls traffic through the TMG firewall, System Policy controls traffic moving to or from the TMG firewall (the system on which TMG is installed) itself. There is a lot of traffic that the TMG firewall generates to support things such as DNS look-ups, domain related traffic, and connection requests to get anti-malware updates. In addition to these types of connections that are initiated by TMG firewall, you also have those connections that are made to the TMG firewall. Two important examples of connections that you would want to allow to the TMG firewall itself are connections that are made to the firewall for web proxy and firewall client requests.

System Policy is managed a bit differently than Firewall Policy. With Firewall Policy, you can essentially create rules from scratch to allow or deny traffic as you see fit through the TMG firewall. In contrast, System Policy represents a collection of rules that are hard coded into the product. That means you cannot delete these rules. However, you can configure them based on your requirements.

Be aware that even though I’ve characterized Firewall Policy as being focused on traffic moving through the firewall and System Policy as traffic moves to and from the firewall, the fact is that Firewall Policy rules are flexible enough to allow you to also control traffic moving to and through the firewall itself. In general, though, you ought to avoid doing this if you don’t absolutely have to. The TMG firewall team did a very thorough job of figuring out which traffic should be allowed to and from the TMG firewall, so it’s always best to check the System Policy Rules before going out on a limb on your own by creating new Firewall Rules for that purpose.

Finally, there is Network Policy, also known as Network Rules. Network Rules essentially allow you to define the routing relationship between any two networks. There are two types of route relationships that you can define between any two networks: route or NAT. By the way, you have a lot of flexibility here, since “networks” are defined as a collection of IP addresses.

Now that we have a clearer understanding of how the TMG firewall classifies the types of traffic that are handled by the different types of rules, let’s take a look at how those rules are handled by the firewall. Imagine that a client initiates a request that is destined to or through the firewall. What happens?

The first thing the TMG firewall does is attempt to figure out whether the source and destination are “connected”. Connected in this instance means that there is a Network Rule that defines a relationship between the source and destination networks. If there is no rule that defines the relationship, or if there is a rule but it denies the connection, then the connection is denied and the request is dropped. If there is a rule that connects the networks and it is configured as an allow rule, then TMG can go ahead and process the rule some more.
Our intrepid connection request is next confronted by the System Policy Rules. The System Policy Rules are numbered, and the request is matched against the rules in order. If one of the System Policy Rules denies the connection, the connection will be dropped at that point. Otherwise, it will proceed to the next step.
As our connection continues to run the gauntlet, it next faces the Firewall Policy Rules. Again, these rules are numbered and the connection request is evaluated in order of the rules. The first deny rule that matches brings an untimely end to our stalwart connection request.
If our unflagging connection makes it this far, it will meet up again with the indefatigable Network Rules. However, during this rematch, the Network Rules realize that they’ve already been defeated and so they only check to determine whether the routing relationship is Route or NAT. Once that’s done, they forward the connection to its destination using the applicable one of those routing approaches.

Note that if the connection is handled by the web proxy filter, then the Network Rules stand back and do not attempt to block the connection attempt. You might wonder why there are no network rules applied when the connection is handled by the web proxy filter. The reason for this is that all connections through the web proxy filter are seen as connections to the TMG firewall itself. When acting as a web proxy, the TMG firewall acts on behalf of the computer that sent the request. When the TMG firewall web proxy filter receives the request, it then recreates the request instead of just forwarding it. Since the TMG firewall is seen as the “new” client for the connection request, it doesn’t need to incur the overhead of going through the network rules in order to accomplish what it needs to do.

Summary

This is part 1 of a multi-part refresher on how TMG works in regard to access control. In this article, we began our review with a look at policy and rule types. We discussed how the firewall maintains three types of policies – the Firewall Policy, the System Policy and the Network Policy (Network Rules). Using these three policies, the TMG firewall is able to control traffic destined to and through the firewall. In the next article in this series, we’ll talk about some of the details of the rules that comprise these policies. See you then.

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