-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 10 December 2002 03:46, Jozsef Kadlecsik wrote: > On Tue, 10 Dec 2002, Alexandros Papadopoulos wrote: > > In any case, the relevant rules from the output chain are: > > ^^^^^^^^^^^^^^ > Isn't there a rule intented for other purposes, which blocks the > passive data channel? The default behavior is DROP for all chains, so if these ones don't allow it, then it is blocked. I thought these ones were sufficient. I'm attaching the complete ruleset I'm using. > > > I'd bet that the problem is that the SYN request sent from the > > client to my server gets dropped, though. Seems like a > > conntrack/INPUT thing. > > I'd setup logging rules to see where and why the connection gets > blocked. > I've monitored the packets with Ethereal and seen that the problem is the one mentioned -- the SYN packet from the client that tries to open the data connection (when in passive mode) never makes it through the firewall. The question is, why doesn't connection tracking pick this up and allow the packet to go through? (since it's a RELATED connection to a preexisting FTP session) Thanks - -A - -- http://andrew.cmu.edu/~apapadop/pub_key.asc 3DAD 8435 DB52 F17B 640F D78C 8260 0CC1 0B75 8265 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE99hPtgmAMwQt1gmURAgCAAJwMh/18DnsMuY3Zp/401XU4itDNbACdEeSj 8vvn0n0ot+Dbc0QuANY4+rY= =9dZt -----END PGP SIGNATURE-----
Attachment:
rules.gz
Description: GNU Zip compressed data
