TMG Firewall Access Control Policies and Rules (Part 3)

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

Introduction

In Parts 1 and 2 of this series, we talked about the different types of policies that are used to control access to and through the firewall, how these different policies are processed and how allow and deny decisions are ultimately made, then delved deeper into the various components of the access control policies. This time, we’ll move on to a new phase of our discussion on TMG firewall network access policies and address network relationships and network rules.

TMG networks

Before we talk about network relationships and the rules that allow networks to communicate with each other, let’s begin by making sure that we understand how the TMG firewall defines a network.

From the TMG firewall’s perspective, a network is just a collection of IP addresses. Typically, different collections of IP addresses should be based on some kind of subnet boundaries, but that’s not a requirement. The collection of IP addresses can be very small, such as a five computer or IP address subnets. Or it can be very large, such as the entire public IP address space on the Internet.

The TMG firewall needs to be able to identify the network that a request came from and it needs to identify the network that the request is destined for. If the TMG firewall doesn’t understand either one of those networks, then connection requests will fail when making it through the TMG firewall. How does the TMG firewall identify a network? You have to help it out here, by creating a Network Definition in the TMG firewall’s configuration interface.

Default networks

There are a couple of Networks that are already built into the TMG firewall that you don’t need to configure. These are:

  • The default Internal Network
  • The default External Network

The default Internal Network is defined as all addresses that are reachable by the internal interface of the TMG firewall. In most cases, the TMG firewall is going to have at least two interfaces, and one of them is going to connect to the corporate network. One of the key characteristics of the default Internal Network is that the TMG firewall should be able to reach domain controllers and internal DNS servers through the default Internal Network interface.

The default External Network is defined as all IP addresses that are not part of the default Internal Network. That’s pretty broad. The default External Network is different from the default Internal Network in that you don’t have to provide any IP address information in order to define the default External Network. When you configure the default Internal Network, you are asked for the IP address range that is reachable from the default Internal Network interface. In contrast, there are no configuration requirements for the default External Network. The default external Network is just any IP and every IP address that isn’t assigned to a Network that is defined on the TMG firewall.

Custom networks

In addition to the default Networks that you define on the TMG firewall, there is also the option to create your own TMG firewall Network definitions. There are two types of custom Network definitions that you can create on the TMG firewall:

  • Internal Networks
  • External Networks

Internal Networks are Networks that are associated with network interfaces that connect to the corporate network or networks that are trusted by the organization. Each network is associated with a NIC on the TMG firewall. For example, suppose you have three NICs that are connected to the TMG firewall. One NIC is connected to the default Internal Network, another NIC is connected to the default External Network, and the third NIC is connected to the production server network. You can create a new Internal Network definition for the production server network. That Network definition would include all the IP addresses of the servers on that Network that are reachable from the TMG firewall through the network interface that is connected to the production server network.

An External Network definition is typically one that is relatively untrusted by the organization. Clearly, the default External Network is untrusted. But what other types of Networks might you create that are relatively untrusted? How about a public access DMZ? How about a guest wireless LAN client Network?

For example, let’s suppose you now have a TMG firewall that has five network interfaces:

  • One network interface is connected to the default Internal Network
  • One network interface is connected to the default External Network
  • One network interface is connected to the production server Network
  • One network interface is connected to a public access DMZ
  • One network interface is connect to a private access DMZ

The fourth NIC, the one that’s connected to the public access DMZ, can be used to access a collection of IP addresses that are reachable from that NIC, where those IP addresses are those that are used by devices located on the public access DMZ. A public access DMZ is a DMZ that allows devices located on the default external Network to initiate connections to devices on the public access DMZ Network. This is pretty much what everyone would consider a very low trust Network. This most likely would be categorized as an External Network because of the trust issue.

Internal vs. External networks

I included the fifth Network in the scenario above because it brings up some interesting possibilities in terms of how you would define a Network and drives home a point I want to make regarding Network definitions. A private access DMZ is one that contains devices that accept outbound connections on behalf of internal clients to access information that is located somewhere on an external Network. For example, you could put DNS forwarders or outbound SMTP relays on the private access DMZ Network. Would this be considered an External Network or an Internal Network?

You might consider it an internal Network since it doesn’t accept any unsolicited inbound connections from External Network located systems. On the other hand, you might consider it an external Network since you allow clients on internal networks to communicate directly with these systems on the private access DMZ Network.

What is the answer? There really isn’t any “right” answer to this puzzle, because there is no functional difference between Internal and External Network definitions. The terms External and Internal (outside of the default External and Internal Network definitions) are for accounting purposes only, to let you know about relative levels of trust and to a certain extent, to make it easier for you to decide what type of routing relationship you want to allow between any two Networks. We’ll talk about how that works in more detail later.

Complex scenarios

Let’s add another Network definition to the mix – how would you categorize the following network?

  • Another NIC connects the DMZ firewalls to a Network that lies between a back-end and front-end TMG firewall

Now the concept of Internal Network and External Network gets even more blurred, since this back to back DMZ Network exists from two different perspectives; one perspective is that of the TMG firewall in the front of the back to back configuration, and the second perspective is that of the TMG firewall in the back of the back to back configuration.

From the perspective of the front-end TMG firewall, the back to back DMZ Network could be considered an Internal Network. In fact, it will have to be configured as part of the default Internal Network, since the external interface will be connected to the default External Network. In contrast, from the perspective of the back-end TMG firewall, the back to back DMZ Network could be configured as either part of the default external Network, or it could be defined as part of the default External Network. To make the back to back DMZ network part of the default External Network, all you need to do is not create a Network definition for the IP addresses contained in the back to back DMZ network.

Creating Network Definitions is just the first part. However, keep in mind that you don’t have to have any Network Definitions defined other than the default Internal and External Networks. If all you want to have is two NICs connected to your TMG firewall, then the default Networks are all you need. However, if you are going to have more than two NICs in your TMG firewall, then you’re going to need to create your own Network definitions to support those NICs.

The role of the NIC

It’s important to understand the critical role that the NIC plays in defining TMG Networks. Think of the NIC as the “root” of the Network definition. Any device that can go through the TMG firewall to reach a different Network than the one on which the device resides must do it through the NIC that is associated with that device’s Network. Similarly, when the TMG firewall needs to connect to a device on a Network, it must use the NIC that is root of that Network. The NIC that is the root of a Network definition is the closest NIC to that Network.

For example, let’s consider a TMG firewall with three NICs – an external NIC, a DMZ NIC and a default Internal NIC. If the TMG firewall wants to communicate with a domain controller, which NIC is the closest to the domain controller? If you said the NIC connected to the default Internal Network, then you’re absolutely right.

Summary

Understanding TMG firewall Network definitions is key to understanding the firewall’s view of the network universe. The TMG firewall is only aware of networks that have been defined on the TMG firewall. If there is no Network defined for a source or destination address, the TMG firewall will not be able to communicate with that device. In the next article in this series, we’ll discuss how we enable communications between Networks through the use of Network relationships and routing rules. See you then! –Deb.

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

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top