I've encountered an odd error state that I haven't been able to resolve yet. I have a customer that, for what ever reason, wants to use active mode occasionally for FTP xfers. What they have noticed, is that after you switch to active, and issue a command (they do 'ls', I've done other things like 'put' and 'get', etc.), the connection hangs. If you wait a bit it returns with a "425 Failed to establish connection". I've tried this on three hosts so far (all CentOS 5) and they all behave the same, some of which there is effectively no firewall (all traffic is allowed from my workstation to the host, and no restrictions on exiting traffic).
All google searches about this behavour thus far have talked about old versions of vsftpd or using filesystems such as FAT, which don't apply in all cases. Any ideas?
--Tim ____________________________________________________________ / bureaucracy, n: \ \ A method for transforming energy into solid waste. / ------------------------------------------------------------ \ \ \ \ /\ ( ) .( o ).
On Thu, 2008-06-05 at 11:05 -0700, Timothy Selivanow wrote:
Any ideas?
Did you open both ftp and ftp-data ports?
On Thu, 2008-06-05 at 14:23 -0400, Ignacio Vazquez-Abrams wrote:
On Thu, 2008-06-05 at 11:05 -0700, Timothy Selivanow wrote:
Any ideas?
Did you open both ftp and ftp-data ports?
Yes. On some of the hosts, my workstation is just explicitly allowed through also (I've also tried turning off iptables, just in case).
--Tim ______________________________________________________________ < I wouldn't be so paranoid if you weren't all out to get me!! > -------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
On Thu, Jun 5, 2008 at 2:05 PM, Timothy Selivanow timothy.selivanow@virtualxistenz.com wrote:
things like 'put' and 'get', etc.), the connection hangs. If you wait a bit it returns with a "425 Failed to establish connection". I've tried
Is the FTP client behind NAT? If it is then active FTP won't work, since the client will request the server to connect to the internal IP.
HTH, Filipe
Filipe Brandenburger wrote:
On Thu, Jun 5, 2008 at 2:05 PM, Timothy Selivanow timothy.selivanow@virtualxistenz.com wrote:
things like 'put' and 'get', etc.), the connection hangs. If you wait a bit it returns with a "425 Failed to establish connection". I've tried
Is the FTP client behind NAT? If it is then active FTP won't work, since the client will request the server to connect to the internal IP.
its somewhat more complex than that. many NAT boxes (home routers, etc) recognize FTP on port 21, and monitor the PORT commands, and mangle them automatically. A linux masquerading server can do this too, with the right ip_masq module. if the FTP is running on a nonstandard port other than 21, the automagic stuff won't work. If the FTP /server/ is behind NAT using a port forward, it also gets messy.
there's a detailed discussion of these and other salient points here, http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html it bears reading carefully.
On Thu, 2008-06-05 at 20:04 -0700, John R Pierce wrote:
Filipe Brandenburger wrote:
On Thu, Jun 5, 2008 at 2:05 PM, Timothy Selivanow timothy.selivanow@virtualxistenz.com wrote:
things like 'put' and 'get', etc.), the connection hangs. If you wait a bit it returns with a "425 Failed to establish connection". I've tried
Is the FTP client behind NAT? If it is then active FTP won't work, since the client will request the server to connect to the internal IP.
its somewhat more complex than that. many NAT boxes (home routers, etc) recognize FTP on port 21, and monitor the PORT commands, and mangle them automatically. A linux masquerading server can do this too, with the right ip_masq module. if the FTP is running on a nonstandard port other than 21, the automagic stuff won't work. If the FTP /server/ is behind NAT using a port forward, it also gets messy.
there's a detailed discussion of these and other salient points here, http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html it bears reading carefully.
There's no NAT'ing occuring in my tests (all machines, including my workstation are not using RFC1918 addresses, some of the core routing infrastructure is, but it's all routable and not NAT'd). There are various routers and firewalls between my workstation and the hosts, but all ACL's and firewall rule sets allow my traffic unimpeded to my testing hosts and the customer's hosts.
The frustrating thing is, it happens on all of the CentOS 5 machines I've tested on.
--Tim ____________________________________________ < Invest in physics -- own a piece of Dirac! > -------------------------------------------- \ \ \ \ /\ ( ) .( o ).