FTP problem with IPTABLES

Discussion in 'Linux Networking' started by Karl Bickmore, Jul 12, 2003.

  1. 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
     
    Karl Bickmore, Jul 12, 2003
    #1
    1. Advertisements

  2. Karl Bickmore

    ryan Guest

    <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/projects/cuteftp/What_is_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.
     
    ryan, Jul 12, 2003
    #2
    1. Advertisements

  3. Karl Bickmore

    Robert Jirik Guest

    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
     
    Robert Jirik, Jul 12, 2003
    #3
  4. Both Solutions worked, thanks!
     
    Karl Bickmore, Jul 12, 2003
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.