I had the same exact scenario and problem as you guys described and spent the whole day today trying to identify the issue and find a solution for it. Apparently after following the debugging steps Stefaan requested I was able to identify the same Internal IP replacement pattern, the outgoing FTP packet the external server would get contained the internal IP of the perimeter client, that demonstrated the FTP Access filter wasn't doing the FTP PORT command IP analysis and translation as it should.
I tried guessing theories as to what would make the FTP access filter ignore or fail when analyzing such request, considering the requests were classified correctly when monitoring the source/destination/rule matching.
What I found in my scenario and after doing several scenario evaluations, is that the following configuration makes ISA Server 2004 SP2 fail to correctly apply the FTP Access Filter rules to a specific outgoing connection:
A) I had set up a different access rule for the FTP protocol to allow access to another group of users to specific machines, that rule preceeded the one allowing FTP access from the perimeter to the external network.
B) Both rules had two things in common: both of them had the FTP procol in their protocols list and both of them contained the same network in the From tab (the network from which my machine was originating the request).
C) When disabling the first or putting my perimeter-external-FTP access rule with precedence over the first, the perimeter access was allowed, the PORT command was translated correctly.
This made me think that once the rule gets processed by the firewall upon a client's request and the FTP Access Filter is triggered from within that specific instance, for some reason it goes back to the list of access rules (to probably find the Ready-only restriction property or similar configuration) and then *incorrectly* matches the first rule containing the FTP protocol on it and targeted to the same source/request originator network. Once the first rule is found, I believe the Filter code crashes or exists (leaving the FTP request untreated - no replacement done) when it detects the matching rule is not the same as the one that originated the Filter to be invoked.
I didn't get to analyze the source that filter's DLL but I believe that should be probably what's causing it, which could be considered a bug and is probably also there for ISA 2006.
Mike, not sure if you fixed your issue already as it's been a good 6 months from your last post but I wanted to share this as most of the information from the begginig of this thread to the last ones saved me a lot of time in understanding and testing things through the right path.
(Sorry, I think I started simply wanting to share that I was able to fix the problem in my systems and ended up writing a huge page about it ;) - hope you guys understand).
Roberto Andrade Grass Roots BitTime Product Development / Business Analyst