Currently I have ISA working with FTP client software as well as the IE browser (PORT mode). The issue I am having is with a script which executes a DOS FTP session to automatically downloads some files. I can successfully establish a DOS FTP session complete with login. However, as soon as I attempt a transfer of any sort(ls or get), it hangs. Has anyone successfully setup DOS FTP access through ISA? I would assume it has to do with packet filters but I am not sure what they should be. Is DOS PORT or PASV? What am I missing here?
Thanks for the quick reply. As for your article I have read it more than once and it was very useful in undertanding how actually FTP works.
What I mean by DOS FTP is exactly that. Command line util included with Win2k. The FTP command is actually embedded in a VBScript, but this is beside the point - it is the scenario where command line FTP is used. If I try a "manual session" I get the behaviour described above; that is, I can login, but it hangs on any kind of transfer. As you say, I should have everything configured correctly, since I can get both FTP client software to work and the browser. That's why I can't understand this issue. I have the browser set to use PORT more and the FTP client successfully uses the firewall client in PASV mode. I did read in another post that there may be a bug with multiple IP's on the external interface. Our config is kind of complicated in that we are running ISA as an Enterprise Array with Stonebeat for failover.
the only problem I know of with FTP and multiple IP addresses assigned to the ISA external interface is described in http://support.microsoft.com/default.aspx?scid=kb;en-us;817829 . The solution is to implement the hotfix or disable IP routing (Kernel Data Pump).
If that doesn't solve your problem, you'll have to take a Network Monitor trace on the ISA external interface are even on the external subnet to see what is really happening on the wire.
Hmm interesting. I didn't anticipate this being such an issue, since I have the other two ways working. I thought maybe it was a quirk with command line FTP. I tried two packet filters, one for outbound port 21 and inbound port 20 but the filters only let you define either the external interface on the ISA boxes or a perimeter box. So I wasn't really sure how that was supposed to work with internal clients. I tried defining the external interfaces thinking that the packet filtering only really took place there. These didn't work either. I checked the ISA logs and at first FTP responses were being blocked on the external interfaces, but once I created the filters the logs showed they were allowed. However, this still didn't fix the problem.
PS ... this work around didn't work for me and the problem described in the Q article isn't the exact behaviour I observed. It's not like I can't establish the FTP session. I can successfully login consistently. The session hangs as soon as some kind of transfer is initiated - for eg. ls or get.
Bizarre. I know.
The packet trace option might work. The logs from the PIX and the ISA logs might be sufficient to determine what is happening. Otherwise I will have to call MSTech support ...
for outbound access creating IP packet filters will *not* help you. You need a protocol and site&content rules and they will create dynamically the necessary IP packet filters.
Can't you place an FTP server in the DMZ between the PIX and the ISA and first the outbound FTP to this FTP server?
OK on the packet filters - didn't think so from what I have read but thought you might know something else. I am pretty sure my Protocol and Site & Content Rules are OK since the the forms of FTP are working.
As for an FTP server in the DMZ - I could try that perhaps - can your redirect an ftp query from a client to a server like that?
I have no experience at all wil Stonebeat, but can you make another test with the Microsoft FTP client? Just make sure that: - you have a protocol rule allowing access to all IP traffic for any request. - you have a site&content rule allowing access to all destinations, any request, any content. - the client is a SecureNAT and/or Firewall client. - you have enabled the logging of all fields in the ISA log settings and the log format is set to ISA. - you take a Network Monitor trace on the ISA external interface.
Post then the relevant entries from the Firewall and IP packet filter logs unmodified. We can first take a look on the log files. If needed, we will compare them with the Network Monitor trace file.
Ok on all points except two. The network monitor trace might be difficult, since these servers are on switches; are you suggesting running netmon on one of the ISA servers? Not sure how the netmon will the traffic otherwise. As for posting it, it has too much information in there regarding the privacy of the company. When you say "unmodified", does that mean not changing anything to "protect the innocent"?
Thanks for sticking with me on this issue. I do appreciate it. Since there are two ISA servers involved, I would guess you mean run netmon on both capturing traffic on both external interfaces. Correct?
As for the info, I thought you meant the ISA logs, since there is more info in there (DMZ addresses, network Id's etc etc) that I do not really want to publish.
I will post the follwing from the ISA logs - it logs two sessions - first the failed DOS session and then the successful FTP client session.
It may not post very well, but here it is none the less - can you tell anything from this?
yes, I mean run netmon on both capturing traffic on both external interfaces.
I'm missing some important fields in the posted Firewall log. As said before, you must enable the logging of *all* fields in the ISA log settings. Can you do that and redo the tests?
Also, I suggest you post 3 excerpts of the Firewall log: - FTP command line client - WSFTPPro in active mode FTP - WSFTPPro in passive mode FTP
I am having the same problem. FTP works with WSFTP, and via a web browser after I enabled passive mode FTP. Is this a problem with command line ftp connecting through PORT mode? I have read your documents on FTP Stefaan, it has helped alot. Thanks for taking the time to write that up. If there is a solution to allow ftp from a command prompt, please post it. Thanks.
the Microsoft command line FTP client works perfectly through the ISA server if the FTP server supports Active mode FTP!
In fact, I always test with the Microsoft FTP client and only use another one if I need to test Passive mode FTP. There is really nothing special to tell about the Microsoft FTP client.
What is the Firewall and IP packet filter log telling you?
I will do some testing this weekend and try to post the logs.
I just tried active mode on the FTP client and it failed, even though I can use PORT mode on the browser. I have a suspicion that the built-in FTP filter does not know how to translate secondary connection on account of our configuration, and that is why it would seem that PORT mode fails in these cases. With two outside interfaces that are "clustered" with stonebeat, I don't think the filter knows on which interface to open the secondary connections. See, we have a virtual IP reprensenting these interfaces, and some fancy work had to be done on our switches and routers, namely enabling multicast mac forwarding on the switch ports and static arp entries on the firewall.
Do you think that this might be causing the issues? That is, the fact that the built-in FTP filter works on perhaps on only one outside interface, but more than one it gets confused?
Have you successfully used the Microsoft FTP client in an array configuration?
Daniel, are you using more than one ISA server in your configuration?
I am scanning through the log file right now and try to make sense of the information on there The thing that I am trying to understand is with passive ftp, does that mean we can't do upload because upload used active mode or am I totally off base on that?? As far as the FTP server not supporting Active Mode FTP from DOS-FTP, is there a way we can be sure of this (I guess this is where the log files help right ???
Kurt,
I am using 2 ISA servers for redundancy.
BTW, would there be any reasons why audio streaming is a problem with window NT 4.0 when 98, 2000 pro, xp, 2003 work???
if only passive mode FTP is working then there is a fair chance that the clustering is creating havoc. Keep in mind that for active mode FTP the FTP application filter must rewrite the IP address and port number in the port command due to the NAT. That is not needed in passive mode.
That's excactly the reason why I asked for a full logging *and* network monitor trace to track down the problem. Personally I have no experience with clustering software, but I know quit well the FTP protocol.
passive or active mode FTP has nothing to do with the ability to perform uploads and/or downloads. It just defines the way the data connection is negotiated. Check out my article again for full details. You will find there also some examples how FTP sessions are logged.
To be RFC compliant, I think that each FTP server must support active mode FTP and might support passive mode FTP. However that says nothing about what is allowed along the path!