Accessing FTP via IE wont work for ISA clients

A bunch of FTP questions, seems tragic it is so tough.

Mine goes like this.  I am managing two distinct domains with ISA 2004 in 
front of each.  There is a dediicated VPN channel opened between them, and 
everything works great.

The access rules are nearly identical on each ISA box.  From inside of one 
network, users can download FTP files from IE on sites such as Symantec and 
HP, but the connection times out on the other network.  On the working one, 
the log monitor shows an FTP connection on port 21 followed by an FTP 
connection on a high port.  In both accesses, FTP is the publishing rule and 
protocol recognized.

On the other network, the FTP connection on port 21 is followed by an 
unrecognized protocol on a high port, and that happens twice more (same 
outside IP address).  The attempt to download a file fails.

I have looked at the access rules and system rules till my eyes have crossed 
trying to come up with any differences.  I even deleted the rule from the 
non-working network, exported it from the working one and then imported it. 
Still no results that are positive.

The FTP rule says allow traffic from internal, local and VPN clients to 
External.  The only protocol in the rule is FTP and the filter is checked in 
the properties.  No internal FTP server.  The failure occurs no matter which 
IE or Firefox browser I try (some IE 6 and IE 5 on the working network).

Any ideas?  I have the impression that just setting up that access rule 
would work, and that is precisely what happened on the working network.

I thank you all in advance for whatever help you might be able to provide.

In the advanced properties of IE there are two things involving FTP. One is
the "folder view for FTP" toggle and the other one is the "active/passive"
toggle. Try various combinations of those to find something that works.  FTP
is not "simple",..it is a very complex protocol and IE is a very *lousey*
FTP Client, you will probably always have a certain amount of trouble.

If the users are only downloading and not uploading then you a 100% better
off to just use a web service,...you can make it behave similar to an FTP
site by turning on Directory Browsing for the target folder in the IIS MMC
and not putting any HMTL files in there,...it will list the files the same
as FTP and they can download the same as FTP. And you won't have all the
hassle.

This is exactly what I do here when we have to supply files to outside
clients. I use FTP initially, it simply wasn't worth the trouble.  FTP is
only really usefull of they are doing uploads, and then we insist that they
use a "real" FTP client,...I am just not going to "babysit" everyone's IE
situation if they are trying to use it as an FTP Client.

I don't know anything about "other" browsers.

-- 
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
 http://www.**--****.com/ 

Microsoft Internet Security & Acceleration Server: Guidance
 http://www.**--****.com/ 
 http://www.**--****.com/ 

Microsoft Internet Security & Acceleration Server: Partners
 http://www.**--****.com/ 
-----------------------------------------------------

I have played with both settings and all four combinations dont change the 
result.  

Other browsers was essentially meant to be Firefox.  

What still bothers me and what I hoped was the most salient point of my post 
was the way in which the failure is occuring:  the connection on port 21 is 
recognized as FTP and is allowed, but subsequent high-port connectiions fail 
as unrecognized.  However, in the other domain I manage, it works slick as 
can be with FTP coming up for the high port connections.  This was 
implemented simply by adding the access rule, no tweaking of anyone's IE or 
anything else.

THe main reason for getting this successful is application software that 
provides for automatic updates.  The users have several of these, and they 
seem to work via ftp over a web interface only (some by running an imbedded 
IE page).  

The internal IT guys also rely on downloading drivers, etc. from specific 
web sites and use IE as their principal tool.  While it may suck in the minds 
of many, it nevertheless works extraordinarly well on one implementation of 
ISA and not at all on another, almost identical one.  With a specific 
requirement and need, I prefer not to tell users they are just idiots for 
wanting to do something (that they know full well they can and it works) 
simply because I can't find the reason.

I will endeavor to keep looking. Thanks.

FYI, I have found and solved the problem.  Simply put, ISA was working 
perfectly.  I was not.

In the ISA manager, there is a section called Add-Ins, and one of the tabs 
is for application filters.  Lo and behold, FTP was not enabled.  Enabling it 
and restarting the service fixed all.

So, if any of you have the problem of FTP not allowing securenat clients to 
connect to the dynamic port when you otherwise have a perfectly good access 
rule, please check that the application filter is enabled.

OK, sounds good.

"Larry Heimendinger" < XXXX@XXXXX.COM > wrote in


it
to
access