-> Well, I was thinking that too, but I suspect it isn't the
-> case, because I did a simple test. I telneted through my firewall to an
ftp
-> server's port 21. I then issued the user and pass commands one character
-> at a time (eachcharacter got its own packet, verified via sniffer.)
Did you have any success with this? I tried it inside and outside
the firewall, to two different servers, and neither server would take
partial commands from the console.
This surprised me, because, as I mentioned in my original story, the
user command and argument are going in two packets, and it's accepted.
Perhaps this is being buffered someplace?
-> I don't think that's what his problem is, although I can't
-> say I have any
-> clue as to what *is* the problem. It may be usefull to unload the
-> ip_conntrack_ftp and ip_nat_ftp modules and see if that
-> changes the behavior
-> any, and/or try a straight telnet to port 21 and see if it
-> causes the same
-> problem.
Can one do an ftp process through iptables without those modules
loaded? I was under the impression that ftp wouldn't work unless those
modules were loaded.
On another note: I decided to try one more thing short of removing
the ftp tracking modules. My goal was to eliminate any rules that filter
packets based on flags or state. I wrote rules telling the firewall to pass
all TCP packets between the two system, both new and established. I inserted
this right at the top of the forward chain. Yet, the problem continues: that
first password packet never gets through the firewall.
I'm running out of rocks to look under. ;-)
Joe
