Firewall Kernel Mode Tool integrated into Forefront TMG 2010

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall

There is a pretty good 3 part tutorial over on ISA Server.org by Deb Shinder on setting up an Email Hygiene solution on the new TMG Firewall.  This is a powerful solution but care must be taken to install things in the right order.  The tutorial provides step by step instructions with screen shots.

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall – Part 1: Installation.

Installing and Configuring the E-mail Hygiene Solution on the TMG 2010 Firewall – Part 2: E-Mail Policy.

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall – Part 3: Configuring AntiSpam Policy.

Forefront TMG 2010 Email Protection Updates

^{View article...}

Forefront TMG 2010 Web Protection Services Licensing

Introduction

Forefront TMG 2010 adds two new subscription-based features, known collectively as Forefront TMG Web Protection Services (WPS). These features include URL Filtering (URLF) and Anti-Malware or Enhanced Malware Protection (AM or EMP). One thing that makes these features unique within Forefront TMG is that they are licensed separately from Forefront TMG itself. This blog will discuss the various licensing and purchasing options available for URLF and EMP subscriptions and guide you through managing the license details in Forefront TMG management.

WPS Purchasing and Pricing

The first thing most people want to know is “How do I get a Forefront TMG WPS license and how much does it cost?”

Forefront TMG WPS is subscription product licensed per user or per device.  This subscription is only offered through Microsoft Volume Licensing programs, and must be purchased separately from Forefront TMG 2010. Forefront TMG WPS is included in Forefront Protection Suite and ECAL.  You can find information on purchasing Forefront TMG WPS through Microsoft or a Microsoft partner at http://www.microsoft.com/forefront/threat-management-gateway/en/us/purchase.aspx.

The Forefront TMG WPS pricing structure is outlined in http://www.microsoft.com/forefront/threat-management-gateway/en/us/pricing-licensing.aspx.

Verifying the Evaluation License

You may want to take advantage of Forefront TMG WPS while you wait for your license to arrive; or perhaps you want to give WPS a test drive before you decide whether you want to purchase a license. Regardless, TMG provides a free 120-day trial subscription that goes into effect as soon as you deploy Forefront TMG 2010.

Using the Getting Started Wizard (GSW)

The Getting Started Wizard (GSW) provides one way to configure these options. During this process, you can choose to enable HTTPS Inspection, URLF and EMP as well as whether to use the evaluation license (selected by default). The following steps show you where you make these choices in the GSW.

Note: if the TMG computer is a member of an array, the GSW is not available. In this case, you must use the Without the GSW steps

View article...

Still confused about what Direct Access really is and what it can mean for your business?  Bookmark the DirectAccess FAQ for answers to many of your DirectAccess questions.  Learn how your users can be seamlessly and securely connected to your network any time they have an internet connection.  Keep your users up to date with security and system health policies using DirectAccess. 

Announcing the Forefront TMG Best Practices Analyzer Version 8!  This announcement discusses new features and functions found in the latest release of the Best Practices Analyzer tool, including URL Filtering, ISP Redundancy, HTTPS Inspection, Anti-Malware protection and much more!   

Forefront TMG Case Studies – Many of our customers will wait a while and look to see how a software product performs in the real world before making the decision to adopt a new technology.  The same goes for the Microsoft Forefront TMG product, the successor to the popular and proven Microsoft ISA technology.  Customers want to know why TMG is being adopted, why they should change from their current ISA platform, and what benefits they will realize when they decide to make the move.  A great way to answer those questions is through real world case studies such as those found here where customer testimonials can help illustrate some of the benefits found in Microsoft TMG. 

Site Search

Advanced Search

Web security and Web filtering for ISA Server
Monitor, control and protect your ISA Server users with filtering policies, real-time monitoring and multiple virus scanning engines
Learn more and download 30-day trial

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

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

• Published: Jan 20, 2009
• Updated: Jan 20, 2009
• Section: Tutorials :: Configuration - General
• Author: Thomas Shinder

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

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)

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:

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)

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!

• Real-Time Article Update (click for sample)
• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)

Latest articles by Thomas Shinder

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)
• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
• ISA Firewall Web Caching Capabilities
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 2)
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 1)

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

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!

• Real-Time Article Update (click for sample)
• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)

Latest articles by Thomas Shinder

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
• ISA Firewall Web Caching Capabilities
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 2)
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 1)
• X-Forwarded-For and the ISA Firewall: Track your Originating Client through a Web-proxy Chain and on Your IIS

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

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

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

• Published: Dec 16, 2008
• Updated: Dec 16, 2008

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.

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.

ISA/TMG Firewall Networks

NOTE:
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 Network network object. The Network network object defines traffic that moves through the firewall. All traffic that moves to or through 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 through the firewall. However, there are times when traffic with the same source and destination Network can bounce off 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 10.0.0.1 and the client behind that interface has IP address 10.0.0.2. 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.

Figure 1

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.

Figure 2

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 10.0.0.0-10.0.0.255 and 192.168.1.0-192.168.1.255. All of these IP addresses are part of the default Internal Network and reach the ISA firewall through the same network interface card.

Figure 3

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 10.0.0.0/24 and 192.168.1.0/24 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 172.16.0.2 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 172.16.0.2 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 spoof attempt. All spoof attempts are blocked by the firewall.

Figure 4

What if you wanted to allow connections from that host at 172.16.0.2? 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 Properties dialog box for that Network. In the figure below, you can see the addresses tab for the default Internal Network. This default Internal ISA Firewall Network includes all addresses on the network ID 192.168.1.0/24.

Figure 5

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 192.168.0.0/24 are part of the Guest ISA Firewall Network.

Figure 6

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:

• The default External Network – 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
• The default Internal Network – 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
• The Local Host Network – 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.
• VPN Clients Network – 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.
• Quarantined VPN Clients Network – 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.

Figure 7

Summing up what we know at this point:

• 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

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:

• Enables communications between the two ISA/TMG Firewall Networks
• Sets a routing relationship between the two Networks

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.

Summary

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.

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!

• Real-Time Article Update (click for sample)
• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)

Latest articles by Thomas Shinder

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)
• ISA Firewall Web Caching Capabilities
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 2)
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 1)
• X-Forwarded-For and the ISA Firewall: Track your Originating Client through a Web-proxy Chain and on Your IIS

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

How to migrate Microsoft ISA Server 2006 to Microsoft Forefront TMG

ISA Server 2006: Migrating to Forefront Threat Management Gateway.

• Published: Nov 25, 2008
• Updated: Nov 25, 2008
• Section: Tutorials :: Configuration - General
• Author: Marc Grote

Introduction

Microsoft Forefront TMG (Threat Management Gateway) is the upcoming successor of ISA Server 2006 and will be available in 2009. This article is based on a beta version of Microsoft Forefront TMG. If you want to evaluate Forefront TMG, a public beta is available at the following website: Forefront TMG. If you want to have a look at a special version of Microsoft Forefront TMG which is already RTM, you should evaluate Microsoft Windows Essential Business Server 2008 which contains Forefront Threat Management Gateway, Medium Business Edition. But keep in mind that this is not the same version of TMG which Microsoft will publish in 2009 as a standalone product.

See the full article at the source.

Source: How to migrate Microsoft ISA Server 2006 to Microsoft Forefront TMG

Thomas Shinder Blog RSS

All Blogs  »  Thomas Shinder Blog  »  News ISA Central  »  Blog article: Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

From the site:

“In the past, ISA has had very limited or no support on Microsoft’s virtualization platform.  Now, ISA and Forefront Threat Management Gateway (TMG) is supported .  I met up with Jim Harrison to get some guidance on what you need to think about when you virtualize your ISA/TMG servers.  We quickly dive into a whiteboard session on the various ways you can configure Hyper-V / virtual server to work with ISA/TMG and dig into the advantages and disadvantages of each network configuration such as:

• Performance
• Management
• Administration
• Security

Some other things we talk about:

• Why placing TMG on the parent is a bad idea and how you should configure the parent partition
• Configuration options of the actual ISA/TMG server
• Failover, Clustering, and Quick Migration with ISA / TMG in a virtual environment
• Configuration changes you should make for any host which faces the Internet

View the security considerations for virtualized ISA / TMG deployments guide / whitepaper Jim wrote.

See KB article 957006 which states ISA (and other) products are officially supported on Hyper-V.”

=====================================

Head on over to http://edge.technet.com/Media/Virtualize-your-ISA-...rvers/ to watch and listen to Jim Harrison’s great presentation on deploying an ISA or TMG firewall in a virtualized environment. You’ll be glad you did!

HTH,

Tom

Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com
PROWESS CONSULTING documentation | integration | virtualization
Email: tshinder@isaserver.org
MVP — Forefront Edge Security (ISA/TMG/IAG)

This entry was posted on Sunday, October 12th, 2008 at 9:54 am and is filed under News, ISA Central. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Thomas Shinder Blog » Blog Archive » Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

Announcing: Forefront Threat Management Gateway, Medium Business Edition

I am pleased to announce that the first version of the new Forefront Threat Management Gateway (TMG) has been released to manufacturing as part of the Windows Essential Business Server 2008 (EBS) release. As I first blogged in April of this year, Forefront TMG is a new era for the ISA Server product line. It is taking us and our customers into new and innovative protection directions based on the ever-increasing threats we are seeing on the Internet today.

Forefront TMG, Medium Business Edition is fully integrated in Windows Essential Business Server and installed by default. One of the unique capabilities of this edition is the simplified setup and configuration – without taking away the ability for customers or value added service providers to provide the customization or control they may require for their specific environments. We took a specific approach in this release by asking the administrator what he/she wants to achieve, not how to do it. The end result is a server pre-configured with best practices for the most common security and access needs including Internet access, remote access and common firewall rules.

Not only does Forefront TMG include a fully featured and highly rated corporate firewall capability, but it adds a Unified Threat Management (UTM) capability to the EBS installation. It truly provides a comprehensive, all-in-one integrated edge security solution, for both the headquarters and the branch offices. The real value comes through the tight integration of the different UTM components, as well as with the other applications and solutions encompassing EBS. The integrated anti-virus subscription services provide administrative relief to IT professionals from having to constantly monitor the security threats and changing edge policies. The “Am I Secure?” page provides an easy, at a glance view of the security state and statistics of the system avoiding the need for complex understanding and expertise to provide protection for the business.

As our software, hardware and appliance partners announce exciting value–add offerings, I will keep the community informed. In addition, I will be announcing future details around the public beta for the next edition of TMG later this year on this blog. I think you will be excited and surprised and certainly well worth the wait when we announce. Stay tuned to this channel for continual updates!

David B. Cross

Product Unit Manager

Published Tuesday, September 16, 2008 1:13 PM by isablog

Forefront TMG (ISA Server) Product Team Blog : Announcing: Forefront Threat Management Gateway, Medium Business Edition

Server Publishing with ISA Server 2004/2006 and Route Relationship Between Networks

Suppose you have the following scenario:

You are running ISA Server in 3-Leg configuration with a route relationship between the Internal and Perimeter networks. There's a FTP Server and some Web Servers operating in your Perimeter network.

ISA IP-Addresses:

Internal 172.118.115.15

Perimeter 39.1.1.15

External 192.168.101.15

FTP Server Address is 39.1.1.5 connected to Perimeter network

You have already published some Web Servers connected to your Perimeter network, and made them available to External and Internal Users. Now you want to publish a Non-Web Server e.g. the FTP Server connected to the Perimeter network to the Users in the External and Internal networks. You want to use the ISA IP-Addresses for this publishing scenario.

To do so you open the ISA MMC right-click Firewall Policy and Select New ->'Non-Web Server Protocol publishing rule'. You Enter a Name for the rule e.g. "Publish Perimeter FTP Server to Internal and External", in the Next Window you enter the IP Address of the Server, e.g. 39.1.1.5, next you select the FTP-Server Protocol. Then you select on which networks and which IP-Addresses the ISA Server will listen for requests intended for the published FTP Server.

On the Next Page you Finish the Wizard and Apply the changes.

That's easy, isn't it?

Now you want to verify the access to the FTP Server.

You first check the access from External to IP 192.168.101.15, works fine.

Next you want to access the Server from your Internal network using IP 172.118.115.15... it doesn't work.

But why? You start troubleshooting, looking at the ISA Live Logging, and realize, that no ISA rule matches the requests and therefore the request is denied.

On the ISA Server start a command window (Start, Run, cmd), and check if there is a socket Listening to Port 21 using the command netstat -an | findstr 21

The Output shows, that there actually is a Listening socket for the configured External IP, but no socket for your Internal IP.

ISA Server provides a tool called fwengmon to analyze and troubleshoot firewall connectivity issues by monitoring ISA Server in kernel-mode driver (fweng.sys) (ISA 2006: http://www.microsoft.com/downloads/details.aspx?familyid=01fc5551-5d44-4a99-966a-bd86caeb43d7 or ISA 2004: http://www.microsoft.com/downloads/details.aspx?FamilyID=F3306399-D4F9-4989-865E-C61F8293C330).

You execute fwengmon.exe with the /C parameter to check the created objects and receive output similar to this:

The output shows, that ISA has created one socket for 39.1.1.5:21 (FTP Server IP) and one for your external IP 192.168.101.15:21, but no socket for your internal IP. This is called ISA 'port stealing' and represents the route relationship for the traffic.

Does ISA simply ignore the complete publishing rule? Why is there no internal socket, and why can ISA Server create sockets for IP Addresses not configured on ISA?

The Answer: ISA will only create sockets and bind them to ISA Servers owned IP-Addresses for Non-Web Server Protocol publishing rules when there is a NAT relationship between those networks.

If ISA recognizes that there is a route relationship between the networks ISA will not create a socket for the Server IP Address you want to publish. Therefore the access will work when you try to directly connect to the Server IP Address 39.1.1.5:21.

!NOTE! The Web Listener used for Web publishing will always include the ISA Web Proxy Filter. Because an application proxy mechanism such as the Web Proxy Filter creates a completely new connection between ISA and the published server, and because the default for Web Publishing rules is to “Use the ISA computer IP address” when creating these connection. Thus, ISA appears to perform NAT on the traffic between the client and server, because it creates sockets for its configured IP Addresses even if there is a route relationship between the networks.

Question - But for all that, is it possible to publish my FTP Server without changing the network relationship between Perimeter and Internal to NAT?

Answer - Yes, you can do this

To solve the issue, you have to create a new network rule.

1. Navigate to Configuration, right-click Networks and select New -> Network Rule.

2. Choose a Name, e.g. "Internal to Perimeter FTP Server"

3. Add the FTP Server to the Sources. Click Add, New/Computer and create a Computer Object for your FTP Server. Then select this Object to add it to the Sources.

4. Add your Internal network to the destinations.

5. Configure a Network Address Translation (NAT) relationship.

6. Finish the Wizard and verify that the new rule order is lower (numerically) than the rule defining the route relationship between Perimeter and Internal. Apply the changes.

7. After the changes have been applied, you can use fwengmon to verify that the socket has been created in Kernel Mode and use netstat -an to check if there is a listening socket.

You can see, that the socket for the 39.1.1.5:21 disappeared and a new socket for 172.118.115.15:21 is created.

8. When you verify the access from your Internal, you'll see, that you now can connect to the 172.118.115.15:21 and that the correct rule is being matched.

Philipp Sand | Support Specialist ISA Server

Published Tuesday, June 24, 2008 12:54 PM by isablog

Forefront TMG (ISA Server) Product Team Blog : Server Publishing with ISA Server 2004/2006 and Route Relationship Between Networks

Sunday, June 08, 2008 5:25 PM yuridio

TMG New Features - Policy Enforcement

1. Introduction

Throughout the years ISA Server suffered many improvements in the way that handles firewall policy, if you remember, on ISA Serve 2000 we have to stop the service so the policy could take effect immediately, which improved a lot on ISA Server 2004. However even with ISA Server 2006 there is still a common complaint from customers, which was: I applied a new ISA Server policy but I see that my user still accessing the web site. He has to close it and open a new connection in order to take effect. The answer up to now was: well, that’s expected in ISA Server. The connection that is already established will not be affect, only the new one. In TMG we have a new feature called Policy Enforcement that can address this need and this post will give you an overview on that.

2. Compliance Enforcement

The key feature of TMG in this area is the fact that it enforces the new policy for compliance purpose. In other words: if the company security policy changes and those changes need to rapidly reflect in the edge then you can just make the changes and re-apply to the TMG Server. In summary, the process works like this:

Figure 1 – Policy Enforcement.

The re-evaluation of the existing HTTP session happens right after the policy takes effect for the first traffic within the session. Therefore you could potentially see an open session for the site that you just prohibited because no traffic was exchange within that session yet.

On step two, when the administrator applies the change, the Saving Configuration Change window shows the following warning about this new feature:

Figure 2 – New configuration change window.

3. Conclusion

This is just one more improvement that you will see in TMG and it is an improvement that bring more control and security enforcement to the network administrator. For more information about policy enforcement review the official TMG documentation at TMG TechNet Library Page.

Filed under: TMG

Yuri Diogenes's Blog : TMG New Features - Policy Enforcement