Re: interesting behavior of ftp helper

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Hello,

Leonardo Rodrigues Magalhães a écrit :
[...]
>    forward_interna_externa is the created table that receives all 
> traffic flowing from internal to external network. It has, among several 
> others, the following rules:
> 
> -A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m tcp 
> --dport 20:21 -j ACCEPT

Port 20 is not needed. The FTP conntrack helper and RELATED/ESTABLISHED 
states will take care of this.

> -A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m state 
> --state RELATED -j ACCEPT
> -A forward_interna_externa -j LOG --log-prefix "bloq_forward_externa:" 
> --log-level 6 --log-tcp-sequence --log-tcp-options --log-ip-options
> -A forward_interna_externa -j DROP
> 
>    ip_conntrack_ftp and ip_nat_ftp modules are correctly loaded.
> 
>    So, with these rules and all i have read, i was expecting that 20 and 
> 21 TCP ports would handle the active FTP connections and 
> ip_conntrack_ftp+RELATED rule would handle the passive FTP connections.

Not exactly. Port 21 is the control connection and is always used 
whether you're in passive of active mode. Both passive and active data 
connection are RELATED to it. Note that port 20 is used as a source port 
by the server to initiate a data connection in active mode. It is not a 
listening port waiting to accept incoming connections.

>    But ..... altough i was doing what i tought to be the correct rules 
> and loading the needed modules, i couldnt passive FTP. Active FTP was 
> OK, but passive wasn't. My connections were blocked and no packets were 
> hitting the RELATED rule:
> 
> Aug 15 15:20:02 fenix kernel: bloq_forward_externa:IN=eth0 OUT=eth1 
> SRC=192.168.0.54 DST=200.182.XX.YY LEN=40 TOS=0x00 PREC=0x00 TTL=127 
> ID=756 DF PROTO=TCP SPT=1113 DPT=4846 SEQ=1838929699 ACK=3064370605 
> WINDOW=65535 RES=0x00 ACK URGP=0

You must be wrong. This is an ACK packet, following a SYN/ACK packet 
sent by the server in response to a SYN packet you sent to establish the 
passive data connection and which had the RELATED state. Check the 
counters. If the RELATED rule did not catch the SYN packet, then another 
rule did. Once the data connection has been established (after the SYN), 
all its subsequent packets have the ESTABLISHED state, as any other 
connection.

[...]
>    The other theory i got is that only the FIRST packet of a helper 
> identified connection is RELATED and all the other packets that belong 
> to that RELATED connection are indeed ESTABLISHED ones.

Correct. In related connections the RELATED state replaces NEW.