These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for FTP - LIST command stalls on the new forum.
Web Hosting and Cloud Computing Control Panels
Some FTP clients default to active FTP and some default to passive FTP. ProFTPd is configured, by default, to accept either...but many firewalls can break one or the other (oddly, as only one requires anything fancy to work).
Opening the high ports used by FTP is usually sufficient to resolve issues like this. I generally open <i>all</i> high ports (1024:65535), since many protocols rely on access to them...though you can also use the RELATED and ESTABLISHED stateful rules in iptables, if the offending firewall is a Linux iptables firewall.
--
Check out the forum guidelines!
The only firewall is IPtables but Im still not sure that it's relavent.
I CAN connect to the machine and login fine it just hangs on the LIST command.
If it's IPtables causing the problem I shouldn't be able to login if the port is blocked should I?
FYI, I disabled IPtables and it dis work then so obvisouly you're right but I still don't understand why? I'm not really comfortable opening all high ports...that seems pretty dangerous....
<div class='quote'>that seems pretty dangerous...</div>
That's me, always living dangerously!
Actually, it's almost entirely harmless. The only concerns with opening high ports is if you have databases or other services listening on public addresses (which is potentially quite dangerous). But, high ports are specifically <i>for</i> user-level, non-privileged communication--they're intended for everybody on the system to be able to use them for various services. Realistically, not many services use them or need them to be open, and thus it's irrelevant to have them open--it's a security null. Neither positive or negative, if you don't have any services that use them.
There's no need to be superstitious about firewalls and open ports--if you don't have a service running on a port, then opening it is meaningless. No one can exploit a non-existent service, and pretty much nothing in a reasonably configured web server system actually runs on a high port (and those that do, like databases, default to local addresses only). And, if you <i>have</i> configured a service to run on a high port on a public address, then presumably it's because you want to provide some sort of service to the world on that port...and you'd be opening it anyway! ;-)
Anyway, if you want to be specific, you could just open a small range of ports, and configure ProFTPd to only use those ports. By default, it will use any of the high ports--I think any that the client requests. But some folks go for just the ephemeral ports range, which is 49152:65534. Set ProFTPd to use this range with:
PassivePorts 49152 65534
And open iptables with:
iptables -I INPUT -p tcp --dport 49152:65534 -j ACCEPT
iptables-save
Again, you may prefer to instead use a stateful rule something like this:
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables-save
This doesn't open <i>any</i> ports. It allows all traffic that is related to some other connection that's already been allowed--so if you allow the the initial FTP connection on 21 or 20 it'll allow all subsequent requests that are related to that connection. At least, I think it'll work that way.
--
Check out the forum guidelines!
then you are left with a few options.
if it is a VPS then you have a control panel for it so that is easy. Either reboot fron there or ask the support to make ssh work.
if its your own box then ask the data center guys to reboot without the IPtable loaded or go to the data center if possible and do it yourself.
on centos its real easy. press I at startup and skip whatever you don't want to load.
another option is to get APC on the box to remotely reboot but that wont help much if the messed up iptable gets loaded at boot.. a RAC will help in those cases.
oh and dreamweaver by default uses active connection on port 21.
if Dreamweaver works and any other ftp program doesn't, then likely it is not something on the server but has something to do with the ftp program.
imo you should use winSCP and alternatively filezilla (and generate a ssh key. a local private key can be made by puttygen).
It was filezilla I was using
i happen to have an openvz as well (as a slave-nameserver).
You can't do anything related to the kernel whereas under Xen you can do limited things assuming your host knows his stuff.
iptables for one is extremely limited under openvz and not really worth making a fuzz about on your system, unless you want to run services under different ports than the defaults.
On a side note: My experience with such a VPS is that RAM is extremely important as you do not have swap. Also the OS template your host is using as some have rpmforge enabled which can screw things up for Webmin in a nasty way.
I tried both of the above changes to iptables. first the top, restarted IPtable just to be safe and then the 2nd and restarted again. No LIST, same as before.
It only works if I run service iptables stop
I tried forcing filezilla to active mode and it connects fine (wish I'd tried it before the IPtbles mods just to see which was doing the work) but Kompozer (amongshttp://www.virtualmin.com/components/com_fireboard/template/virtualmin/i...
Quick Reply t others) has only passive FTP...
Oops... ignore the accidental paste in the middle of my last reply.
I tried to edit it after but got a an error from the board....
Do you have any additional luck if you enable FTP connection tracking? You can do that with:
/sbin/modprobe ip_conntrack_ftp
That may assist iptables in determining what connections are really from your FTP client and may help both active and passive modes to work.
-Eric
Hey that worked! thanks!
will that remain enabled through a reboot or tdo I have to modify a conf somewhere?
No, it's not persistent, so you'd have to load it up again next time.
On CentOS/RHEL, it looks for a file called /etc/rc.modules. You can put modules you'd like to load in there like this:
echo "/sbin/modprobe ip_conntrack_ftp" >> /etc/rc.modules
Then next time you reboot, it should load that up (you can verify it with /sbin/lsmod).
-Eric
Oh, right, and you'll need to make that file executable:
chmod +x /etc/rc.modules
More details here: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-gui...
It doesn't exist anywhere on the machine.
Should I just create it? Will it know to look for it automatically?
If you run this command:
grep -n rc.modules /etc/rc.sysinit
On my system I see:
354:if [ -f /etc/rc.modules ]; then
355: /etc/rc.modules
That is, in the RHEL/CentOS startup files, it looks for that file and when it exists, it executes it.
So, yeah, if you create that file on a RHEL/CentOS system, it'll be executed.
However, you might consider two other options:
1. /etc/modules.conf is also used for loading modules
2. If you're loading iptables via the system script, /etc/init.d/iptables, you can use the RHEL/CentOS way to load an iptables related module by editing /etc/sysconfig/iptables-config and adding "ip_conntrack_ftp" to the IPTABLES_MODULES section. It would then be loaded each time "/etc/init.d/iptables start" is executed.
-Eric
Thanks much....I wonder why this isn't enabled by default?
Actually this seems to have broken the machine in other ways... IMAP and POP stopped working so I took it out of the ip-tables-config and rebooted the virtual machine and now that's all back but now I can't ssh into the host it just times out. I think it broke IPtables on the host machine and I can't get into it to try rebooting it....
<div class='quote'>Actually this seems to have broken the machine in other ways... IMAP and POP stopped working so I took it out of the ip-tables-config and rebooted the virtual machine and now that's all back but now I can't ssh into the host it just times out. I think it broke IPtables on the host machine and I can't get into it to try rebooting it....</div>
Slow down. You're definitely conflating multiple, unrelated issues into one big "OMGWTFBBQ!" moment. ;-)
So, can you still login to Virtualmin? If so, browse to Webmin:Networking:Linux Firewall and stop the firewall while you figure out what went wrong.
But, I suspect the firewall has nothing to do with IMAP and POP. ip_conntrack_ftp is extremely specific about what it does, and certainly wouldn't break other protocols. I'm not sure what would cause the troubles you describe, except maybe simply not allowing access to the necessary ports in your iptables configuration.
Anyway, you'll need to narrow things down and tackle one problem at a time. Rebooting and random poking and prodding isn't really the right way to go about solving problems. Though I suppose a reboot will be necessary if you have no way to get into the box. ;-)
--
Check out the forum guidelines!
I guess I need to clarify for a second...
Virtualmin is running on Centos5 virtual machine running under Openvz on a Centos5 host machine. The problem is that I can't ssh (putty) into the HOST since making these changes. Somehow they seem to have caused a problem with the firewall on the host.
I have removed the changes from the virtual machine and had a manual reboot done at the remote centre and now things are back to normal, I can access the hardware.
It seems to me that making the changes to the virtual machine somehow also affected the physical. Perhaps its an Open VZ problem?
So, the offending firewall is inside the virtual system?
You wouldn't (shouldn't) be able to insert modules into the host kernel from within the guest system--so I think I'm confused.
--
Check out the forum guidelines!
Yes, the offending firewall is inside the virtual machine but what I'm saying is that making the mods in the Virtual machine also affected the physical host, but not is a good way.
I know that OpenVZ is "containerized" but it's not run as a completely separate entity to the best of my knowledge. perhaps its a bug of some sort.