FTP problem with IPTABLES

I have a Redhat 9.0 system running as a Firewall and email server. I have
configured SNAT and everything seems to be fine except an issue with FTP.
Clients behind the firewall can login to a remote FTP site, they can CD, but
can't ls, put or get. Below are the rules in the firewall script I have for
FTP:

#I have not inlcuded all of the variables for this post, but I did add some
to help you read this.

UNPRIVPORTS="1024:65535"
EXTERNAL_INTERFACE ="eth0"
ANYWHERE="0.0.0.0/0"


iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
ESTABLISHED,RELATED \
--sport 21 --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j ACCEPT

iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
NEW,ESTABLISHED \
--sport $UNPRIVPORTS --dport 21 -s $EXTERNAL_IP -d $ANYWHERE -j ACCEPT

# Normal Port mode FTP data channels

iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
ESTABLISHED,RELATED \
--sport 20 --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j ACCEPT

iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
NEW,ESTABLISHED \
--sport $UNPRIVPORTS --dport 20 -s $EXTERNAL_IP -d $ANYWHERE -j ACCEPT

# Passive mode FTP data channels

iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
ESTABLISHED,RELATED \
--sport $UNPRIVPORTS --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j
ACCEPT

iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
NEW,ESTABLISHED \
--sport $UNPRIVPORTS --dport $UNPRIVPORTS -s $EXTERNAL_IP -d $ANYWHERE -j
ACCEPT

# Because of MASQ

iptables -A FORWARD -p TCP -s $INTERNAL_NETWORK --sport
$UNPRIVPORTS --dport 20:21 -j ACCEPT
iptables -A FORWARD -p TCP -d $INTERNAL_NETWORK --sport
20:21 --dport $UNPRIVPORTS -j ACCEPT
iptables -A FORWARD -p TCP -s $INTERNAL_NETWORK --sport
$UNPRIVPORTS --dport $UNPRIVPORTS -j ACCEPT
iptables -A FORWARD -p TCP -d $INTERNAL_NETWORK --sport
$UNPRIVPORTS --dport $UNPRIVPORTS -j ACCEPT

On Fri, 11 Jul 2003 18:30:19 -0700, Karl Bickmore wrote:

> I have a Redhat 9.0 system running as a Firewall and email server. I have
> configured SNAT and everything seems to be fine except an issue with FTP.
> Clients behind the firewall can login to a remote FTP site, they can CD,
> but can't ls, put or get. Below are the rules in the firewall script I
> have for FTP:

<snip>

This is a classic problem with FTP in a NAT environment. It's all about
Passive (PASV) mode. The short answer is, your clients behind the NAT
need to turn on PASV mode within their FTP client. See the man page or
other documentation for your FTP client for how to set this; any decent
FTP client will have the ability to toggle Passive mode.

Below is a detailed explanation of Passive and Active modes of FTP,
courtesy of Ted Ede, taken from:

http://help.globalscape.com/robo/pro...PASV_Mode_.htm

Regards,
Ryan Rhea

----------

What is PASV Mode?

This explanation is courtesy of Ted Ede.

In active mode you talk to the FTP server, and ask for a file. Over that connection, the server says to you, "Okay, I'm going to send you a file, and I'm going to send it you over a new connection to Port X on your machine". X is from 1024 to 65535. Your client replies, "go for it".

Now the FTP server tries to open that port, but speaking on a port that the NAT gateway would not be expecting a request on. So, all of a sudden your NAT gateway receives a request on Port X, and it does not know which machine on the your net that the packet was intended for, so it denies the request, and you don't get your file.

On linux, ip_masq_ftp, a kernel module, can be loaded to fix this. Instead of blindly NATing away, it eavesdrops on the FTP protocol, and it knows in active mode that the server will reply to the client over the control connection with a port number which is contained in the *data* of the packet. When a reply comes in on this port, the ip_masq_ftp module tells the NAT code to route it to the correct client behind the gateway. You still need to open the firewall to all incoming ports, but only if the source port is the FTP data port.

In PASV (passive) mode, port 21 is always initiated by the client for control and port 20 is always initiated by the client to receive data. This makes it NATable. Most FTP clients are set to Active mode by default and must be told to switch to PASV mode.

It's kind of a misnomer to say the client is passive. Basically, it instructs the server to be passive, telling it, "Hey FTP server, don't get active on me! When I want the file, I'll open a connection to you and get it."

So, you may be saying, why did they bother with this active baloney at all? Like everything invented in unix, there's more to it than meets the eye. Two properly implemented FTP servers can be made to work together from a third machine. Using the FTP control port from machine A, you can tell the FTP server on machine B to download the contents of a directory on machine C. This is basically how FTP mirror sites get updated.

Karl Bickmore wrote:

> I have a Redhat 9.0 system running as a Firewall and email server. I have
> configured SNAT and everything seems to be fine except an issue with FTP.
> Clients behind the firewall can login to a remote FTP site, they can CD,
> but
> can't ls, put or get. Below are the rules in the firewall script I have
> for FTP:

It's passive mode problem, anyway - try:
insmod ip_conntrack_ftp
insmod ip_nat_ftp

it should do ...

--
Robert Jirik
[mailto:robert(at)aristoteles(dot)xhaven(dot)net]
public PGP key: http://xhaven.net/robert/pgp_key.asc
-
"There's one good kind of writer -- a dead one"
-- James T. Farrell

Both Solutions worked, thanks!


"Karl Bickmore" <(E-Mail Removed)> wrote in message
news:xwJPa.3155$u51.1427@fed1read05...
> I have a Redhat 9.0 system running as a Firewall and email server. I have
> configured SNAT and everything seems to be fine except an issue with FTP.
> Clients behind the firewall can login to a remote FTP site, they can CD,
but
> can't ls, put or get. Below are the rules in the firewall script I have
for
> FTP:
>
> #I have not inlcuded all of the variables for this post, but I did add
some
> to help you read this.
>
> UNPRIVPORTS="1024:65535"
> EXTERNAL_INTERFACE ="eth0"
> ANYWHERE="0.0.0.0/0"
>
>
> iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
> ESTABLISHED,RELATED \
> --sport 21 --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j ACCEPT
>
> iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
> NEW,ESTABLISHED \
> --sport $UNPRIVPORTS --dport 21 -s $EXTERNAL_IP -d $ANYWHERE -j ACCEPT
>
> # Normal Port mode FTP data channels
>
> iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
> ESTABLISHED,RELATED \
> --sport 20 --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j ACCEPT
>
> iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
> NEW,ESTABLISHED \
> --sport $UNPRIVPORTS --dport 20 -s $EXTERNAL_IP -d $ANYWHERE -j ACCEPT
>
> # Passive mode FTP data channels
>
> iptables -A INPUT -i $EXTERNAL_INTERFACE -p TCP -m state --state
> ESTABLISHED,RELATED \
> --sport $UNPRIVPORTS --dport $UNPRIVPORTS -s $ANYWHERE -d $EXTERNAL_IP -j
> ACCEPT
>
> iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p TCP -m state --state
> NEW,ESTABLISHED \
> --sport $UNPRIVPORTS --dport $UNPRIVPORTS -s $EXTERNAL_IP -d $ANYWHERE -j
> ACCEPT
>
> # Because of MASQ
>
> iptables -A FORWARD -p TCP -s $INTERNAL_NETWORK --sport
> $UNPRIVPORTS --dport 20:21 -j ACCEPT
> iptables -A FORWARD -p TCP -d $INTERNAL_NETWORK --sport
> 20:21 --dport $UNPRIVPORTS -j ACCEPT
> iptables -A FORWARD -p TCP -s $INTERNAL_NETWORK --sport
> $UNPRIVPORTS --dport $UNPRIVPORTS -j ACCEPT
> iptables -A FORWARD -p TCP -d $INTERNAL_NETWORK --sport
> $UNPRIVPORTS --dport $UNPRIVPORTS -j ACCEPT
>
>