On Tuesday 19 November 2002 18:11, Frédéric Poulet wrote:
I tested with cuteftp my logs are
STATUS:> Getting listing ""... STATUS:> Connecting to ftp server 192.168.5.2:21 (ip = 192.168.5.2)... STATUS:> Socket connected. Waiting for welcome message... 220 ProFTPD 1.2.6 Server (ProFTPD) STATUS:> Connected. Authenticating... COMMAND:> USER test 331 Password required for test. COMMAND:> PASS ***** 230 User test logged in. STATUS:> Login successful. COMMAND:> PWD 257 "/home/test" is current directory. STATUS:> Home directory: /home/test COMMAND:> FEAT 500 FEAT not understood. STATUS:> This site doesn't support the 'features' command. COMMAND:> REST 100 350 Restarting at 100. Send STORE or RETRIEVE to initiate transfer. STATUS:> This site can resume broken downloads. COMMAND:> REST 0 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer. COMMAND:> PASV 227 Entering Passive Mode (192,168,5,2,129,73). COMMAND:> LIST STATUS:> Connecting ftp data socket 192.168.5.2:33097... ERROR:> Can't connect to remote server. Socket error = #10060. ERROR:> Timeout (60000 ms) occurred on receiving server response. Yahoo! Mail : http://fr.mail.yahoo.com
Ok, this is interesting information. The PASV command from the client requests a non-default port for a data channel, the server returns (129,73) = 33097, and the client tries to get a directory listing on that port, which is correct! Now, I suppose the firewall comes in. The FW-log should have a record of a thrown away connection attempt from the client machine on port 33097). I don't know whether the ProFTPD server has any configuration parameter that decides on that particular port, 33097. It doesn't seem to be so, since it delivered another port (129,32) = 33056 when testing with the other client. Nonetheless, it would be great if it could be decided on a small range of ports which are always returned from the server on a PASV request. Then you could open those particular ports in the firewall configuration, which is another problem. If it is not possible, I guess you'll have to disable the firewall in order to make the machine usable as an FTP-server, or at least open a wide range of ports. FTP is old junk, always creating this kind of problems in connection with firewalls. The basic problem is that FTP _is_ insecure, so it _should_ be such problems with technologies like firewalls. Have you considered using SFTP? That is Secure FTP by tunneling file transfers through ssh. Encrypted communication and other nice stuff! Of course, it implies new requirements on clients, but as far as I know, such software is available for most OS:es. For free, I think. -- Ch