Thanks to everyone for the help, especially Josh Paetzel, who actually tried
to answer the original question.  I was trying not to admit this FTP server
is on a Windows 2003 box, so I just kept plugging away and trying.  Never
did figure it out.  So I am going to install VMWare server and within that
set up a minimal linux server.  That I know how to do.

- Joey

On 3/3/07, Justin Krejci <jus at krytosvirus.com> wrote:
>
> This is very nice and gives great visual representations of FTP
> communications
> in passive and active modes.
>
> http://slacksite.com/other/ftp.html
>
> On Saturday 03 March 2007 11:17, Josh Paetzel wrote:
> > On Friday 02 March 2007 12:08, The Wandering Dru wrote:
> > > Andrew Zbikowski wrote:
> > > > I always use the command line on
> > > > Linux, but there has to be a GUI client somewhere.
> > >
> > > Both Konqueror and Nautilus have the ability to connect to remote
> > > ssh. It's just drag and drop from there.
> > >
> > > Most linux ftp clients I've seen can do scp as well.
> >
> > While I agree that sftp is a better choice, mainly because it plays
> > nicer with NAT and doesn't throw plain-text passwords around, there
> > are situations where FTP is still needed....so I'll actually answer
> > your question.
> >
> > FTP runs over two ports, a command port and a data port.  So far all
> > you've been dealing with is the command port, which is why clients
> > can connect but not actually do anything.  To make things worse,
> > passive FTP, which is the default for almost every client out there
> > these days, has one more nasty trick up it's sleeve.  In passive FTP
> > the client connects in on a random high port for data that is agreed
> > upon between the client and server over the command
> > channel....unfortunately, unless you are running something like
> > connectrac w/ iptables or punch_fw for ipfw the NAT implimentation
> > has no way of knowing which port to expect this connection on.  So
> > you end up with a situation like this...
> >
> > client connects to server on command port which is punched through the
> > NAT and says, I'd like to do a ls.  Server replies back, ok, let's do
> > that over port, uhmmm, well, let's use 10584.  Client says ok, and
> > tries to connect in....at that point your router sees a brand new
> > connection coming in to port 10584 and has no clue what to do with
> > it, so it gets dropped.
> >
> > The solution is to limit the range of data ports your FTPd can use (by
> > default they use 1024 - 65535) and forward those through the router
> > as well....most decent FTPd's have some sort of PassiveMaxPort and
> > PassiveMinPort directive in them.  You'll also need to tell it to use
> > your WAN IP for passive connections....the name for this setting
> > varies.  Your other option is to run a NAT implimentation that can do
> > connectrac or punch_fw.
>
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20070306/a960aff7/attachment.htm