Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)
Understanding the concept of Network Rules.
- Published: Jan 13, 2009
- Updated: Jan 13, 2009
If you missed the first part in this article series please read Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.
Introduction
In our last article on 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 on the firewall. The addresses can be on and off-subnet for the specific NIC, but in order for a client behind any NIC on 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 on ISA and TMG Networking, or want to brush up on 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 on one ISA/TMG Firewall Network to connect to a host on 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 one 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 on the source Network are hidden from the destination host. The destination host sees the source IP address as the primary IP address on the external interface of the ISA/TMG firewall. The primary IP address is the IP on top of the IP address list (when there is more than one IP address bound to the external interface of the ISA/TMG firewall). A NAT route relationship is one-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 on one Network to a host on 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.
Network Rule Examples
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 on the default Internal Network try to connect to hosts on the default External Network, the source IP address seen by the host on the default External Network is going to be the primary IP address on 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 on 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 on 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 on the ISA firewall. One NIC is connected to the default External Network one NIC is connected to the default Internal Network, and one NIC is installed on a DMZ Network. There are two Network Rules configured on the ISA Firewall:
- A Network Rule connecting the default Internal Network to the default External Network, and the route relationship is NAT
- A Network Rule connecting the default Internal Network to the DMZ Network, and the route relationship is Route
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 on the external interface of the ISA firewall. When hosts on the default Internal Network connect to hosts on the DMZ Network, the destination hosts on the DMZ Network will see the source IP address as the actual IP address of the host on the default Internal Network. Likewise, since the route relationship is reciprocal, when a host on the DMZ Network tried to connect to a host on the default Internal Network, the host on the default Internal Network will see the source IP address as the actual IP address of the host on 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 on the DMZ Network tries to connect to a host on the default External Network? Since there is no Network Rule in place connecting hosts on 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 on the source Network. Connections from hosts on 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 on 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 on the DMZ Network. You want to allow incoming SMTP messages from the Internet to the SMTP server on 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 on 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 only. 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 on 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” on 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 on the default Internal Network try to connect to hosts on the DMZ Network, the DMZ Network hosts will see the source IP address of the connection to the be primary IP address on 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 on the DMZ Network to hosts on 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 on the DMZ Network try to connect to hosts on the default Internal Network, the hosts on the default Internal Network will see the source IP address of the connection request as the primary IP address on the Internal Network NIC. Access Rules are allow connections from hosts on the DMZ Network to the default Internal Network and publishing rules allow connections from hosts on 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 on the default Internal Network are on 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 on 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, on 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 on the back-end ISA/TMG firewall to the DMZ Network and define a Route relationship between the Networks. Now when hosts connect to resources on the DMZ Network, an Access Rule is used to allow the connection and the hosts on 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 on the DMZ Network to connect to hosts on the default Internal Network behind the back-end ISA/TMG firewall.
This scenario is important because many people would like to terminate VPN connections at the front-end firewall. When VPN 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 VPN clients access to resources on the default Internal Network behind the back-end ISA/TMG firewall. The take home point is that since the VPN clients are given IP addresses that belong to DMZ Network definition on 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 one 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 on 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 on 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 on 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 one that doesn’t belong to it’s default Internal Network and will drop the connection as spoofed.
Figure 10
Summary
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 on 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 only 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.
If you missed the first part in this article series please read Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.
About Thomas Shinder
Dr. Thomas W. Shinder is an MCSE, MCP+I, and MCT. He has worked as a technology trainer and consultant in the Dallas-Ft. Worth metro area, assisting in development and implementation of IP-based communications strategies for major firms such as Xerox, Lucent and FINA.
Click here for Thomas Shinder's section.
Share this article
Receive all the latest articles by email!
Get all articles delivered directly to your mailbox as and when they are released on ISAserver.org! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update. Sign up to the ISAserver.org Monthly Newsletter, written by ISA expert Dr. Tom Shinder, containing news, the hottest tips, ISA links of the month and much more. Subscribe today and don't miss a thing!
Latest articles by Thomas Shinder