So today was an interesting / frustrating day depending how you look at it, I spent far to much of the day helping out Nat with a bizarre issue to do with TMG publishing rules. In our case FTP publishing, however we did manage to get to the bottom of it so here are the results for anyone else that might run into the same issue… (If you want the fix with no waffle jump to the end!)

(our error was logged as Event ID 21174 “The server publishing rule xxxx failed because there was no valid network listener. For requests to reach the published server there must be a network relationship between the selected listener networks and the published server. Error location: 325.958.7.0.9193.500”)

Background

In most scenarios with TMG / ISA you have a front firewall of some description and then your TMG at the back end. In this scenario typically when you want to publish a service (lets say FTP) to the internet it’s normally not an issue, you NAT the connection from the internet to an IP on the outside of the TMG and then you create a server publishing rule to pass that back through to the internal server that’s hosting the service, job done.

However in our case we wanted to publish a service on the internal interface of the TMG for something that existed in the DMZ network in front of the TMG. This was a range that wasn’t explicitly defined and so was classed as being in the “external” network range. This might seem like a weird thing to want to do, however there is quite a good reason. In our case there was an isolated “test network” used by the client as a replica of their live kit for testing purposes. In order to ensure total isolation this test network was protected by it’s own Cisco ASA firewall and neither network knew about each other as all traffic in and out was NAT’ed meaning that nothing could talk directly to or from the test network. However we needed a way of gaining access to certain resources in the test network. At first this was fairly straight forward to achieve using RDP over HTTPS (TS / RDS Gateway) and this worked first time perfectly. The trouble started when we tried to add FTP access into the mix.

image

In the diagram each green line represents a separate connection so the client was only talking to the TMG, the TMG talking to the DMZ ASA and the ASA talking to the destination server.

The error

When creating a new server listener you specify the network to listen on & the destination server to pass the traffic to (also don’t forget afterwards to check what source IP TMG sends to the remote server – for us this had to be the TMG’s IP) but when we applied the configuration and tested the traffic from our client wasn’t hitting our publishing rule, it was hitting an access rule lower down the list. Using netstat (“netstat –abn”) we also determined that the TMG server wasn’t listening on our FTP port for incoming connections. After a bit of digging around we spotted the following error in the Windows application event log each time we re-enabled the publishing rule:

image

Event ID 21174 “The server publishing rule xxxx failed because there was no valid network listener. For requests to reach the published server there must be a network relationship between the selected listener networks and the published server. Error location: 325.958.7.0.9193.500”

It’s a bit strange seeing as the destination is in the “external” network range and the source is in “internal” which was already taken care of by the following default network rule in TMG (if you used the getting started topology wizard):

image

We already had a explicit relationship defined between the two networks… and then to add to the mystery this was already good enough for publishing HTTP protocols between the exact same IP’s but apparently TMG handles non-HTTP traffic in a different way (I assume due to it’s built in proxy).

The fix

Well the solution turns out to be a bit weird, you need to create a new network relationship between the destination and source networks. Now thankfully in TMG you can do this just between specific IP’s or computer objects rather than having to choose entire subnets or network ranges. The other thing we discovered is that the direction of the relationship REALLY matters. i.e for server publishing NATing “Internal” to “External” isn’t the same thing as NATing “External” to “Internal”.

So let’s step through creating the network relationship required for successful server publishing:

First start by creating a new network rule

image

Next enter your destination server (i.e the IP of the ASA in my scenario) in the “Traffic Sources” box

image

Then enter the source networks in the “Traffic Destinations” box (i.e the network you are connecting from – this should match what you have defined in “Networks” on your publishing rule)

image

Choose to NAT the traffic

image

And lastly leave the NAT Address as default IP unless you know what your doing

image

Then confirm the settings & apply the configuration

After checking that the new network rule configuration has applied (or just wait 5 minutes) disable and re-enable your non-functional server publishing rule and this time you should see your TMG start to pass traffic through correctly and a quick check of the listening ports will show it waiting for connections on your selected interface.

image

Summary / TLDR

To make TMG publish non-HTTP protocols on any interface other than External then make sure you define a specific NAT network relationship (even if it’s already covered by an existing “external” NAT rule) using the remote server as the “Source” and the listening network as the “Destination”!

I have recreated the error and tested this fix in a similar scenario by publishing an external FTP server from the internal interface of my TMG, same error – same fix.

I’m aware this post is a bit long winded so please feel free to drop me any comments below and I can clarify where things might be ambiguous.

Again thanks to Nat for his patience and perseverance.