I'll try to describe this issue succinctly, with out cussing!
I subscribe to a customer-mandated file transfer application published out on the interwebs by a third party. The web GUI requires HTTPS from a particular IP, no problem there. However, the web GUI launches a JavaScript "proprietary" (for lack of a better word) FTPS client which opens a command connection on TCP21 with Implicit SSL encryption, then their server opens a plethora of UDP ports back to the client in the range 8000-8999 which are encrypted Implicitly with AES.
I've created an Access rule to allow traffic from internal addresses to the two internet IPs of this vendors app servers, and nothing I've done has been successful in making this connection work. Firewall logs show the outbound FTP traffic on TCP21, but its' hitting a different rule (our general internet traffic rule.) JAVA console logging shows TCP.ConnectionReset when the app tries to handoff to FTP(S) or the UDP ports. I've attempted to add FTP to the protocol set for this rule, I've tried variations on UDP Send/Receive, Receive/Send, both as a Secondary Protocol, I've tried to split into two rules (outbound and inbound) etc but just can't make any headway.
I would even consider getting the right rule to appear in the logs a success! Rule order seems to be ignored... Last access rule or first, my for-the-purpose rule is never triggered.
So, ultimately I have two questions: 1) Why is the rule order apparently being ignored? 2) Does TMG2010 support a "proprietary" FTPS with the above-described port ranges?
Posts: 3472
Joined: 3.Jan.2008
From: Amazon, Brazil
Status: offline
Hi,
TMG does not support FTPS or Secure FTP:
quote:
Secure FTP support
Issue: Forefront TMG does not support secure File Transfer Protocol (FTP). Cause: Secure FTP uses an encrypted control channel between the FTP client and server. After the FTP client and server establish an encrypted control channel, the Forefront TMG FTP filter cannot see the FTP commands and so cannot create the dynamic policy changes that are necessary to fully support FTP communications. Solution: There is an unsupported workaround available that allows you to publish secure FTP. For more information, see Publishing Secure FTP Servers behind ISA Firewalls at the ISAserver.org Web site (http://go.microsoft.com/fwlink/?linkid=51105).
Hey! Thanks for the reply... EXCELLENT series of articles! I'm digesting them now.
Summarizing: In order to support both traditional FTP and FTPS client streams, it looks like I'll need to create custom protocols for FTPS and FTP, disable the global FTP filter, and use the Firewall Client (or add 1024-65536 as Primary Connection ports and live with the security consequences??)