Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: common FTP+NAT problem
Date: Mon, 31 Jul 2006 19:44:51 +0200	[thread overview]
Message-ID: <44CE4193.4050603@plouf.fr.eu.org> (raw)
In-Reply-To: <44CE313A.4040204@ort.edu.uy>

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 17:44 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 [this message]
2006-07-31 18:03   ` Pascal Hambourg
2006-07-31 18:10   ` Ernesto Silva
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=44CE4193.4050603@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@lists.netfilter.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