I am in the process of setting up an iptables firewall for one of my boxes and its at about 98% right now. The only thing that isn't working correctly is a slow FTP startup process. When I connect to the server, the connection hangs for a few seconds, then logs in and everything continues at normal speeds. I am using active FTP to get around my router-in-a-box that connects to the internet.

I set up some logging in the firewall to try and figure out what is going on. According to the logs, it turns out that the server is trying to send a series of SYN packets on port 113 (the auth port AFAIK) to the client box a few seconds BEFORE the FTP session is succesfully opened. The firewall is blocking this (as it probably should be), but I am curious 1) why it is trying to do this, and 2) if it is neccesary why iptables doesn't see the state of these packets as RELATED or ESTABLISHED to the FTP connection and allow them that way. I see this in the logs every time I connect to the server via FTP. Below is a segment of my firewall if that will help. TIA.

INPUT (policy DROP):
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:ftp state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp-data state RELATED,ESTABLISHED

OUTPUT (policy DROP):
ACCEPT tcp -- anywhere anywhere tcp spt:ftp state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:ftp-data state RELATED,ESTABLISHED

The port 113 connection is the server trying to get an ident response for your connection, to grab the user running the ftp connection process. Most people do not run ident services any more, but you can't blame the FTP server for trying

You might be better off specifically rejecting AUTH requests at the firewall, if you're not running identd or similar.

Well I've spent all afternoon testing this thing. I found that there are actually packets going BOTH ways on port 113 when an FTP connection is initiated. If I drop the the outgoing packets, it takes about 40 seconds to log in completely (some sort of time out maybe?). If I accept the packets in both directions, everything flies and the connection is initiated right away. If I drop the incoming packets only, the handshake is faster, but not as fast as when I accept them. If I reject the packets in both directions, there is about a 6 second delay between when the SYN packet is sent and when the LIST is recieved by the client. Does anyone see anything significant about this pattern?