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