I guess I still find it interesting that we are both using more than one ISA server and we are experiencing the same issue. I really do think it has to do with the filter getting confused. What I am also trying to discern here is whether or not it is the clustering or the Enterprise Array config that is at issue.
I know you haven't clustered before, but what about an Enterprise Array setup. Have you have any experience or luck getting MS FTP client to work in this config?
Also - when you say NATing - where exactly is this NATing taking place? It's proxying I thought ...
noop, no experience with enterprice array either. I'm working for customers with rather small networks ( < 250 hosts), a lot of remote sites and not willing to spend enough money!
I agree that there is probably an integration problem with the clustering software and ISA. Tom Shinder has much more experience with such configurations. So, maybe you should drop him an email to catch his attention to this topic.
As explained in my article, the PORT command (Active mode FTP) embeds the IP address and port number the FTP server should connect to for the data connection. That information is inserted by the FTP client and therefore will normally contain his local IP address and a high port number. For a SecureNAT client it is the FTP application filter who will analyze the PORT command and change the content from the clients IP address and port number to his external IP address and another port number. For a Firewall client the IP address and port number to be inserted by the client is negotiated between the Firewall service on ISA and the Firewall client as explained in my article http://www.isaserver.org/articles/Understanding_the_Firewall_Client_Control_Channel.html .
Therefore, if the Firewall service on ISA (including the application filters) is not fully aware of the real external IP address used, you might expect problems will all protocols which have embedded IP addresses and/or port numbers in the data field.
Too bad on the larger installations, sounds like you could handle it for sure and too bad for me cause you would probably have an answer Who is the fellow you mentioned and is it alright to just email him directly?
Ok on the other things you mentioned ... I do recall reading something similar, but I did not read the article you suggest; I will now though .
As for the real IP ... we have looked at the traffic leaving the ISA cluster from the firewall and it actually sees the "real" IP's or interfaces and not the virtual one. In a way the ISA array is not really aware of Stonebeat and Stonebeat is not really aware of ISA. You can use it to fail-over by using the test subsystem to fail-over on a failed services etc, but it really operates at the network level ... failing over to accept all traffic on the virtual IP based on whatever test you setup. The virtual IP's only seem to be used for inbound connections ... Maybe that could be it ... the FTP filter sees the real IP traffic leaving and tries to map it back to the real ones and can't on account of Stonbeat and the firewall trying to pass the traffic back on the virtual IP, thus circumventing the FTP filter. I am not sure if that made any sense to you.
Question here - when ISA initiates that connection outbound to the FTP server, it forms a socket which should return traffic on this same socket connection. Correct? I am a little fuzzy on this point ... or would the firewall intercept it and try and pass it back to the Virtual IP?
Similar situation with the internal interfaces with respect to traffic and real vs. virtual IP's.
Thanks again for all of your assistance. It is appreciated!
If I do the tests this weekend it means I would have to go in to work à which means it may wait until Monday.
quote:Send Me Email, but Keep it on the Boards I enjoy getting your email, but if you have a question, make sure you post the question to the Web boards. After you post your question to the Web boards, send me an email telling me that you've posted your question and a link to where you posted it. This way I can answer the question and everyone can benefit from our discussion.
I would take a network monitor trace on ISA itself and one on another external station on the external segment. For the latter you can use Ethereal. You can then compare both traces, analyze the content of the PORT command and check out to which IP address the FTP server is connecting back.
BTW --- have you already contacted the technical support of Stonebeat?
Does anyone know if ISA server prevent FTP session to/from a Linux server? I am having problem connecting to several Linux server. WS-FTP returns a connection closed by remote host error, and dos-ftp with passive or active mode returns the same thing. Thanks for any help