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.
>
>
next prev 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