Justin Dugger wrote:

Actually, you probably need a ftp tracking module installed into the kernel; ftp has two ports, the command and data port. The command port is 21, which does things like initiate transfers and list directory contents, etc. It also sends a random number which pertains to the port number for the data port. Now that I think of it, this usually matters much more for the clients, I'm not so sure of the server. Anyone wiser than I (it isn't hard)?

FTP uses port 21 for commands, such as LIST, PWD, DIR, CD, etc. as you stated above. It uses a separate socket and separate ports for data transfers (such as directory listings and files). Data transfers are either "active" or "passive." For active connections, the server initiates a connection _from_ port 20 to a randomly selected port on the client. For passive connections, the client initiates a connection to a randomly selected port on the server. You shouldn't have to unblock port 20 no matter what, since there isn't going to be traffic coming into that port in either case. Firewalls can trip up two things: - They can block active data connections to clients (which is why most FTP client software uses passive connections nowadays). - If a data connection takes a long time, they can time out the associated command connection (which sits idle). To get around these issues firewalls typically use stateful inspection or proxying. References: http://slacksite.com/other/ftp.html http://en.wikipedia.org/wiki/Ftp Gerald Combs CCNA (expired)