Overview of ISA and TMG Networking and ISA Networking Case Study

[LEFT][CODE]http://www.isaserver.org/tutorials/Overview-ISA-TMG-Networking-ISA-Networking-Case-Study-Part1.html[/CODE]

[SIZE=3][B]PART-1[/B][/SIZE]

What ISA/TMG firewall Networks are about and how the firewall uses these networks to perform several key functions

Last week I did a blog post asking our ISAserver.org members what kind of content they would like to see on the site. I expected the typical stuff, such as “more articles on integrating with other networking equipment vendors” and “more information on how NLB works” and “more articles on how to make ISA and TMG work with Exchange 2007, SharePoint and OCS” and maybe even “more stuff about ISA and TMG add-ons”. I was not disappointed. I did get requests for all of that kind of content.
There was also another comment that I thought was interesting. Someone wrote to me and said that what he would like is some information on the basics. For example, the basics of ISA networking. This fellow said that many Microsoft admins who use ISA have a basic understanding of TCP/IP networking but do not have a good grip on how the ISA firewall see the networked world and any information that would help along those lines would be very helpful.
The comment was a timely one for me, as it dovetailed with some other experiences I was having last week. Therefore, in the spirit of this request for some return to the basics and my experiences last week, we will go over some of the basics of ISA/TMG firewall networking.
[B]ISA/TMG Firewall Networks[/B]

[B]NOTE:
[/B]Pay close attention to the capitalization I use in this article. Network with a capital “N” refers to an ISA/TMG Firewall Network – which is a network objects that the firewall uses to define collections of IP addresses directly accessible from a specific network interface. In contrast, when a lower case “n” is used for network, I am referring to a generic network or network segment.
ISA and TMG firewalls see the networked world based on the concept of the [B]Network [/B]network object. The [B]Network[/B] network object defines traffic that moves through the firewall. All traffic that moves [I]to[/I] or [I]through[/I] the firewall must source from one Network and have a destination to another Network. If the source and destination traffic are on the same Network, then the traffic doesn’t move [I]through[/I] the firewall. However, there are times when traffic with the same source and destination Network can [I]bounce off[/I] the firewall. We will take a look at this example later.
What is an ISA Firewall Network? An ISA/TMG Firewall Network is a collection of IP addresses that can directly reach a NIC on the firewall without having to traverse the firewall. For example, consider a simple scenario where the ISA firewall has two NICs: an internal interface with an IP address of 10.0.0.1 and an external interface with a public IP address. There is a host connected to the same network as the firewall’s internal interface and that client has an IP address of 10.0.0.2. In this example, the internal interface and the client at 10.0.0.2 are part of the same network, since the client can directly reach that interface without crossing the firewall. In addition, the client can’t be on the same network as the external interface of the firewall, since it would have to cross the firewall to reach that interface.
The figure below depicts this example. The internal interface has the IP address [B]10.0.0.1[/B] and the client behind that interface has IP address [B]10.0.0.2[/B]. The client behind the internal interface can reach the internal interface directly. The client behind the internal interface cannot reach the external interface directly. Therefore, the client could never be a member of the ISA Firewall Network that the external interface belongs to.
[IMG]http://www.isaserver.org/img/upl/image0021229419308209.JPG[/IMG]
[B]Figure 1[/B]
As I mentioned earlier, an ISA Firewall Network is defined as a collection of IP addresses that can be reached directly through one of the interfaces on the ISA or TMG firewall. However, this does not mean that all of those IP addresses have to be on the same network ID as the interface on the ISA firewall.
For example, in the figure above, the internal interface of the ISA firewall was on network ID 10.0.0.0/24 and the client was an “on subnet” client that was also on network ID 10.0.0.0/24. The ISA Firewall Network defined for that interface was 10.0.0.0-10.0.0.255.
What if there is a router behind the ISA firewall’s internal interface and there are remote network IDs that need to connect to the Internet through the ISA Firewall’s internal interface? For example, in the figure below you see that I have added a router and a remote network ID behind that router, which in this case is 192.168.1.0/24. Will the ISA Firewall need to see connections from the 192.168.1.0/24 network ID as being on the same ISA Firewall Network as connections from the 10.0.0.0/24 network ID?
The answer is YES. The reason for this is that both 10.0.0.0/24 and 192.168.1.0/24 in this example have to connect to and through the ISA firewall using the same NIC. Since the ISA Firewall see each NIC as the root of an ISA Firewall Network, all connections made directly to and through the firewall on that interface are part of the same ISA Firewall Network.
[IMG]http://www.isaserver.org/img/upl/image0041229419308256.JPG[/IMG]
[B]Figure 2[/B]
However, in order to make this work, you need to add those addresses to the definition of the ISA Firewall Network. In this example, the definition of the default Internal Network would include the addresses [B]10.0.0.0-10.0.0.255[/B] and [B]192.168.1.0-192.168.1.255[/B]. All of these IP addresses are part of the default Internal Network and reach the ISA firewall through the same network interface card.
[IMG]http://www.isaserver.org/img/upl/image0061229419308256.JPG[/IMG]
[B]Figure 3[/B]
The reason we need to include all the addresses that are behind a specific NIC on the firewall is that if there is a host that tries to connect through the ISA firewall on that NIC from a source IP address that is not part of that ISA Firewall Network, the connection request will be dropped as a spoof attempt. The ISA or TMG firewall sees the connection attempt as a spoof because the IP address is not part of the definition of that ISA Firewall Network.
For example, check out the figure below. We have defined the default Internal Network in this example as all IP addresses in the [B]10.0.0.0/24[/B] and [B]192.168.1.0/24[/B] ranges (note that I have included all the addresses in each network ID – that is not a requirement. I could have included only a subset of those IP addresses if I wanted to). What if a host with the IP address [B]172.16.0.2[/B] tried to connect to the ISA Firewall through the NIC that represents the “root” of the default Internal Network?
The connection attempt would fail. The reason why it would fail is that [B]172.16.0.2[/B] is not part of the definition of the default Internal Network in this example. Since the ISA Firewall does not recognize this source IP address as part of the default Internal Network, it will not allow the connection through the NIC that defines the “root” of the default Internal Network. It will call out this connection as a [I]spoof[/I] attempt. All spoof attempts are blocked by the firewall.
[IMG]http://www.isaserver.org/img/upl/image0081229419308272.JPG[/IMG]
[B]Figure 4[/B]
What if you wanted to allow connections from that host at [B]172.16.0.2[/B]? It is a simple matter of adding that IP address to the definition of the ISA Firewall Network that this host uses to connect to and through the ISA firewall. In this case, you could add just that IP address, or if you have other hosts on that network ID, you could add the IP addresses of those hosts, or you could add all the addresses in that network ID.
You define that addresses that belong to a specific ISA Firewall network in the [B]Properties[/B] dialog box for that Network. In the figure below, you can see the addresses tab for the default [B]Internal[/B] Network. This default Internal ISA Firewall Network includes all addresses on the network ID [B]192.168.1.0/24[/B].
[IMG]http://www.isaserver.org/img/upl/image0101229419506147.jpg[/IMG]
[B]Figure 5[/B]
You can create multiple ISA Firewall Networks on a single ISA Firewall. For example, suppose you wanted to create an ISA Firewall Network for wireless guest computers to connect to the Internet. In this case, you would add a third NIC to the ISA firewall (the other two interfaces are for the external interface and the internal interface). The third NIC would become the “root” of a new ISA Firewall Network. You would then assign addresses to that ISA Firewall Network. Each NIC on the ISA firewall needs to be on a different network ID, so after installing the third NIC, we assign it an IP address on a network ID that is different than the other two NICs. Then we assign IP addresses for the new ISA Firewall Network. In the figure below, you can see that all addresses on network ID [B]192.168.0.0/24[/B] are part of the [B]Guest[/B] ISA Firewall Network.
[IMG]http://www.isaserver.org/img/upl/image0121229419506162.jpg[/IMG]
[B]Figure 6[/B]
It is important to remember that an IP address can participate on a single ISA Firewall Network. You can not assign the same IP address to two different ISA Firewall Networks. If you do, you will receive an error message.
Out of the box, the ISA or TMG firewall will have the following Networks defined:

[LIST][*][B]The default External Network[/B] – the default External Network is defined by all IP addresses that are used by any other ISA Firewall Network. Any address that is not used by any other ISA Firewall Network will automatically be included as part of the default External Network. The NIC that defines the default External Network is usually the NIC with the default gateway bound to it. ISA and TMG MBE firewalls support a single default gateway[*][B]The default Internal Network[/B] – this is the network you define during setup that represents your primary internal network. You can have multiple internal networks if you like, but there is only one default Internal Network which you set up during installation of the ISA firewall. The default Internal Network typically contains your key infrastructure services, such as DNS, DHCP and Active Directory domain services. The default Internal Network is important because much of the ISA and TMG firewall’s System Policy is configured to access resources on the default Internal Network[*][B]The Local Host Network –[/B] The Local Host Network is defined by the IP addresses bound to all NICs on the ISA or TMG firewall. For example, if the firewall had two interfaces, one with IP address 2.2.2.2 bound to it and the other with 10.0.0.1 bound to it, then IP addresses 2.2.2.2 and 10.0.0.1 are members of the Local Host Network. Note that this breaks one of the rules of ISA/TMG Networks – in that these IP addresses are also members of the Networks to which those NICs are connected. The 2.2.2.2 is likely a member of the default External Network and the 10.0.0.1 is a member of the default Internet Network.[*][B]VPN Clients Network – [/B]The VPN Clients Network contains the IP addresses of connected VPN clients. There are two ways to assign IP addresses to VPN clients: using a static address pool and using DHCP. If you assign IP addresses to VPN clients using a static address pool, then you must remove those IP addresses from any other Network that might contain them. For example, if you want to assign on-subnet addresses to VPN clients (such as 192.168.1.200-192.168.1.225/24 when the internal interface is on 192.168.1.1/24), you must remove those addresses from the definition of the on-subnet network.
In contrast, if you want to use DHCP to assign IP addresses to VPN clients, then you do not have to remove those addresses from the definition of any other Network that might also be using those addresses. It makes sense, since when you use DHCP to assign these addresses; you know that no other host should be able to use the same IP address on any other Network. In contrast, if you assign static addresses to VPN clients, you do not know for sure that there might be an error that would lead you to use the same addresses on another Network. Addresses are automatically added and removed from the VPN clients Network when they are used and released by the VPN clients. Note that this represents a second exception to our rule that an IP address can belong to a single Network – since you use DHCP to assign IP addresses to VPN clients, those addresses can belong to another ISA/TMG Firewall Network.[*][B]Quarantined VPN Clients Network –[/B] The Quarantined VPN Clients Network contains the IP addresses of VPN clients that have not yet passed VPN quarantine control. This is configured as a separate Network from the VPN Clients Network because you might want to create Firewall Rules that allow quarantined VPN clients access to resources on a Protected Network (a Protected Network is any ISA/TMG Network that isn’t the default External Network) or even on the Internet so that they can remediate themselves. IP addresses are automatically moved from the Quarantined VPN Clients Network to the VPN Clients Network when the VPN client passes quarantine control checks.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0141229419506178.jpg[/IMG]
[B]Figure 7[/B]
Summing up what we know at this point:

[LIST][*]ISA/TMG Firewall Networks are used for spoof detection. If a source IP address arrives at an interface that is a root of an ISA Firewall Network that isn’t an IP address defined for that Network, then the connection attempt is dropped as a spoofed connection attempt[*]An IP address can be assigned to a single ISA/TMG Firewall Network. The only exceptions to this rule are seen with the Local Host Network and the VPN Clients and Quarantined VPN Clients Networks when you use DHCP to assign addresses to VPN clients.[*]An ISA/TMG Firewall Network can contain IP addresses from multiple network IDs. What all these IP addresses have in common is that if they need to connect to and through the ISA or TMG firewall through the same NIC[/LIST]
ISA/TMG Firewall Networks also are used to do one more important task: define whether connections are routed or NATed from the systems on a particular Network to another Network. In order to hosts on a Network to communicate with hosts on another Network, the two Networks must be connected using a Network Rule. The Network Rule accomplishes two things:

[LIST][*]Enables communications between the two ISA/TMG Firewall Networks[*]Sets a routing relationship between the two Networks[/LIST]
I’ll go into more details on Network Rules and connecting Networks to one another in the second part of this series on ISA/TMG firewall networking.
[B]Summary[/B]

In this article, we went over what ISA/TMG firewall Networks are about and how the firewall uses these networks to perform several key functions. We saw that an IP address can belong to only a single Network, with the exception of the Local Host Network and the VPN Clients and Quarantined VPN Clients Networks. We then finished off with a brief overview of the default ISA/TMG Firewall Networks. Next week I will continue the story by showing you how ISA/TMG Networks are used to connect hosts on one Network to another, and how Networks are used to define a route relationship between source and destination. See you then! –Tom.


[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Overview-ISA-TMG-Networking-ISA-Networking-Case-Study-Part2.html[/CODE]

[SIZE=3][B]PART-2[/B][/SIZE]


Understanding the concept of Network Rules

[B]Introduction[/B]

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 [URL="http://isaserver.org/tutorials/Overview-ISA-TMG-Networking-ISA-Networking-Case-Study-Part1.html"]here[/URL].
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.
[B]Note:
[/B]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 [I]not[/I] 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.
[IMG]http://www.isaserver.org/img/upl/image0021231445932143.jpg[/IMG]
[B]Figure 1[/B]
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.
[B]Network Rule Examples[/B]

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.
[IMG]http://www.isaserver.org/img/upl/image0041231446505393.JPG[/IMG]
[B]Figure 2[/B]
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:

[LIST][*]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[/LIST]
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.
[IMG]http://www.isaserver.org/img/upl/image0061231446505393.JPG[/IMG]
[B]Figure 3[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0081231446505393.JPG[/IMG]
[B]Figure 4[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0101231446505408.JPG[/IMG]
[B]Figure 5[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0121231446646377.JPG[/IMG]
[B]Figure 6[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0141231446646377.JPG[/IMG]
[B]Figure 7[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0161231446646393.JPG[/IMG]
[B]Figure 8[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0181231446646393.JPG[/IMG]
[B]Figure 9[/B]
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.
[IMG]http://www.isaserver.org/img/upl/image0201231446646455.JPG[/IMG]
[B]Figure 10[/B]
[B]Summary[/B]

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.

[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Overview-ISA-TMG-Networking-ISA-Networking-Case-Study-Part3.html[/CODE]

[SIZE=3][B]PART-3[/B][/SIZE]


Case study: Migrating a unihomed ISA 2000 firewall configuration to a multihomed ISA 2006 firewall configuration

[B]Introduction[/B]

In the first two parts of this series on ISA and TMG networking, I discussed the concepts of ISA/TMG Firewall Networks and Network Rules. In those articles I tried to make it clear that you need to have a good understanding of how the ISA/TMG firewall sees the networked world before you can get the most out of your firewall configuration.
Now that you have a good understanding of ISA/TMG Firewall Networks and Network Rules, let us take a look at a case study. In this case study the client wanted to migrate from ISA 2000 to ISA 2006. As you might know, there is no direct upgrade path from ISA 2000 to ISA 2006. I do not consider this a major problem (in most cases) because the networking model used by ISA 2004 and ISA 2006 firewalls is completely different than that used in ISA 2000. It is better to start over and determine what the requirements are, and see how the new network model and new features included with the newer firewall version can help meet and optimize those requirements.
The client was using the ISA 2000 firewall for Web Publishing Rules only. It was not used for outbound access in any way. Its only duty was to perform reverse Web proxy for a number of applications hosted on an internal Web server. The client did use the ISA 2000 firewall to route requests to different Web sites based on the path in the request. Because of this, internal clients needed to connect to the Internal Web sites through the ISA firewall.
[B]Current Infrastructure: Unihomed ISA Firewall on Internal Subnet[/B]

Figure 1 shows the old network configuration that’s relevant to our ISA firewall design. As you can see, there is a front end ASA gateway connecting the customer’s network to the Internet. The ASA gateway is the device that enables all inbound and outbound access into and out of the network.
There was a core router that routes to a number of internal network IDs. There is a unihomed ISA firewall on one of these network IDs. Since the ISA 2000 firewall is unihomed, all networks are considered internal. However, this observation is somewhat moot since the ISA 2000 firewall didn’t see network world in terms of ISA Firewall Networks. The default gateway for the old ISA 2000 firewall is local IP address on the LAN router.
[IMG]http://www.isaserver.org/img/upl/image0021232441721357.JPG[/IMG]
[B]Figure 1[/B]
Figure 2 shows the old traffic path used by internal clients when they tried to connect to the company’s Web sites. When planning out ISA or TMG firewall deployments, it's critically important that you understand the current network infrastructure and the request/response paths used by both internal and external clients to reach those resources. The old request/response path for internal clients can be described in the following steps:

[LIST=1][*]Client on one of the internal subnets sends a connection request to the unihomed ISA firewall. This request must cross network IDs and thus packets must be sent to the core router for routing.[*]The core router forwards the packets to the ISA 2000 firewall.[*]The ISA firewall proxies the request to the Web site, which is on the same network ID as the ISA firewall.[*]The Web site responds to the ISA firewall’s request for information.[*]The ISA firewall forwards the response to the internal client that made the request. The request must be forwarded to a different network ID than where the ISA firewall exists, so response packets are sent to the ISA firewall’s default gateway, which is the core router.[*]The core router forwards the response to the internal client that made the request.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0041232441721388.JPG[/IMG]
[B]Figure 2[/B]
After understanding how internal clients reached the Web sites through the unihomed ISA 2000 firewall, the next step was to figure out how external clients reached the Web sites. Figure 3 shows the request/response path:

[LIST=1][*]An external client resolves the name of the Web site to an IP address on the external interface of the ASA gateway.[*]The ASA gateway does reverse NAT to forward the request to the unihomed ISA 2000 firewall. In order to reach the remote subnet on which the ISA firewall exists, the ASA gateway forwards the packets to the core router’s local IP address.[*]The core router forwards the packets to the ISA firewall.[*]The ISA firewall does reverse Web proxy and forwards the request to the Web site.[*]The Web site sends its response to the ISA firewall.[*]The ISA firewall sends its response to the client that made the request. Since the source IP address is an Internet IP address, the ISA firewall sends the request through it’s default gateway, which is the local IP address on the core router.[*]The core router uses the ASA gateway as its default gateway, and forwards the packets to the ASA.[*]The ASA forwards the packets to the client that made the initial request for the Web content.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0061232441721419.JPG[/IMG]
[B]Figure 3[/B]
Now that we have a good understanding of the request/response paths for connections to the ISA firewall for Web content, we can now think about how to redesign the configuration so as to provide a much higher level of security using the new networking model included with the ISA 2006 firewall.
[B]New Network Configuration: ISA Firewall as Inline Network Security Device[/B]

We decided to increase network security by changing from a unihomed ISA firewall configuration to a dual homed, inline network device configuration. When the ISA firewall is deployed in this way, attackers would not be able to bypass the firewall to obtain content on the internal Web servers. In addition, this configuration enables the ISA firewall to shore up the security weaknesses inherent in the ASA gateway, thus providing a dual layer of protection for both inbound and outbound access. Our initial design did not include outbound access control, but it would be something to consider in the future. For now, we will focus only on using the ISA firewall for reverse proxy.
As you know now, ISA and TMG firewalls need to have Networks defined in order to allow traffic to cross them. In addition to defining these Firewall Networks, we need to configure Network Rules to connect the Firewall Networks.
In figure 4 you see how we deployed the new ISA firewall. First, the ISA firewall was placed behind the ASA gateway and it uses the LAN interface of the ASA gateway as the ISA firewall’s default gateway. The other NIC on the ISA firewall was connected to the default Internal Network. The default Internal Network is defined by all IP addresses located behind the internal interface of the ISA firewall. In this case, since there were multiple internal subnets behind the ISA firewall, we had to add all of these IP addresses to the definition of the default Internal Network.
In addition, we had to make sure that the ISA firewall was configured with routing table entries that let the firewall know to use the core router to forward connections to different network IDs within the default Internal Network. We needed to do this because the ISA firewall’s default gateway was the LAN interface on the ASA gateway, which represents a departure from the previous ISA firewall’s configuration, where it was using the core router as its default gateway.
We also needed to configure an ISA Firewall Network for the DMZ segment between the ISA firewall’s external interface and the LAN interface on the ASA gateway. The reason for this was that they were currently using the ASA at their VPN gateway. External VPN clients connect to the ASA and need access to content behind the ISA firewall. After creating the ISA Firewall Network for the DMZ, we set a Network Rule to Route connections between the DMZ and default Internal Network. The ASA had to be configured to inform the VPN clients to use the ISA firewall’s external interface as the gateway address for all the internal network IDs.
The other Network Rule applying to this configuration is one enabling traffic between the default Internal Network and the default External Network. This Network Rule set a NAT relationship between the default Internal and default External Networks.
[IMG]http://www.isaserver.org/img/upl/image0081232441721419.JPG[/IMG]
[B]Figure 4[/B]
Figure 5 gives you a look at the request and response traffic between an external client and the Web servers that the new ISA firewall configuration will provide access to:

[LIST=1][*]The external client resolves the name of the Web site to an IP address on the external interface of the ASA gateway that will perform reverse NAT on the connection.[*]The ASA gateway forwards the packets to the external interface of the ISA firewall.[*]The ISA firewall needs to forward the request to the Web server on a remote subnet. In order to do this, it forwards the packets to the local interface on the core router.[*]The core router forwards the packets to the Web server.[*]The Web server responds to the request. Since the request appears to come from the IP address of the ISA firewall (the default setting for Web Publishing Rules), it sends its response through its gateway address, which is the local address on the core router.[*]The router forwards the packets to the internal interface of the ISA firewall.[*]The ISA firewall returns the response to the requesting client through the ASA gateway.[*]The ASA gateway forwards the packets from the ISA firewall to the requesting client.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0101232441903919.JPG[/IMG]
[B]Figure 5[/B]
The next problem we had to deal with is how internal clients reach the Web servers. Since I prefer to not loop back through the ISA firewall to reach internal resources, I proposed that the following should be the optimal request/response path (figure 6):

[LIST=1][*]The internal client makes a connection request to the Web server that is on a remote network ID. In order to do that, it uses it’s default gateway, which is the local IP address on the LAN router.[*]The router forwards the packets to the Web server.[*]The Web server responds to the client request. Since the request came from a client on a remote subnet, it forwards the response through the local IP address on the core router.[*]The router forwards the response to the requesting client.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0121232441903919.JPG[/IMG]
[B]Figure 6[/B]
While that would have been the optimal solution in terms of performance and simplicity, this “direct access” method would not work in our scenario. The client was using the ISA firewall to do some neat routing tricks based on the path statement in the request, so both internal and external clients need to go through the ISA firewall to make the solution work. This required that the Web Listener used in the Web Publishing Rules be configured to listen on both the internal and external interfaces of the ISA firewall. In addition, a split DNS infrastructure needed to be put into place, so that internal clients resolved the names of the Web sites to the IP address on the internal interface of the ISA firewall.
With those configuration settings in place, the new request/response path would look like this:

[LIST=1][*]The internal client makes a request for the Web site. The site name resolves to the IP address on the internal interface of the ISA firewall. Since the client is on a subnet remote from the internal interface of the ISA firewall, the request is forwarded to the client’s default gateway, which is the local IP address on the core router.[*]The core router forwards the packets to the IP address on the internal interface of the ISA firewall.[*]The ISA firewall reverse proxies the request to the Web site on a remote subnet. To do this, the ISA firewall sends the packets through the core router to reach the remote subnet on which the Web server is located.[*]The router forwards the packets to the Web server.[*]The Web server returns the response to the source IP address of the request, which is the internal IP address on the ISA firewall. In order to reach this IP address on a remote subnet, the Web server sends the packets to the local interface of the core router.[*]The core router forwards the packets to the ISA firewall’s internal interface.[*]The ISA firewall sends the response to the client that made the original request. In order to reach the client on the remote subnet, the ISA firewalls sends the packets to the local address on the core router.[*]The router sends the packets to the client that made the original request.[/LIST]
[IMG]http://www.isaserver.org/img/upl/image0141232441903935.JPG[/IMG]
[B]Figure 7[/B]
[B]Summary[/B]

In this last article of our three part series on how the ISA and TMG firewalls see the network, I went over a case study were we migrated a unihomed ISA 2000 firewall configuration to a multihomed ISA 2006 firewall configuration. In order to make the migration a success, we needed to understand how ISA/TMG Firewall Networks work and how to configure Network Rules to connect those Networks. We needed to make sure that all the appropriate addresses were configured in the default Internal Network, and we also created another ISA Firewall Network to support VPN clients terminating on the ASA gateway in front of the ISA firewall. Finally, a detailed understanding of the request/response paths between clients and published servers was critical to making the solution work.
Since we have spent so much time on network designs the last few weeks, let us take advantage of this momentum and examine some network designs for unihomed ISA firewalls. While concepts of ISA Firewall Networks and Network Rules do not apply to unihomed ISA Firewalls, there are still some routing options, as we can take advantage of Web Routing Rules to do some neat things work unihomed ISA firewalls. See you then! –Tom.

[/LEFT]