I can buy what you are saying, since you should know this. You
should then also know what the "out of the box" ProFTPD server
does, that make it fail to talk to users behind a NAT hub. It is
not only my situation. I have this confirmed by at least 10 NAT
connected users (8 in Spain and 2 in Sweden), when the try to
connect to the box that I rent from Rackshack. We all have the
problem that it hangs after the PASV and -LIST commands, on
occasion it can come through after a disconnect command.
Everything in client configurations or different clients is tested and
work on other FTP servers and in one case a setup of an other
ProFTPD server. The non function of FTP is tested to be some anomaly
with the "out of the box" ProFTPD server. I have not sufficient control
or knowledge about the ProFTPD installation to pin down the
problem. I have only established that Ident lookups from FTP or
Rackshack IRC support chat, make it impossible to communicate
in NAT mode. Single connection without NAT work.
An active request from the server to the IP that connects, will not get
any response from the clients. Because with NAT, the sessions that
the client establish MUST be used for all communication. What is
ProFTPD doing in passive mode that do not follow this method?
The whole situation is a major disturbance of the server functionality.
At 03:41 PM 6/11/2003 -0700, you wrote:
>hakan>The only way a server can communicate with a client behind
>hakan>NAT, is to do so on IP/session, given to it by the client. The
>hakan>fact is that after PASV and -LIST commands, the directory
>hakan>listing does not arrive and close to the client.
>Does server debugging output show that the server received these commands?
>If so, then the issue isn't related to ident lookups, for proftpd will
>have been finished with any ident lookups before the client sends any FTP
>commands, even to login.
>I've added debugging calls in the current CVS sources so that at, at debug
>level 6, one can see what's happening with ident lookups (couldn't connect
>to an identd server, lookup timed out or fails, etc). This should help,
>in the future, with debugging such situations.
>hakan>The only thing (except a bug, that would effect other servers
>hakan>also) that I could find is an active Ident opened by the server.
>hakan>An activity opened by the server, cannot be responded to
>hakan>behind the NAT, since NAT does not know where to send it,
>hakan>if a client has not given NAT and server the session id. You
>hakan>cannot reach a client behind NAT in active mode, the client
>hakan>must always initiate the transfers, for them to be labelled.
>*sigh* Active/passive transfer have nothing to do with ident lookups.
>When a client first connects to proftpd, it will do a number of things,
>one of which may be an ident lookup, before the client ever sends any
>commands. Say the client is behind a NAT box, and you have proftpd
>configured for ident lookups. An attempt to contact an identd server on
>the client's IP address will happen. Either that connection will fail,
>and proftpd will continue on, or it will succeed. If the connection
>succeeds, proftpd will then send the proper ident commands. This ident
>lookup may fail, or time out, etc. However, it all still happens _before_
>the client sends any commands. And this is the only time in a session
>when proftpd will attempt an ident lookup; not when the client requests a
>download or upload or directory listing. Thus, ident lookups and
>active/passive transfers are completely unrelated in proftpd.
>There is even a timer on how long such an ident lookup, should a remote
>identd server be listening, lasts. This is to prevent a malicious identd
>from attempting to hang clients.
>Given this, I wonder if there is something else involved in your