So the situation is you have an FTP client behind your TMG server, trying to connect over FTP to a server on the Internet. Logon looks to be successful, but when you try to do an ls or a dir, you get a 550 response…access denied. If you run a trace on both the client and the external interface of the TMG server, you will see a lot more traffic outside than in, and if you look at the FTP logs, you’ll see that the server is NOT throwing a 550 at all, and as far as it can tell, the client is just disconnecting. So what the heck is going on?
When FTP is permitted out, but still does not work, look to a combination of TMG’s FTP application filter and general FTP permissions as the culprits. Out of the box, the TMG server will not allow active FTP, nor will it allow anything but READ ONLY operations for clients. It’s not really the application filter’s fault; it was built with the expectation that your internal clients would be using the SecureNAT client, and the filter really does enhance FTP by dynamically opening secondary ports as necessary for FTP. If you are not using the SecureNAT client, however, this filter effectively borks FTP communications, even if you have the ip any rule we set up back in this earlier post.earlier post. There are two things you have to do to fix this.
- In the TMG Management Console, browse down to System, click the Application Filters tab, and open the properties of the FTP Access Filter.
Check the box to Allow active FTP access.
- Then browse up to your Web Access Policy, right click your AllowOutboundRule, and click "Configure FTP.
Clear the checkbox in the dialog window that pops up for Read Only.
Apply the changes, and enter "permit ftp" or something similar in your change tracking, and bob’s your uncle.
You might also enjoy:
