In our last article . ISA and TMG firewall networking, I talked about how ISA and TMG firewalls use Networks to control traffic moving through and to the firewall. To recap, ISA and TMG Firewall Networks are collections of IP addresses located behind a specific NIC . the firewall. The addresses can be . and off-subnet for the specific NIC, but in order for a client behind any NIC . the TMG or ISA firewall to reach a destination through the firewall, that client’s IP address must be included in the definition of the ISA or TMG Firewall Network from which it connects. If the client’s IP address is not part of the ISA Firewall Network definition for the NIC that receives the request, the connection will be dropped as spoofed.

If you have not read part 1 of this series . ISA and TMG Networking, or want to brush up . what ISA/TMG Firewall Networks are all about, click here.

Now that you understand the details of ISA/TMG Firewall Networks, the next step is to understand how to connect those Networks. In order a host . .e ISA/TMG Firewall Network to connect to a host . another ISA/TMG Firewall Network, the source and destination Networks must be connected. The way you connect ISA/TMG Firewall Networks is by creating a Network Rule.

Network Rules connect ISA/TMG Firewall Networks in .e of two ways: NAT or Route. When you connect ISA/TMG Firewall Networks to each other, you also define the route relationship between the Networks.

Note:
Pay attention to the capitalization when I refer to networks. A “network” with a lower case “n” is a generic network, while a Network with an upper case “N” is an ISA/TMG Firewall Network.

When you define a NAT relationship between the source and destination Network, all IP addresses . the source Network are hidden from the destination host. The destination host sees the source IP address as the primary IP address . the external interface of the ISA/TMG firewall. The primary IP address is the IP . top of the IP address list (when there is more than .e IP address bound to the external interface of the ISA/TMG firewall). A NAT route relationship is .e-way. When you NAT from source to destination, you do not NAT from destination to source. For example, when you NAT from the default Internal Network to the default External Network, you do not NAT from the default External Network to the default Internal Network.

In general, when there is a NAT relationship between the source and destination Network, you create Access Rules to allow connections from the NATed to the non-NATed Network (for example, from the default Internal Network to the default External Network) and Publishing Rules to allow connections from the non-NATed Network to the NATed Network (for example, from the default External Network to the default Internal Network).

When you define a route relationship between two ISA/TMG Firewall Networks, the route relationship is reciprocal. That is to say, if you create a route relationship from source to destination Network, then there is also a route relationship between the destination and source Network. When there is a route relationship, no IP addresses are hidden, and the source IP address is always preserved.

In general, you use Access Rules to allow traffic in both directions when there is a route relationship between source and destination Networks. For example, if you have a route relationship defined for connections from the default Internal Network to a DMZ Network, then you can use Access Rules to allow connections from the default Internal Network to the DMZ Network, and you can use Access Rules to allow connections from the DMZ Network to the default Internal Network.

An example Network Rule appears in figure 1 below. In this example, there is a Network Rule that connects the DMZ Network to the default Internal Network and the route relationship is Route.

Figure 1

Remember, there must always be a Network Rule that connects the source and destination Network. Even if you create an Access Rule that allows a connection from a host . .e Network to a host . another Network, the connection attempt will fail because the Networks are not connected by a Network Rule. This problem can be hard to troubleshoot because when you check the ISA/TMG firewall’s log files, you will see that the connection attempt is denied, but there would not be any information indicating that the problem is a missing Network Rule. Well, that’s been true for ISA firewalls. I have not yet tested this with TMG firewalls. However, the problem should be less frequent with TMG firewalls, since when creating a new TMG Network, you are asked to define the Network Rule before the Network is created. In contrast, with the ISA firewall, you could create a Network without creating a Network Rule.

To get a better understanding of how Network Rules work in connecting ISA/TMG Firewall Networks, let’s look at a few examples. In figure 2 below, you will see a typical configuration for an ISA/TMG firewall with a default Internal and default External Network. In this example, there is a Network Rule connecting the default Internal and External Networks, and the Network Rule defines a NAT relationship between the Networks.

When clients . the default Internal Network try to connect to hosts . the default External Network, the source IP address seen by the host . the default External Network is going to be the primary IP address . the external interface of the ISA/TMG firewall. In effect, the ISA/TMG firewall is “hiding” the IP address of the source client.

Figure 2

ISA and TMG firewalls can be configured with multiple NICs. There is no limit . the number of NICs you can install in an ISA or TMG firewall. In fact, you can even create virtual NICs using 802.1q VLAN tagging, as long your NICs and NIC drivers support this configuration. When you have multiple NICs installed . the ISA firewall, you can create an ISA/TMG Firewall Network for each of the NICs (recall our discussion of ISA/TMG Firewall Networks in part 1 of this article series, where each NIC represents the “root” of each ISA/TMG Firewall Network).

In the figure below, you can see that there are three NICs installed . the ISA firewall. .e NIC is connected to the default External Network .e NIC is connected to the default Internal Network, and .e NIC is installed . a DMZ Network. There are two Network Rules configured . the ISA Firewall:

In this configuration, connections from the default Internal Network to the default External Network will be NATed, and the destination hosts will see the source IP address of the connection as the primary IP address . the external interface of the ISA firewall. When hosts . the default Internal Network connect to hosts . the DMZ Network, the destination hosts . the DMZ Network will see the source IP address as the actual IP address of the host . the default Internal Network. Likewise, since the route relationship is reciprocal, when a host . the DMZ Network tried to connect to a host . the default Internal Network, the host . the default Internal Network will see the source IP address as the actual IP address of the host . the DMZ Network.

In this next example (figure 3), connections from the default Internal Network to the default External Network are allowed by using Access Rules. Connections from the default External Network to the default Internal Network are allowed by publishing rules (either Web or Server Publishing Rules). Connections from the DMZ Network to the default Internal Network, and from the default Internal Network to the DMZ are allowed using Access Rules.

Figure 3

What do you think will happen if a host . the DMZ Network tries to connect to a host . the default External Network? Since there is no Network Rule in place connecting hosts . the DMZ Network to the default External Network, the connection attempt will be denied, as seen in figure 4 below. Even if there is an Access Rule allowing the connection, the connection attempt will fail because there is no Network Rule connecting the Networks.

Figure 4

Let us say that we create a Network Rule that connects the DMZ Network to the default External Network and define the route relationship as NAT. When there is a NAT relationship, we can use either public or private addresses . the source Network. Connections from hosts . the DMZ Network to the default External Network are allowed by using Access Rules, and connections from the default External Network to the DMZ network are allowed by using publishing rules.

Figure 5

Figure 6 below shows a slight alteration in the configuration. In this case, there is a route Network Rule connecting the DMZ Network to the default External Network. Because there is a route relationship, we must use public addresses . the DMZ Network, because private addresses are not routable over the Internet. We can use Access Rules to allow connections from the DMZ Network to the default External Network, and we can also use Access Rules to allow connections from the default External Network to the DMZ Network.

Up to this point, I’ve been telling you that when you have a route relationship, you can use Access Rules to control traffic in both directions. However, it is possible to use publishing rules. In the case or Web Publishing Rules, the route relationship isn’t an issue, because the connections are always proxied from the source and destination Network, so no actual “routing” at an IP level actually takes place. However, the situation is a little different with Server Publishing Rules.

When there is a route relationship between the source and destination Network, you can allow incoming connections using either an Access Rule or a Server Publishing Rule. In some cases, you might want to use a Server Publishing Rule instead of an Access Rule, because application layer inspection filters are bound to some Server Publishing Rules that can’t be bound to access rules.

For example, in the example configuration noted in the above figure 5, there is a route relationship because the default External Network and the DMZ Network. Suppose you have an SMTP server . the DMZ Network. You want to allow incoming SMTP messages from the Internet to the SMTP server . the DMZ Network. In this case, you could create an Access Rule to allow incoming SMTP connections from the default External Network to the DMZ Network, or you could create a Server Publishing Rule that publishes the SMTP server . the DMZ Network.

The advantage of using a Server Publishing Rule in this scenario is that the SMTP filter can be bound to the “SMTP Server” protocol. “Server” protocols are for inbound connections .ly. The SMTP filter can’t be bound to the “SMTP” protocol, which is used for Access Rules. Thus, a Server Publishing Rule using the SMTP Server protocol allows us to apply application layer inspection . the incoming connections.

I should note here that when you do use Server Publishing Rules to publish servers in a scenario where this is a route relationship between the source and destination Network, you still publish the machine using the actual IP address of the published server. However, the ISA or TMG firewall then performs a bit of magic to intercept the connection so that application layer inspection can be performed. The firewall does what is called “port stealing” . the Server Publishing Rule, so that when connections destined to the actual IP address of the published server are made, the firewall “steals” the connection and passes it to the application layer inspection filters. If the connection passes inspection, then it is forwarded to the published server. If the connection does not pass inspection, then it is dropped.

Figure 6

Now let us change our focus and look at the connectivity between the DMZ Network and the default Internal Network. In figure 7 below, you can see that we have a Network Rule connecting the default Internal Network to the DMZ Network, and the route relationship is NAT. Because the route relationship is NAT, when hosts . the default Internal Network try to connect to hosts . the DMZ Network, the DMZ Network hosts will see the source IP address of the connection to the be primary IP address . the DMZ NIC.

To allow connections to the DMZ Network from the default Internal Network, you need to create Access Rules. To allow connections from hosts . the DMZ Network to hosts . the default Internal Network, you need to create publishing rules. What you cannot do when there is a NAT relationship from the default Internal Network to the DMZ Network is create Access Rules allowing connections from the DMZ Network to the default Internal Network.

Figure 7

Figure 8 shows a reversal of the Network Rule connecting the DMZ Network to the default Internal Network. In this case, the Network Rule defines a NAT relationship from the DMZ Network to the default Internal Network. When hosts . the DMZ Network try to connect to hosts . the default Internal Network, the hosts . the default Internal Network will see the source IP address of the connection request as the primary IP address . the Internal Network NIC. Access Rules are allow connections from hosts . the DMZ Network to the default Internal Network and publishing rules allow connections from hosts . the default Internal Network to the DMZ Network. You cannot create Access Rules to allow connections from the default Internal Network to the DMZ Network because the hosts . the default Internal Network are . the non-NATed Network.

Figure 8

The next scenario looks at a scenario that is a common point of confusion: the back to back ISA/TMG firewall configuration. In a back to back firewall configuration, there is a front-end ISA/TMG firewall that is connected to the Internet, and there is a back-end ISA/TMG firewall that is connected to a DMZ behind the front-end firewall and an internal network behind the back-end firewall.

In the typical case, the front-end ISA/TMG firewall has a NAT route relationship between the DMZ network behind the front-end firewall and the default External Network. The back-end ISA/TMG firewall has a NAT relationship between the default Internal Network and the default External Network.

What you should appreciate here is that in this typical scenario, the DMZ network in front of the back-end ISA/TMG firewall is part of the back-end ISA/TMG firewall’s default External Network. Because it is part of its default External Network, the route relationship is going to be NAT. Therefore, if hosts behind the back-end ISA/TMG firewall need to connect to machines . the DMZ network between the firewalls, then you will create Access Rules to enable those connections. If there are machines in the DMZ network between the firewalls that need to connect to hosts behind the back-end ISA/TMG firewall, then you will need to create publishing rules to enable those connections.

Figure 9

Now let’s look a variation of the above scenario. In this case, . the back-end ISA/TMG firewall we create an ISA/TMG Firewall Network for the DMZ between the firewalls. Then we create a Network Rule that connects the default Internal Network . the back-end ISA/TMG firewall to the DMZ Network and define a Route relationship between the Networks. Now when hosts connect to resources . the DMZ Network, an Access Rule is used to allow the connection and the hosts . the DMZ Network see the source IP address as the original client IP address. This configuration also allows you to create Access Rules to allow hosts . the DMZ Network to connect to hosts . the default Internal Network behind the back-end ISA/TMG firewall.

This scenario is important because many people would like to terminate *** connections at the front-end firewall. When *** clients are terminated at the front-end ISA/TMG firewall, they are given IP addresses that are part of the DMZ Network. Thus, they act as DMZ Network hosts. You can then create Access Rules that allow the *** clients access to resources . the default Internal Network behind the back-end ISA/TMG firewall. The take home point is that since the *** clients are given IP addresses that belong to DMZ Network definition . the back-end ISA/TMG firewall, you can use Access Rules instead of publishing rules due to the route relationship between the two Networks.

There is .e more thing you should be aware of in this back to back configuration where there is a route relationship between the back-end ISA/TMG firewall’s default Internal Network and the DMZ Network. When hosts . the back-end ISA/TMG firewall’s default Internal Network try to connect to the Internet, the connections must go through both firewalls. When the front-end ISA/TMG firewall receives the outbound connection request from hosts . the back-end ISA/TMG firewall’s default Internal Network, the source IP address is going to be the actual IP address of the host making the request.

Normally, the default Internal Network for the front-end ISA/TMG firewall will include the IP addresses . the DMZ Network. However, since there is a route relationship between the DMZ Network and the back-end ISA/TMG firewall’s default Internal Network, you need to include the addresses in the back-end ISA/TMG firewall’s default Internal Network in the addresses that define the front-end ISA/TMG firewall’s default Internal Network. If you fail to do this, the front-end ISA/TMG firewall will see the source address as .e that doesn’t belong to it’s default Internal Network and will drop the connection as spoofed.

Figure 10

In this, part two in our series about ISA/TMG Network concepts, I went over some scenarios that were designed to help you understand the concept of Network Rules. Network Rules are required to connect Networks. If source and destination Networks are not connected, no communications will be allowed between those Networks, even if there are Access Rules configured to allow the connections. When defining a Network Rule to connect a source and destination Network, you also define the route relationship. The route relationship can be either NAT or Route. Access Rules and publishing rules are supported in a different way, depending . the route relationship between the source and destination Networks.

Next week we will look at a case study where we had to have a good understanding of how ISA/TMG firewall Networks work in order to get a working solution. This case study involves migrating an old ISA 2000 firewall to ISA 2006. Not .ly that, but the migration also includes changing over from a unihomed ISA firewall to a dual-homed firewall. As you might imagine, there were several network issues that needed to be addressed. You find out what the problems where and how we solved them in the next article. See you then! –Tom.