Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Ernesto Silva <silva@ort.edu.uy>
To: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Cc: netfilter@lists.netfilter.org
Subject: Re: common FTP+NAT problem
Date: Mon, 31 Jul 2006 15:10:12 -0300	[thread overview]
Message-ID: <44CE4784.3090909@ort.edu.uy> (raw)
In-Reply-To: <44CE4193.4050603@plouf.fr.eu.org>

Hi Pascal,
	the "-t nat" was a typo in the email.
I wrote the "RELATED" specification because I thought port 20 and the rest of the connections (in passive and active mode) 
may be handled by ip_conntrack_ftp and ip_nat_ftp in an "automagically" way. Thats why I was asking about the modules 
functionallity.

Anyway, I used your suggestion (which I already knew) and wrote the extra rules for port 20, 1024:, etc.

you wrote:
 > You don't need to care about conntrack states in the nat table : only
 > the first packet of a NEW connection goes through the nat chains.
I didn't know that, thanks.

Many thanks, problem solved.
-- 
Ing. Ernesto Silva.
Coordinador de Desarrollo Web y Sistemas Abiertos
Universidad ORT Uruguay.
E-mail: silva@ort.edu.uy
Tel: (+598-2) 902-1505 ext. 206


Pascal Hambourg wrote:
> Hello,
> 
> Ernesto Silva a écrit :
> 
>>    I'm having a problem to access internet ftp servers from my 
>> internal network. I understand the ftp connection but I don't have 
>> enough information about ip_conntrack_ftp and ip_nat_ftp modules, so 
>> here is my situation.
>>
>> I'm using iptables 1.3.3-3, I have the mentioned modules loaded and 
>> wrote the following rules:
>>
>> _fwd="iptables -A FORWARD"
>> _nat="iptables -A POSTROUTING"
> 
> 
> Same remark as Baltasar about "-t nat" missing in _nat.
> Are you sure you understand the FTP protocol ? When reading your 
> ruleset, I doubt it.
> 
>> $_fwd -i $INT_IF -p tcp -s $INT_NET --sport 1024: -o $INET_IF --dport 
>> 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>> $_fwd -i $INET_IF -p tcp --sport 21 -o $INT_IF -d $INT_NET --dport 
>> 1024: -m state --state     ESTABLISHED,RELATED -j ACCEPT
> 
> 
> You'll never see an FTP control packet (TCP 21) in the RELATED state.
> 
>> $_nat -p tcp -s $INT_NET --sport 1024: -o $INET_IF --dport 21 -m state 
>> --state NEW,ESTABLISHED,RELATED -j SNAT --to $INET_NIC
> 
> 
> You don't need to care about conntrack states in the nat table : only 
> the first packet of a NEW connection goes through the nat chains.
> 
>> Are those rules enough?
> 
> 
> No. They only allow FTP control connections, not FTP data connections 
> used for file transfer and directory listing.
> 
>  From your ruleset, I understand you want to allow FTP between internal 
> clients and external servers, and nothing else. All right. Be aware that 
> blocking the useful RELATED ICMP may break things, though.
> 
> First, FTP is made of a classic TCP control connection from the client 
> to the server on port 21. It means the first packet is NEW and all 
> others are ESTABLISHED, so :
> 
> $_fwd -i $INT_IF -s $INT_NET -o $INET_IF -p tcp --sport 1024: \
>   --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
> $_fwd -i $INET_IF -o $INT_IF -d $INT_NET -p tcp --sport 21 \
>   --dport 1024: -m state --state ESTABLISHED -j ACCEPT
> 
> $_nat -o $INET_IF -s $INT_NET -p tcp --sport 1024: --dport 21 \
>   -j SNAT --to $INET_NIC
> 
> Second, a TCP active or passive FTP data connection is established 
> whenever a file transfer or directory listing is needed. Passive data 
> connections are established from the client to the server with random 
> unprivileged ports on both sides. Active data connections are 
> established from the port 20 of the server to an unprivileged random 
> port of the client. When the ip_conntrack_ftp module is loaded, the 
> first packet is RELATED (instead of NEW without the module), and all the 
> others are ESTABLISHED as usual. So :
> 
> # passive mode
> $_fwd -i $INT_IF -s $INT_NET -o $INET_IF -p tcp --sport 1024: \
>   --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
> $_fwd -i $INET_IF -o $INT_IF -d $INT_NET -p tcp --sport 1024: \
>   --dport 1024: -m state --state ESTABLISHED -j ACCEPT
> 
> # active mode
> $_fwd -i $INET_IF -o $INT_IF -d $INT_NET -p tcp --sport 20 \
>   --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
> $_fwd -i $INT_IF -s $INT_NET -o $INET_IF -p tcp --sport 1024: \
>   --dport 20 -m state --state ESTABLISHED -j ACCEPT
> 
> No need for any NAT rule, the ip_nat_ftp module will smartly take care 
> of everything automatically.
> 
> But IMHO this is a bit overkill. Here's what I'd use :
> 
> # that's for any ESTABLISHED and RELATED traffic, not only FTP
> $_fwd -i $INT_IF -s $INT_NET -o $INET_IF -m state --state \
>   ESTABLISHED,RELATED -j ACCEPT
> $_fwd -i $INET_IF -o $INT_IF -d $INT_NET -m state --state \
>   ESTABLISHED,RELATED -j ACCEPT
> 
> # that's for the first packet of a control connection
> $_fwd -i $INT_IF -s $INT_NET -o $INET_IF -p tcp --sport 1024: \
>   --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
> $_nat -o $INET_IF -s $INT_NET -p tcp --sport 1024: --dport 21 \
>   -j SNAT --to $INET_NIC
> 
> 
> Notes about ip_conntrack_ftp and ip_nat_ftp :
> 1) They only work on plain unencrypted FTP. They don't work on FTPS (FTP 
> encrypted with TLS/SSL).
> 
> 2) When using FTP control connections on non standard ports (i.e. other 
> than 21), you must specify theses ports (as well as port 21 if used too) 
> in the "ports" parameter of both modules when loading them.
> 
> 


  parent reply	other threads:[~2006-07-31 18:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 16:35 common FTP+NAT problem Ernesto Silva
2006-07-31 16:52 ` former03 | Baltasar Cevc
     [not found]   ` <44CE397B.9030404@ort.edu.uy>
2006-07-31 17:23     ` former03 | Baltasar Cevc
2006-07-31 17:39   ` Ernesto Silva
2006-07-31 17:44 ` Pascal Hambourg
2006-07-31 18:03   ` Pascal Hambourg
2006-07-31 18:10   ` Ernesto Silva [this message]
2006-07-31 18:19     ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44CE4784.3090909@ort.edu.uy \
    --to=silva@ort.edu.uy \
    --cc=netfilter@lists.netfilter.org \
    --cc=pascal.mail@plouf.fr.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox