> -----Original Message-----
> From: Dougherty, Joe [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 26, 2002 4:03 PM
> To: 'Joe Patterson'; Ramin Alidousti
> Cc: [EMAIL PROTECTED]
> Subject: RE: mangled ftp packets preventing connection
>
>
> -> 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.
it worked fine for me from inside my firewall to ftp.netfilter.org.
>
> 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.
Well, that depends on your definition of "work". those modules do one thing
each: the conntrack module looks at PORT commands and notes what ports are
being used, then marks those ports as being "related" to the original
connection. The nat module actually mangles the PORT commands so that they
work through a nat device. Your connection, however, is failing long before
it gets to a PORT command. So, if you unload those modules, one of two
things should happen: either it fails in exactly the same way, in which
case you can be pretty sure it's not a problem specific to the module, or it
gets further along and fails later (at or after the PORT command), in which
case you can be pretty sure it *is* a problem with those modules. In
neither case will the overall problem of "it doesn't work" be fixed, but you
will have a better understanding of where the problem might be. And in all
cases it gives you something new to try instead of staring at a blank screen
and occasionally banging your head against the nearest wall. :)
> 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
>
