TMG Back to Basics – Part 1: Server Publishing Rules

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

 If you would like to revert back to the “Controlling Internet Access: A short Primer on TMG Access Rules” series please go to:

Introduction

If you’re new to the TMG firewall, you might have wondered what Server Publishing Rules are all about. The good news is that Server Publishing Rules are really simple – they are essentially reverse Network Address Translation rules that allow you to reverse NAT for a number of protocols. However, Server Publishing Rules are more than just reverse NAT, because the TMG firewall includes a number of Application Filters (essentially NAT Editors) to support complex protocols, and there are also a number of security related application Filters that improve the security of the reverse NAT.

In contrast to Web Publishing Rules, which can be extraordinarily complex, Server Publishing Rules are typically very simple. Because of their simplicity, some TMG administrators prefer to use Server Publishing Rules over Web Publishing Rules, even though a Web Publishing Rule might be the better decision from a security point of view. For example, publishing Exchange 2010 can be very complex, and while there is a wizard that does part of the work for you, it ignores the auto discovery feature that is so useful. Thus many people will do an SSL Server Publishing Rule to publish Exchange instead of going through the major hassle of trying to Web Publish Exchange.

In fact, because that scenario is so common, in today’s example we’ll create an SSL Server Publishing Rule to show you exactly how it’s done. To begin creating a Server Publishing Rule, click on the Firewall Policy node in the left pane of the console, and then click the Tasks Tab in the Task Pane. On the Task Pane, click the Publish Non-Web Server Protocols link, as shown in Figure 1.


Figure 1

This brings up the Welcome to the New Server Publishing Rule Wizard page, shown in Figure 2. In the Server publishing rule name text box, enter a number for the Server Publishing Rule. In this example, we’ll name the rule Complex SSL Site (we’ll pretend, for purposes of this example, that this is an Exchange CAS server that we’re publishing). Click Next.


Figure 2

On the Select Server page, shown in Figure 3, enter the IP address of the server on the internal network that you want to publish. If you don’t know the IP address, you can click the Browse button.


Figure 3

When you click the Browse button, it will bring up the Find Internal IP Address dialog box that’s shown in Figure 4. Enter the name of the server you want to publish in the Server name text box and click Browse. When the system finds the server, it will list the IP address in the IP addresses list. Click OK after finding the IP address.


Figure 4

After you see the IP address on the Select Server page, shown in Figure 5, click Next.


Figure 5

On the Select Protocol page, as seen in Figure 6, select the protocol you want to allow to be used by the published server. In this example, we want to allow SSL to the published server, so we select the HTTPS Server protocol from the drop down list. Note that when publishing sites using Server Publishing Rules, you use “Server” protocols, such as the HTTPS Server protocol we used in this rule. Click the Properties button.


Figure 6

This brings up the Properties dialog box that’s shown in Figure 7. Click the Parameters tab. Here you can see the port or port ranges that are used by the protocol. When you use the built in protocols, you typically won’t want to change the ports. Here you get information about the primary and secondary connections that are supported by the protocol. You also get information about any Application Filters that are bound to the protocol. In this example, you can see that this server has Bandwidth Splitter installed on it, and the Bandwidth Splitter Application Filter appears in the Application Filters list. Click Cancel to dismiss this dialog box.


Figure 7

Click the Ports button. In the Ports dialog box shown in Figure 8, you can exercise more fine-tuned control over the ports used by the Server Publishing Rule. In the Firewall Ports section, you can use the default port for the protocol, or you can change the port. For example, the default port used by the HTTPS Server protocol is TCP 443. However, if you wanted to use an alternate port, you could select the Publish on this port instead of the default port option and name an alternate port. As long as no other rule or application is listening on that port and IP address, it’ll work fine.

You can also do port redirection if you like. In the Published Server Ports section, you see that the default setting is to Send requests to the default port on the published server. In this example, the HTTPS Server protocol uses the default port of TCP 443 so it would forward the connection to that port on the published server. However, if you wanted to use another port on the published server to accept SSL connections, you can change it to something else, and then select the Send requests to this port on the published server option and enter the alternate port. This is pretty user friendly stuff.

You can also control which source ports are used by the user who wants to connect to the published server. In the Source Ports section, the default setting is Allow traffic from any allowed source port. Since most applications are going to use a dynamically assigned source port, this is generally the best way to go. However, if you want to improve the security for some applications (such as RDP publishing), you could select the Limit access to traffic from this range of source ports and then enter a limited range, and force the RDP client application to use the ports you designate here.


Figure 8

Click Next after selecting the protocol that you want to publish on the Select Protocol page, shown in Figure 9.


Figure 9

Before we move to the next page of the wizard, let’s take a look at the Server Protocols that are available to you “out of the box”. Remember, when you create Server Publishing Rules, you need to use a “Server” protocol. When you click on the Firewall Policy node in the left pane of the console and click the Toolbox tab (you can’t do it right now because you’re in the middle of the wizard) and then click the Server Protocols node, shown in Figure 10, you’ll see a list of Server Protocols that you can use in Server Publishing Rules. This is a pretty comprehensive list! Of course, if the protocol you want to use isn’t in this list, you can always create your own Server Protocol by clicking on the New menu.


Figure 10

Now let’s get back to the wizard. On the Network Listener IP Addresses page that’s shown in Figure 11, select the Network or Networks on which you want to listen for incoming requests. In most instances you’ll want to accept incoming connections from the default External Network, so you’ll put a checkmark in the External checkbox on this page. However, in most cases you don’t want to listen on all the IP addresses on the NIC. If you have more than one IP address bound to the external interface, you should click the Addresses button and select the specific IP address to which you want users to make the connection. If you have a NAT device in front of the TMG firewall, then you should select the IP address to which the NAT device is forwarding the connections when external users are trying to connect to the published server.


Figure 11

Review your settings on the Completing the New Server Publishing Rule Wizard page, shown in Figure 12, and then click Finish.


Figure 12

After you click Finish, you can see the new Server Publishing Rule in the Firewall Policy list, as seen in Figure 13.


Figure 13

Double click on the Server Publishing Rule you just created. There are a couple of tabs worth taking a look at here, as they expose some options that you didn’t have when you went through the wizard. Click on the From tab, shown in Figure 14. Notice on the From tab that This rule applies to traffic from these sources lists Anywhere. In most cases, you’ll want to leave it this way. But what if you have some addresses or networks that you don’t want to have access to the published server through this rule? You can click the Add button in the Exceptions section and enter those addresses. This gives you some measure of access control over which addresses can connect through this Server Publishing Rule.


Figure 14

On the To tab, shown in Figure 15, notice the two options in the Request for the published server section. The default setting is Requests appear to come from the original client. This means that the published server will “see” the actual IP address from which the connection came over the Internet. If you choose this option, the published server will need a route to the Internet and its default gateway must provide access to such a route. If you don’t want to provide the published server a route to the Internet, you can select the Requests appear to come from the Forefront TMG computer. When you select that option, the published server only needs a route that enables it access to the internal IP address of the TMG firewall. However, when you select that option, the source IP address for the incoming connections to the published server will be the IP address on the internal interface of the TMG firewall and that address will appear in the published server’s log files.


Figure 15

Once you’re done, click Apply at the top of the middle pane of the TMG firewall console and save the changes to firewall policy. After that, connections to the published server will be allowed on the protocol you selected for the rule.

Summary

In this article, part of our Back to Basics series for new TMG administrators, we went over the topic of Server Publishing Rules. As you saw, Server Publishing Rules are very simple to put together and allow you to enable reverse NAT to published servers on your intranet. There are a number of Server protocols that you can use to create Server Publishing Rules right out of the box, or you can create your own Server Protocols. Some of the Server Protocols have Application Filters that make the protocol more secure, or that perform some level of protocol validation. You also saw that you could customize the protocol and redirection behavior when configuring the Server Publishing Rule. Have fun with Server Publishing Rules and let me know if you run into any problem with them!

 

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

If you would like to revert back to the “Controlling Internet Access: A short Primer on TMG Access Rules” series please go to:

About The Author

1 thought on “TMG Back to Basics – Part 1: Server Publishing Rules”

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