That should do it. Unless it is explicitly defined that port will not be open.
But even with that port open, some clients will still have problems if they are using PASV (passive) connections which used high ports. I got around it by changing my client (FileZilla) to a "direct" connection or something.
I had the same problem after opening 21 like that. I think 20 is needed as well to "initiate" the connection.
"this page":http://www.kalamazoolinux.org/presentations/20010417/conntrack.html discusses connection tracking with FTP, which you'll need, and offers some rules you can use.
I just finished battling vsftpd this week. I too experience connection problems. Here's the snippet from my iptables that works for me. Setting a rule for dport 20:21 seemed to be the magic sauce I needed to get pasv mode to work correctly.
-KIRBY
*filter
# Allows all loopback (lo0) traffic and drop all traffic
# to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
# You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT
# Allows FTP connections
-A INPUT -p tcp -m state --state NEW --dport 20:21 -j ACCEPT
Just in case it's of any use, the iptables config for my vsftpd box is copied below. I also have the following two configuration directives in my vsftpd.conf file:
pasv_max_port=64110
pasv_min_port=64100
[ BEGIN IPTABLES RULES ]
# Flush all rule tables and clear any user defined chains.
/sbin/iptables -t filter -F
/sbin/iptables -t filter -X
# Defaults are to DROP anything sent to the firewall or internal network and to permit
# anything going out.
/sbin/iptables -t filter -P INPUT DROP
/sbin/iptables -t filter -P FORWARD DROP
/sbin/iptables -t filter -P OUTPUT ACCEPT
# Allow packets into the firewall that are part of existing and related connections.
/sbin/iptables -t filter -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Drop invalid state connections
/sbin/iptables -t filter -A INPUT -m state --state INVALID -j DROP
/sbin/iptables -t filter -A OUTPUT -m state --state INVALID -j DROP
/sbin/iptables -t filter -A FORWARD -m state --state INVALID -j DROP
# Allow all input to the firewall from the internal network and local interfaces.
/sbin/iptables -t filter -A INPUT -i lo -j ACCEPT
# Rules to allow FTP to work. FTP server listens on port 21 and is forced
# to offer PASV ports between 64100 and 64110 (increase this range for a busy ftp).
/sbin/iptables -t filter -A INPUT -p tcp -s 0/0 --source-port 1024: --destination-port 21 --syn -j ACCEPT
/sbin/iptables -t filter -A INPUT -p tcp -s 0/0 --source-port 1024: --destination-port 64100:64110 --syn -j ACCEPT
# REJECT all other connection requests to any UDP or TCP port not yet provided for.
# REJECT is better against certain types of attacks, such as port scanning,
# since it doesn't leave any dead sockets and tells the scanner to go away - no one is home.
/sbin/iptables -t filter -A INPUT -i eth0 -s 0/0 -p udp -j REJECT --reject-with icmp-host-unreachable
/sbin/iptables -t filter -A INPUT -i eth0 -s 0/0 -p tcp -j REJECT --reject-with icmp-host-unreachable
As a follow up (sorry, I should have done this earlier):
The FTP protocol supports two transfer modes ACTIVE and PASSIVE. Rather than me explain it here, have a look at http://www.slacksite.com/other/ftp.html which explains the differences beautifully. The upshot is that passive mode has a far higher probability of working irrespective of how a client's (your FTP users) firewall is configured. The only problem with passive mode is that by default, for it to work, you have to open all ports > 1023 on the FTP server's firewall. Fortunately, decent ftp daemons like vsftp allow you to restrict what ports are used in passive transfers (in vstfpd's case by using the pasv_min_port and pasv_max_port configuration directives) and this in turn allows you to only open a fixed amount of ports on the server's firewall.
By using passive mode and restricting what ports can be used you remove virtually all potential connection problems that could be caused by a client's firewall and don't needlessly reduce security by having to open massive ranges of ports on the server.
This is worth reading:
http://stevenf.com/archive/dont-use-ftp.php
If at all possible, use SFTP instead. It's FTP over SSH, and it's much more secure. FTP actually sends your password in the clear, which is a huge security risk.
Most modern ftp daemons and clients support SSL/TLS encryption for both login and data transfer and there really is no excuse not to enable this. If you *must* guarantee all users can connect then you can also setup the server to fall back to non-encrypted mode for legacy clients.
I have found (at least in the windows world) that FTP clients are still a lot nicer and more featured than their SFTP counter parts and with SSL/TLS enabled you don't lose anything in terms of security.
Having read through that link none (afaik) of the mentioned issues (bar possibly unicdoe support for file names) applies if you use and configure a FTP daemon properly (e.g. vsftpd) and connect with a decent client that supports both control and data channel encryption (e.g. flash fxp for windows).