I set up an ftp daemon on my LAN's internet gateway box. I have no problems logging into the ftp from other LAN computers, but I can't get a response when trying to login from another computer on the internet. My network looks like is: LAN [eth0] gateway with ftp server [eth1] DSL router internet I have a rule on the DSL router to forward incoming packets to port 21 to the gateway, but I don't know how to verify if this is working as expected. Any network tools I can use to check if I'm getting the requests at the gateway's eth1? Thanks.

The dsl router is nat'ing your gateway's ip, right? And you're using passive ftp (e.g. from a web browser), right? That's a common problem with ftp, as the protocol isn't suited for such setups. Try using a real ftp client with active (not passive) transfer mode. Explanation: The ftp connection to port 21 (the control connection) does succeed, but the ftp protocol requires the ftp client to establish another connection (a data connection) for every data transfer, including dir listings. Web browsers (any many ftp clients in the default config as well) use passive mode, which means that the ftp servers tells the client an ip and port to connect to for the data connection. In your case, the ftp server will respond with a nat'd ip, and the client isn't able to connect to that, and that's why you never see the initial dir list. In active ftp mode however, the roles are reversed: the client tells the server an ip/port combo, and the server will connect to the client for the data connection. This will work in your setup without problems (unless the client is firewalled as well). Unfortunately there's no easy way around that. You'd have to make the ftp server send the outside public ip instead of the nat'd ip, and let your router forward the incoming data connections to the ftp server. In the default setup, port numbers are random, so you need another tweak in the ftp server. I'm not aware of any ftpds that support that. Alternatively the router could mangle the ftp control connection's command, kinda a reverse of the ip-masq-ftp module of linux. But I doubt it that the router supports that.

Thanks for the help. I wasn't able to get it to connect using an active client either. I tried blowing wide open my server's firewall for a moment, and I still couldn't connect from the outside. I've had the same lack of success for ssh. 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-23. Is there a diagnostic util I can run on the server that would indicate if someone's trying to connect to a specified port?

You can use for example tcpdump to see all packets coming to your box on a specific interface. Use the -i flag to specify the interface to use, and append a simple filter rule to the command line to limit output to interesting packets. For example, to see all ssh traffic on eth0, you could use: tcpdump -i eth0 port 22 Output lines for tcp start with a timestamp, followed by source host/ip and port, a ">", then target host/ip and port, and then a character indicating tcp flags. A "S" indicated a syn packet, which is a connection request.

Great! Using tcpdump I managed to keep ahead of my Mysteriously Changing External IP, which seems to change itself every hour or so when there's not much network traffic. Probably my ISP's attempt to get me to buy its expensive static IP options. Anyway, I've managed to connect from a remote computer using both passive and active ftp clients. However, trying to connect to the external IP from an _internal_ computer (on the same LAN as the server) always gets me "connection refused". Using the server's internal IP works fine though. Any ideas what might be the problem here? Btw, I have the same problem with ssd too.

Probably an issue with your dsl router. Linux 2.2 with ipchains port forwarding exhibits the same behavior: the packets only get forwarded when they arrive on the external interface, but when they arrive on the internal interface, nothing happens and you get connection refused, even though the ips used and everything is the same in both cases. Unless you can config the router to work right (?), you'll have to live with it.

I can live with it, so it's okay for me now. Thanks for you help all this time. :)