Has anybody ever had one of those problems that seems like a real challenge at the start but eventually (after a few wasted days) turns into pure drudgery. Well I certainly have.
Can I please tell you about it? I am a web developer who needs to spend a lot of time FTP'ing a large number of files to various hosts. I FTP from a windows 2K SP2 box which is behind a Redhat 7.2 firewall/gateway. I use CuteFTP 4.2.4 (but I'm pretty happy I have eliminated the client as the problem) to batch transfer anything from 20 to 60 files at a time using PASSIVE mode. All goes well for what appears to be a random number of files (sometimes 5 or 6, sometimes 30 or 40) then the transfer just stops, the connection dies and CuteFTP re logs in and the process picks up where it left off. After two or three attempts (and the user skipping files which don't require overwriting) the site is updated. Although it works it is very annoying. This is the error from CuteFTP COMMAND:> STOR themes.inf STATUS:> Connecting data socket... ERROR:> Failed to establish data socket The kernel is 2.4.7-10 and the masquerading is done via IPTABLES 1.2.4-2. I am confident the rule set is not filtering any ftp packets as although the default is set to DROP, all DROPS are logged and I don't get any logged packets. There is however one strange thing about the ruleset (relevant fragment below). Unless the INPUT state is set to NEW as well as ESTABLISHED and RELATED, then ftp packets are dropped and the whole transfer fails. haven't got to the bottom of this yet and I'm worried it may be a security hole. # Allow any related traffic coming back to the MASQ server in # $IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state \ INVALID -j drop-and-log-it $IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state \ NEW,ESTABLISHED,RELATED -j ACCEPT ####################################################################### # FORWARD: Enable Forwarding and thus IPMASQ # echo " - FWD: Allow all connections OUT and only existing/related IN" $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED \ -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT # Catch all rule, all other forwarding is denied and logged. # $IPTABLES -A FORWARD -j drop-and-log-it echo " - NAT: Enabling SNAT (MASQUERADE) functionality on $EXTIF" # #More liberal form #$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE # #Stricter form $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP I think the problem is related to ip_conntrack_ftp and ip_nat_ftp somehow as they don't seem to be being used. The kernel does not load them automatically and if I load them manually via /usr/sbin/insmod they just sit there and do nothing (see below). [root@multimedia bin]# lsmod Module Size Used by ip_conntrack_ftp 4080 0 (unused) ip_nat_ftp 3680 0 (unused) autofs 11520 0 (autoclean) (unused) ipt_LOG 3984 1 (autoclean) ipt_state 1152 3 (autoclean) iptable_nat 18224 1 (autoclean) [ip_nat_ftp] ip_conntrack 16944 3 (autoclean) [ip_conntrack_ftp ip_nat_ftp ipt_state iptable_nat] iptable_filter 2256 0 (autoclean) (unused) ip_tables 11392 6 [ipt_LOG ipt_state iptable_nat iptable_filter] 8139too 12832 1 tulip 39232 1 usb-uhci 21536 0 (unused) usbcore 51712 1 [usb-uhci] ext3 64624 5 jbd 40992 5 [ext3] Now I have lots of questions. Am I on the right track? If so, what activates ip_conntrack_ftp and ip_nat_ftp? Have I missed a configuration somewhere? If these modules are activated will it fix my problem? Should ftp work in passive mode without them? Incidentally, if I take an intermediate step of FTP'ing to the gateway and then FTP'ing from the gateway to the host, it always works 100% no probs. Sorry this has been a bit longwinded but I figured more info is better than less. Can anybody help. If the problem is fixed in just a few lines of e-mail, I am going to scream. Kind Regards Steve McAllister
