Overview of ISA and TMG Networking and ISA Networking Case Study (Part 3)

By /

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

Introduction

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.

Current Infrastructure: Unihomed ISA Firewall on Internal Subnet

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.


Figure 1

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:

  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.
  2. The core router forwards the packets to the ISA 2000 firewall.
  3. The ISA firewall proxies the request to the Web site, which is on the same network ID as the ISA firewall.
  4. The Web site responds to the ISA firewall’s request for information.
  5. 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.
  6. The core router forwards the response to the internal client that made the request.


Figure 2

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:

  1. An external client resolves the name of the Web site to an IP address on the external interface of the ASA gateway.
  2. 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.
  3. The core router forwards the packets to the ISA firewall.
  4. The ISA firewall does reverse Web proxy and forwards the request to the Web site.
  5. The Web site sends its response to the ISA firewall.
  6. 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.
  7. The core router uses the ASA gateway as its default gateway, and forwards the packets to the ASA.
  8. The ASA forwards the packets to the client that made the initial request for the Web content.


Figure 3

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.

New Network Configuration: ISA Firewall as Inline Network Security Device

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.


Figure 4

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:

  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.
  2. The ASA gateway forwards the packets to the external interface of the ISA firewall.
  3. 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.
  4. The core router forwards the packets to the Web server.
  5. 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.
  6. The router forwards the packets to the internal interface of the ISA firewall.
  7. The ISA firewall returns the response to the requesting client through the ASA gateway.
  8. The ASA gateway forwards the packets from the ISA firewall to the requesting client.


Figure 5

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):

  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.
  2. The router forwards the packets to the Web server.
  3. 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.
  4. The router forwards the response to the requesting client.


Figure 6

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:

  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.
  2. The core router forwards the packets to the IP address on the internal interface of the ISA firewall.
  3. 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.
  4. The router forwards the packets to the Web server.
  5. 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.
  6. The core router forwards the packets to the ISA firewall’s internal interface.
  7. 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.
  8. The router sends the packets to the client that made the original request.


Figure 7

Summary

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.

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

About The Author

Tom Shinder is a Program Manager at Microsoft and has two decades of networking and security experience. He has written dozens of books, thousands of articles, and spoken at large industry conferences on the topics of IT infrastructure, Cloud computing, and cybersecurity. In his free time, Tom enjoys participating in equine prediction markets.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top