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

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

Introduction

In the first eight installments of this series of articles, we focused on the web publishing feature included in the TMG firewall. Web publishing, however, is limited to publishing only HTTP, HTTPS and FTP sites. In contrast, the other way you can make internal servers available to others through TMG is by using the Server Publishing feature. Server publishing enables you to publish any protocol using the built in protocols or you can use protocols that you can create yourself. You can publish simple protocols (those that require a single port to imitate the connection) or complex protocols that require that multiple ports and for which callback are required, such as the RPC protocol.

Examining the differences

A major difference between Web Publishing and Server Publishing is that Web Publishing is more complex. (I can hear you all breathing a sigh of relief: “Does that mean this part of the series won’t be quite as long and drawn out as the first part?”). When a user connects to a web site using Web Publishing, the connection is terminated at the TMG firewall and then the TMG firewall may perform some actions on that request. When the TMG firewall has finished doing whatever it needs to do with the request, it recreates the request, which actually represents a new request, and sends that to the published web server.

In contrast, Server Publishing is more like reverse NAT, where the connection is terminated at the TMG firewall and the only change to the request is the replacement of the source IP address. In fact, you even have the option to not change the source IP address. Most Server Publishing Rules do not perform any kind of application layer inspection. However, there are a few built-in Server Publishing protocols that will do some protocol inspection to make sure that the connection request isn’t corrupt or that someone isn’t trying to do something to compromise your server.

Using Server Publishing for HTTP/HTTPS/FTP

Server Publishing can actually be used instead of Web Publishing for HTTP, HTTPS and FTP connection. However, you will not have all the security features available to you. For example, you cannot perform pre-authentication on incoming connections when you use Server Publishing. Also, SSL bridging is not available. However, some people actually prefer to use Server Publishing over Web Publishing for SSL sites because it is much more simple in some SSL publishing scenarios (such as Microsoft Exchange) than Web Publishing. However, with that simplicity comes a much lower level of security.

In general if you are publishing web sites, you should use Web Publishing Rules because they afford you a much higher level of application layer inspection and authentication and authorization. Having said that, I do have to admit that there have been times when I just wanted something “to just work” and used a Server Publishing Rule instead of a Web Publishing Rule. This mostly happens when I’m trying to publish Exchange Servers. However, sooner or later I get around to fixing the configuration and publishing the services correctly by using a Web Publishing Rule.

Better security for Server Publishing rules

Note that there is nothing to prevent you from getting a higher level of security for your Server Publishing Rules. That is because you can associate any of the server publishing protocols with a filter. The TMG firewall comes with a number of filters out of the box. Most of them are dedicated to just making the protocol work. However, there are some that are dedicated to some security functions related to the protocol.

Creating Server Publishing rules

Let’s begin our discussion of Server Publishing by taking a look at how you create a simple Server Publishing Rule.

You start creating a new Server Publishing Rule by clicking the Tasks Tab in the Task Pane. There you will find an entry for Publish Non-Web Server Protocol, as shown in Figure 1. Click that to start the Server Publishing Rule Wizard.


Figure 1

On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the Server Publishing Rule in the Server Publishing Rule Name text box. In this example, we’ll do an FTP Server Rule and name the rule FTP Server, as shown in Figure 2. Click Next.


Figure 2

On the Select Protocol page, shown in Figure 3, you are offered the option to select the protocol you want to publish. If you click the drop down arrow in the Selected Protocol section, you’ll see a number of protocols that were included right out of the box. Also note that you have these other options:

  • Properties. After you select the protocol you want to publish, you can change the properties of the protocol.
  • Ports. If you select this option, you can change some of the characteristics of the protocol, such as on which port the Server Publishing Rule will listen and to which port it will forward the connection on the published server.
  • New. If you select this option, you can create a new Server Publishing protocol.

We’ll look at how each of these options works when we finish the wizard. Once you understand how the options work, you can then use the Properties, Ports and New options when you are going through the wizard so that you won’t have to go back into the Properties of the Server Publishing Rule to modify it after you have finished creating it.


Figure 3

Another place where you can see all the available Server Publishing Rule protocols is in the Toolbox tab of the Task Pane, which is shown in Figure 4. Here you can see all the available Server publishing protocols and you can see the details of each of them. Just click the protocol that you’re interested in and then click the Edit button. Notice that you can create a new Server Publishing protocol in this section, as well.


Figure 4

On the Network Listener IP Addresses page, you can select which network and which IP addresses you want users to connect to when they make a call to your published server. Typically, this is going to be one or more IP addresses on the External Network. However, there are scenarios where you might want to publish on an IP address that is not on, or is in addition to, the External Network. Such a scenario might be one in which the published server is on a DMZ segment. In that case, you would include the Internal Network (or some internal network) as a network that would be listening for connections that would be subsequently forwarded to the published server in the DMZ segment.

You can get more granular regarding which IP address you want the listener to use by clicking the Address button. This opens the External Network Listener IP Selection dialog box that’s shown in Figure 5, and it provides you with the following options:

  • All IP addresses on the Forefront TMG computer that are on the selected network. Use this option if you want the Server Publishing Rule to listen on all IP addresses assigned to the NIC for the network. If you have multiple IP addresses assigned to that NIC, then all the IP addresses can accept connections for the protocol you select and each of them will forward the connection to the published server.
  • Default IP addresses for network adapters on this network. If Network Load Balancing is enabled for this network, the default virtual IP address will be used. The default IP address is typically the first IP address listed in the IP address list. However, things have changed a bit with the TMG firewall, and it is different from the way the default IP address was defined by the ISA firewall. For more information on how the TMG firewall defines the default IP address, check out this link.
  • Specified IP addresses on the Forefront TMG computer in the selected network. If you select this option, you can choose the specific IP addresses on which you want the TMG firewall to accept connections for the Server Publishing Rule.


Figure 5

On the Completing the New Server Publishing Rule Wizard page, shown in Figure 6, you are provided with a summary of the options you selected for the rule. Notice that the Server Publishing Rule Wizard does not provide a Test button like the one you saw for Web Publishing Rules. Therefore, if you want to test the rule, you’ll need to find a client that can connect to the published server after you have created the rule and saved the configuration to the firewall.


Figure 6

It’s done! Here in Figure 7, you can see the Server Publishing Rule in the firewall policy listing. Don’t forget to click Apply to save the configuration.


Figure 7

Summary

In this article, we began with a short introduction to Server Publishing Rules and discussed the differences between Web Publishing Rules and Server Publishing Rules. We observed that Server Publishing Rules are much less sophisticated than Web Publishing Rules and work more like reverse NAT than like proxy connections. However, we also saw that the TMG firewall will perform a certain level of application layer inspection or at least basic protocol validation if there is a filter associated with the server publishing protocol. After this discussion, we then ran through the Server Publishing Rule Wizard and created a simple Server Publishing Rule for the FTP to protocol. In the next article in this series, we’ll take a look at the details of the Server Publishing Rule and look at some of the options that are available to you, by which you can customize the protocol and some other characteristics of how the Server Publishing Rule works. See you then! –Deb.

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

About The Author

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