Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 4)

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

Introduction

In the first three parts of this series on web and server publishing using the TMG firewall, we talked about some general web publishing concepts and definitions and then walked through the TMG firewall’s Web Publishing Wizard. After we completed the Web Publishing Wizard, we created a Web Publishing Rule. In this article, we’ll pick up where we left off and examine the details of the Web Publishing Rule that we created, and also take a look at some of the more advanced options that were not exposed to us when we ran the Web Publishing Rule wizard. Let’s get started.

Web Publishing Rule Properties

When you right click the rule and click Properties, you will see the Properties dialog box for the rule and the default tab is the General tab. There’s nothing very interesting on the General tab other than the name of the rule. Note, however, that you can use that tab to change the name of the rule, so that’s something to keep in mind.

Action Tab

Click on the Action tab and you’ll see some things that you can change here that weren’t available in the Web Publishing Rule Wizard. On the Action tab, you can change the rule from an Allow rule to a Deny rule and vice versa. Notice here that if you change the rule to a Deny rule, you will be given the option to redirect the connection to a different URL. One scenario in which you might want to take advantage of this is to create a Deny rule for an HTTP connection and then redirect the connection to an HTTPS site with the same URL. We often do that for OWA connections, since users don’t want to remember to use HTTPS instead of HTTP. To make it easier for them, we just create the Deny rule for the HTTP connection and automatically send them to the HTTPS site. This makes everyone happy.

There is another option here that you might find helpful. Notice the checkbox for the Log requests matching this rule option. Logging is one of the activities on the TMG firewall that takes a lot of disk space and processing power, so if you can reduce the amount of logging you do, you will be able to squeeze more performance from your firewall. You can uncheck the box to remove the logging for the rule, which is something that you might do if you are using Deny rules that forward to another site. There might be other scenarios where you don’t want to log connections, too, so keep this option in mind when you’re doing your performance tuning for your TMG firewall.


Figure 1

From Tab

Now click on the From tab. This is where you configure the locations from which the rule will accept connections. By default, the rule will accept connections from hosts that are located on any network. However, you can change that if you only want users located on only certain networks or even IP addresses to connect to the site. This can be useful if you want to publish a web server that only a select number of users will be able to access. In that case, you can create a Computer Group that includes only those particular IP addresses, and allow only those particular users access. You can combine this with authentication to make it even more secure.

The Exceptions option was not available in the Web Publishing Rule Wizard. You can use this option to create exceptions to the list of allowed traffic sources. For example, in the figure below you see Anywhere, which means that the rule allows hosts from anywhere to connect to the site through this rule. However, maybe you have noticed in the log files that an attacker is trying to access the site. How do you block that without limiting others’ access? One thing you can do is identify the network that the attacker is coming from and create a Network object for it, and block that Network using an exception. There are many uses for the exceptions, so keep this option in mind when working with Web Publishing Rules.


Figure 2

To Tab

Next, click on the To tab. There are a number of useful options here. The This rule applies to this published site is the private name of the site on your internal network. In this example, the private name and the public name are the same, which means we have a split DNS infrastructure. You also have the option to enter a name in the Computer name or IP address (required if the internal site name is different or not resolvable) text box if the name of the internal computer is not the same as the one you have in the This rule applies to this published site text box. I find this is most commonly useful when you are publishing SSL sites, where the common/subject name for the published site is different from the name of the computer to which you want to forward the connection.

I initially found the Forward the original host header instead of the actual one (specified in the Internal site name field) to be confusing and many other TMG admins have said the same over the year. What does it mean? Well, by default the TMG firewall will proxy the connection to the published web site using the name you listed in the This rule applies to this published site text box. Remember, the TMG firewall is proxying the connection, which means it actually establishes a new connection to the published web site; it doesn’t forward the client connection, it creates a new one on behalf of the external user. Now, there might be times when you want to preserve the host header that the client sent in its request. In that case, you would put a checkmark in the Forward the original host header instead of the actual one (specified in the Internal site name field) checkbox.

Also included on this tab is an important option that you didn’t have in the Web Publishing Rule Wizard. This option is found in the Proxy requests to published site. There are two choices here:

  • Requests appear to come from the Forefront TMG computer
  • Requests appear to come from the original client

If you choose the Requests appear to come from the Forefront TMG computer option, the source IP address of the packet will be the IP address of the TMG firewall. The specific address that the TMG firewall chooses to include as the source address depends on which internal is closest to the published web server. Whatever IP address is closest to the published web server will be used as the source IP address of the packet that is forwarded to the published web server.

If you choose the Requests appear to come from the original client option, the source IP address forwarded to the published web server will be the actual IP address of the client that sent the request to the TMG firewall.

Which option you should select depends on your routing infrastructure. If your routing infrastructure is designed in a way that makes the TMG firewall the gateway to the Internet, then you can leave the source address as the IP address of the client that made the original request. If your routing infrastructure does not configure the TMG firewall as the Internet gateway (or one path of several to the Internet), then you will want the TMG firewall to replace the source IP address with its own, because it’s very likely (and required) that the web server has a route to the IP address of the TMG firewall (or at least one of the IP addresses assigned to the TMG firewall).

Of course, your routing infrastructure is not the only reason you would want to change the default setting, which is to replace the source IP address with the IP address of the TMG firewall. Another reason would be that you want the web site to have the original IP address of the requesting client in its log files. Sure, the original IP address of the requesting client can be found in the TMG firewall’s log files, but often web site administrators prefer to have those addresses in their own log files. Selecting the Requests appear to come from the original client option will make those web server administrators happy.


Figure 3

Summary

In this article we continued our series on web and server publishing rules that you can configure on the TMG firewall to enable external users (or even internal users in some scenario) to access web and non-servers in a secure fashion. We went over three of the important tabs in the Properties dialog box of the example Web Publishing Rule we created last week. Of particular interest are the abilities to redirect connections using a Deny rule and controlling the source IP address the TMG firewall uses when forwarding connections to the published web server. Next time, we’ll continue our journey by looking at the other options in the Properties dialog box and what you can do with those options and then we’ll dig into the Web Listener and look at how you can create an SSL web listener – something that TMG admins sometimes have trouble doing without some encouragement. See you then! –Deb.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top