One of my favorite and most versatile tools in the arsenal is Microsoft Forefront Threat Management Gateway (TMG). Although “ISA” still slips out occasionally, TMG is as ISA was, a firewall, a proxy, a router, and on my short list of solutions to use if traditional methods of routing between networks is not possible, for whatever reason.

Here is a scenario: I have a private L2 network, not reachable from or connected to the corporate network. The private network, unfortunately, uses an IP scheme also in use somewhere on the corporate network. So I cannot simply attach this network to the corporate LAN directly and changing the private network architecture is just not an option right now. Enter the ultimate software network bridge: TMG. But the plot thickens… I have resources on the private side that I want to make available to the corporate network, namely a VDI pool and a Kace web server.

Planning and Design

First and foremost, I need to protect the corporate network. Nothing that goes on in the private network should be able to negatively impact the corporate LAN. This is just a common-sense precaution. With that in mind, the private network will be considered “outside” and firewalled to protect the “inside” LAN. I only have 2 networks in this scenario so a simple perimeter network configuration with 2 interfaces will suffice. My TMG server will be virtual, of course, hosted on an ESXi server with physical connections to both networks. The guest OS will be Server 2008 R2 running TMG 2010, SP1. Because the private network will be considered “the internet”, for all intensive purposes, I will have to reverse publish/ proxy those resources I wish to make available to the internal network. Here is the topology I will be implementing:

This design is typically opposite of what you would normally do with TMG, where you might publish OWA or some other internal resource to the internet. I’ve also used TMG to route specific protocols between otherwise disconnected networks. The end result of this architecture is that users on the LAN side will be able to access the published resources on the “outside”. For this exercise I will be reusing the TMG server’s inside IP address to publish my web server. So users inside will be able to browse to http://10.1.1.50 and be able to view the website hosted on 192.168.1.10.

Setup

All the basic ISA/ TMG setup best practices still apply. Define the networks your internal and external NICs connect to, use a gateway and DNS on only one (the other will be static routed), disable all protocol stack services on the outside interface (NetBIOS, etc), set the NIC binding order properly, etc. These practices are all very well documented so I won’t cover them here. There is also nothing special to configure in the TMG network rules. You don’t need to create a External to Internal route or NAT rule. The magic is all in the publishing rule.

First, create a new Web Site Publishing Rule from within the Firewall Policy tab. Give it a name and set the rule action to Allow. Publish a single web site and decide if you want SSL to protect the server connection between TMG and the web server. For this exercise I will not be using SSL.

Because DNS on the LAN side does not resolve anything in the private network, we need to specify an IP address for the internal web site. Enter the site name, check the box to use an IP address and enter it. We can’t use this site name because it isn’t resolvable but the wizard requires it, we will change it once the setup is complete.

We don’t need to enter a specific path for this website and accept requests for any domain name. Next we need to create a web listener, click New and enter a name.  Choose do not require SSL and select the Internal network to listen for incoming web requests.

Select No Authentication and finish to complete the listener setup. Once complete the listener should look like this:

TMG has the ability to pass authentication requests made by published web servers to clients. In this case we don’t need this so ensure that delegation and direct client authentication are disabled. This rule will apply to all users. Once the base rule is created there are still a few tweaks to be made before it will work as intended.

Open the new rule you just created. On the “To” tab, change the published site entry to the IP address and delete the IP in the second field. Ensure that requests are set to appear to come from TMG.

On the “Public Name” tab, change the rule to apply to “requests for the following sites” and enter TMG’s inside IP address.

Now the secret sauce: Link Translation. Without this, the home page may load but every link a user would click on the website would be directed back to the source web server’s IP address. These requests will fail because there is no routing from the corporate LAN to the private network. Link translation will replace the true source IP address mapping with the TMG server’s IP address. On the Link translation tab, click apply link translation to this rule, then click configure.

The mappings button will show you all translations applied to that rule in a web browser report. At this point, after clicking apply, you should be able to test the rule by clicking the Test Rule button. This will initiate a path ping to ensure the destination is reachable as configured. Before it will take effect, you will need to apply the rule in TMG. Now you can test by accessing the website on the corporate LAN side.

Publishing the VDI host will be similar using standard http/https to access the resources. Link translation will again be the key there to ensure that everything that is published through TMG will appear to be hosted by TMG to the end user.

I’m a big fan of ISA and have been since 2000, yes even 2000. Many things have changed since then and mostly for the better. Layer 7 application filtering is a concept that has been around since the beginning and is one of the reasons ISA is a powerful firewall solution. The management of app filter behavior has gone from front and center to somewhat hidden, hence the purpose of this post. App filters provide the ability to control aspects of specific protocols that pass through the firewall: FTP, HTTP, RPC, SMTP, DNS, etc.

If you enable the FTP and HTTP filters on a general outbound internet access policy, the affects of the filters in default form can be quite limiting, especially for FTP. You can edit the policy’s filter behavior one of two ways: right-click context menu on the policy item, or via the filtering button on the Protocols tab in the policy item itself.

The default mode of the FTP filter is read only so you will be able to log into an external FTP site, execute dir/ls commands but transfers to or from will fail. Uncheck read only from the FTP protocol policy to enable full FTP functionality through the firewall. This behavior can be frustrating to troubleshoot if you don’t know where to look, especially since the configuration of the app filters is not particularly obvious.