The great thing about any new or updated firewall is the coders understand the protocols and processes that little bit more. This means the stuff that worked on the old version might now not work on the new one. This is very much the case on moving from ISA to TMG – especially for FTP.
This has created issues with Active FTP and FTP over HTTP which is why this piece is now here to help others avoid similar learning pains.
Active FTP
TMG blocks Active FTP by default, which is a good thing as Active FTP is bad. Well, RFC 959 doesn’t actually define Active FTP as bad, but the way it works mean the client FTP firewall has to open up a large number of ports and keep track of them inbound from the FTP server. So using Passive FTP means it’s good for the TMG admin with the FTP clients and possibly very painful to the admin hosting the FTP site, but we’re all about defense here. Nice explanation here of the two FTP transfers here
The only problem is that there’s a list of Ms products that use Active FTP as the client by default. The most annoying of which is the built in FTP.exe client on every windows machine. This is extremely painful as there is no way to force this to run in passive mode (Don’t get me started on the quote pasv option in Ms’ FTP.exe debacle – why tell the server to use passive FTP and then, as the client, NOT be able to use passive FTP in the first place!)
SQL Server Integration Service (SSIS) and BizTalk also use Active FTP by default but are easy to flip over to passive FTP.
For those zany folks that have to FTP from the command line I really like ncftp. NCftp client is a free piece of software ported from the *nix world, it has a wonderful .msi format that is easy to deploy to Windows systems. Running commands from a .bat file is as easy as this:
ncftpput -a -u username -p password ftp.site.com . c:\downloads\test.txt
The . (period) after ftp.site.com represents the current directory on the FTP server, in this case the default directory for the username used to log in with.
Uploads local file c:\downloads\test.txt to the current FTP directory on ftp.site.com after login
ncftpget a -u username -p password ftp.site.com . “D:\Server\somewhere\weird folder\” topsecret.*
Downloads remote files topsecret.* from ftp.site.com after login to “D:\Server\somewhere\weird folder\”
The quotes are only used as a space character is used in the folder path. The . (period) after ftp.site.com represents the current directory on the FTP server, in this case the default directory for the username used to log in with.
Plenty of documentation so if you decide to use it, drop some coins in via their paypal donate button.
Can’t get away from Active FTP?
For those stuck in the hell of using Active FTP for a client to an Active FTP site Yuri Diogenes has written a great piece on how to use the application filter to allow Active FTP here so I won’t repeat his instructions.
FTP over HTTP
Back to FTP over HTTP in TMG. For those wondering what this is open up your web browser and type in ftp://ftp.microsoft.com It presents a web view of the ftp site – FTP over HTTP in its full glory.
In ISA have a rule allowing FTP and HTTP meant everything worked, but in TMG they add in the new protocol FTP over HTTP. If you have staff using web browsers to download FTP through the browser then add in or update your FTP allow rule to include the protocol FTP over HTTP. That should keep everyone happy.
Why isn’t my FTP over HTTP rule working
- One firewall too many
You’ve changed your TMG rule but you still get an Error Code 10061 web page from TMG when using FTP over HTTP for any site. For example, in the browser goes ftp://ftp.microsoft.com but this appears:
Technical Information (for support personnel)
- Error Code 10061: Connection refused
- Background: The server you are attempting to access has refused the connection with the gateway. This usually results from trying to connect to a service that is inactive on the server.
- Date: 6/6/666 1:23:45 PM [GMT]
- Server: IloveTMG.honest.com
- Source: Remote server
Now if you have:
A) use multiple IP addresses on your external interface
B) Have set the internal to External Network Rule to use a certain NAT IP address
C) Have a edge firewall/router blocking traffic from certain IP addresses*
You’re problem is the TMG misbehaving and edge firewall device doing its job.
Here’s an example of what the problem is:
I have 192.168.1.66 defined as the IP address the outside world will see from the TMG, despite have twenty other IP addresses on the same external interface. This is defined in the Network Rule tab of the Networking section of the TMG interface.
With a network sniffer, such as Netmon or Wireshark, installed on the TMG server(see below) and listening on the external interface for traffic going to the internet, the TMG uses 192.168.1.66, as it supposed to.
Now connect to ftp://ftp.microsoft.com from a browser and it uses a different IP address (192.168.1.59 in this example)
Feel free to rush to your test lab, try this out for yourself and see it with your own eyes. I’ll wait until you’re back.
But why? WHY?
TMG uses the IP address chosen by Window 2008 TCP/IP stack to pushes out FTP over HTTP rather than the IP address specified in the Network Rule. So it’s Windows 2008 TC/IP stack that’s to blame, rather than poor old TMG, although TMG should really be in full control, so bad TMG! There’s a number of KB’s and articles explaining how Windows 2008 deals with multiple IP addresses.
So what’s the fix?
Easy, but crap security option is to allow FTP out on that IP address (192.168.1.59 in this example) on the external firewall.
I have a request in with Microsoft’s TMG team to explain and hopefully fix this odd behaviour, so when I get a response I’ll update this post
*Option C is pretty common to have a hardware appliance (Cisco, Checkpoint , F5, Sonicwall, etc.) sitting on the edge of the network between the TMG and the raw internet pipe (router, modem or USB device uplink to the ISP) I like have a box in front of the TMG as it stops the random junk traffic from hitting the TMG and provides another layer of defense.

