I am trying to set up an ftp server that is accessible from the internet.

I have no problems logging into the ftp from other LAN computers, but I can't get a response when trying to log in from another computer on the internet.

My network looks like is:
LAN <-> [eth0] gateway with ftp server [eth1] <-> hardware DSL router <-> internet

The DSL router is set up to do NAT. I have set a rule to forward incoming packets to port 21 to the gateway.

Any ideas where I might be missing a step? Are there any network tools that I can use to check if I'm getting any incoming requests at the gateway's eth1?

Any help would be appreciated.

If port 21 is opened on your router and directed to the gateway FTP server, this should work.

Just for grins, how do you initiate the FTP from outside your network?

For example, you would need to FTP to the ISP assigned DSL router IP address unless you have it set up in a DNS somewhere on the Internet.

Another common problem is that hosts behind the router can not access other hosts behind the router using the ISP assigned DSL router IP.

Just some thoughts...

I don't have a solution to your problem. But you can use iptables to find the packets that come to a host. Some thing like "iptables -t nat -I PREROUTING -d server_ip -j LOG" should work. If you want you can give protocol and destination port option.
Also I have read some where that ftp uses port 20 for data transfer. Don't know much about this. But opening port 21 should allow you to login to the server.
--Sarin

Try starting your ftp daemon with the option for eth1 it may be defalting to eth0.

Thanks all for your suggestions, I'll give them a try when I'm free. Someone on another forum mentioned that ftp works by opening another connection on an arbitrary port for each user. I may have to break open a range of ports for ftp to work if this is the cause of problem.

Rich: I'm using a dynamic DNS service (www.dyndns.org). It rules.

I think you might want to have a look at the following document about the explanation of active/passive ftp: http://www.slacksite.com/other/ftp.html

If you are using active ftp with your client software, you will need to open up port 20 as well.
Also ports above 1024 are needed, which ports though is not to tell as the "client" determines the port number.

As far as I know you can tell the client which range of ports to use, so you can control the range of ports to open up in your firewall for ftp communication.

I hope this will help, or lead you to solving your problem.

That won't be necessary.

If you are using iptables there is a feature called connection tracking. That means you can tell your firewall how to determine what packets belong to which connection. You have to tell it for each protocol (ftp, irc, ...) separately.

For ftp this is done with:
Now your firewall knows that the extra connections that are made for ftp (called data connections) are related to the ones on port 21.

By adding the following line to your firewall script, you can tell it to allow such traffic:

You can check out my firewall script if you want to see more examples: ftp://griffon26.kfk4ever.com/pub/iptables.txt

I originally took an example script from http://www.linuxguruz.org/iptables/ and modified it to suit my needs.

Usually you will need to enable ACTIVE transfers on the FTP client side. This makes connections through routers much easier because the connection opens port 20 for control stuff rather than some abitrary port. The connection tracking in iptables is nice, but it didn't do the job for me. Check out http://www.linuxguruz.org/iptables for some good iptables scripts for FTP servers.

Griffon26: Thanks for the info. While I still can't successfully connect from the internet, it did help me protect my server from the LAN.

TruckStuff: In principle, I'd like to support PASV clients so people won't have to mess with their own firewalls to get active clients to work. Thanks for the suggestion anyway.

As for why I can't connect either way, I'm tempted to blame the hardware router (that sits between the server and the internet) for blocking inbound requests despite the settings to forward ports 20-22 (I can't connect from outside using ssh either).

Is there a diagnostic util I can run on the server that would indicate if someone's trying to connect to a specified port?

And here I am, thinking you are trying to protect your computer from the internet

I made a chain called "blocked" in my script and send everything I want to reject to that chain.

So you'll have something like:

The blocked chain could look like this:
Note that the -m limit parameter will make sure that your syslogd isn't flooded. But as a result of that, not all packets will be logged if there are a lot of them in a short period of time.

Great! Checking the logs and using tcpdump, I managed to debug my network. Also found out my net connection was afflicted with the Curse of the Mysteriously Changing External IP, which seems to happen every hour or so without warning.

Anyway, I can now connect from a remote computer using both passive and active ftp clients without ripping any more holes in my firewall. Thanks all for your help.

Last small problem: when trying to connect to the external IP from an _internal_ computer (on the same LAN as the server), I get "connection refused". Connecting to the server's internal IP still works fine though. Any ideas what might be the problem here?

You probably have to allow traffic to and from the internal interface but addressed to the external IP.

iptables -A INPUT -i $LAN_IF -d $EXT_IP -j somechain
iptables -A OUTPUT -i $LAN_IF -s $EXT_IP -j somechain

As you can see in my iptables script, I created some rules to split up the traffic based on direction, origin and destination.

I have chains for traffic from LAN to internet, LAN to server, server to internet, etc. I added the lines above and replaced 'somechain' in the first line with the chain for LAN to server traffic and 'somechain' in the second line with the chain for server to LAN traffic.

Whether or not to actually allow traffic is determined by the rules for those chains.