Page 1 of 1

PROFTPD no transfer timeout, disconnected

Posted: Mon Jun 02, 2008 11:24 am
by Kalimari
Unable to ftp to server using TLS/SSL (using addition to /etc/proftpd.conf - see * below). Thought there might be a problem with PSA certificate so tried a plain-text ftp login (removed tls addition first) and still no joy. Not sure what other change may have caused this? Upgraded to Plesk 8.4, but uploads worked OK the day after...

Here's a snippet of cuteftp log:
STATUS:> [02/06/2008 15:16:41] Connecting to FTP server... IP_ADDRESS_REMOVED:21 (ip = IP_ADDRESS_REMOVED)...
STATUS:> [02/06/2008 15:16:41] Socket connected. Waiting for welcome message...
[02/06/2008 15:16:41] 220 ProFTPD 1.3.1 Server (ProFTPD) [IP_ADDRESS_REMOVED]
STATUS:> [02/06/2008 15:16:41] Connected. Authenticating...
COMMAND:> [02/06/2008 15:16:41] USER USER_NAME_REMOVED
ERROR:> [02/06/2008 15:17:51] Timeout (60000 ms) occurred on receiving server response.
And /var/log/messages:
Jun 2 15:16:41 HOST_REMOVED proftpd[12014]: DOMAIN_REMOVED (IP_ADDRESS_REMOVED) - FTP session opened.
Jun 2 15:16:51 HOST_REMOVED proftpd[11874]: DOMAIN_REMOVED (IP_ADDRESS_REMOVED) - FTP no transfer timeout, disconnected
Jun 2 15:16:51 HOST_REMOVED proftpd[11874]: DOMAIN_REMOVED (IP_ADDRESS_REMOVED) - FTP session closed.
So thinking it was over-zealous firewall settings blocking packets, went as far as disabling Firewall on local PC (McAfee), router/modem and server (PSA-Firewall). Still no joy and same response.

I can use SFTP, but this requires me to relax security to use SSH this way. Spent most of the day investigating this with no solution, has anyone else experienced this or suggest anything else to try...

* Custom adddition to /etc/proftpd.conf

Code: Select all

# TLS
<IfModule mod_tls.c>
        TLSEngine on
        TLSLog /var/log/tls.log
        TLSProtocol SSLv23
        TLSRequired on
        TLSOptions NoCertRequest
        TLSRSACertificateFile /usr/local/psa/admin/conf/httpsd.pem
        TLSRSACertificateKeyFile /usr/local/psa/admin/conf/httpsd.pem
        TLSVerifyClient off
</IfModule>

ListOptions -a
/var/log/tls.log contains the following when TLS connection is used:
Jun 02 16:14:09 mod_tls/2.1.2[17133]: using default OpenSSL verification locations (see $SSL_CERT_DIR environment variable)
Jun 02 16:14:09 mod_tls/2.1.2[17133]: TLS/TLS-C requested, starting TLS handshake
Jun 02 16:14:10 mod_tls/2.1.2[17133]: TLSv1/SSLv3 connection accepted, using cipher DHE-RSA-AES256-SHA (256 bits)
Jun 02 16:14:10 mod_tls/2.1.2[17133]: set RSA blinding on

Thanks for any suggestions or ideas you may have.

Posted: Mon Jun 02, 2008 3:14 pm
by kwebdesign
I'm not using TLS/SSL, so I'm not sure if this is related or not, but I was having a lot of timeout issues, and even cases where one FTP client could connect and work (albeit slowly), while other clients could not connect at all - even from the same machine.

The problem turned out to be that I was using passive FTP and had not specified what ports proftpd should use and opened those ports on the firewall. I was able to fix it for all clients and users by adding "PassivePorts 60150 60200" to the <Global></Global> section of proftpd.conf, and then specifically allowing TCP ports 60150 - 60200 through on the Plesk firewall.

I'm still not sure why I was able to connect with some FTP clients and not others before making this change - it seems that none of them should have worked the way it was configured before. However, I have not had any problems since.

I hope that helps.

Posted: Mon Jun 02, 2008 6:25 pm
by Kalimari
Thanks kwebdesign,

I stumbled upon some similar suggestions while researching the problem, but like you didn't think it a likely solution as FTP was working until recently. I'll give it a go and report back...

UPDATE: It didn't work. Thanks again for the suggestion. I'll post back with the solution when/if I find one...

Posted: Thu Jun 19, 2008 8:55 am
by Kalimari
Turns out FTP was being blocked intermittently, which started me thinking...

Restarted router, got a new IP address and connected straight away, occasionally it needs a few goes until the server likes the IP address.

I can't begin to speculate the cause... maybe related to ASL?

Posted: Thu Jun 19, 2008 4:20 pm
by scott
The 2.6.24 kernels had issues with cisco PIX's, any chance there was one of those in the mix?

Posted: Thu Jun 19, 2008 6:03 pm
by Kalimari
Yeah, my web host uses Cisco hardware, so it sounds likely...

Posted: Fri Jun 20, 2008 8:03 am
by scott
are you using 2.6.25 now? That and 2.6.23 didn't have the issue with cisco + FRTO

Posted: Fri Jun 20, 2008 11:45 am
by Fenice
We had been running the same setup on our proftpd for a long time, with no issues at all. Issues started when last month our provider, theplanet, had a major outage, and some parts of the data center where destroyed.

Once they restored their service, proftpd was unable to work again with TLS enabled; we contacted them about the issue, but they did not reply to our trouble ticket for 2 weeks. In the meanwhile, we tried everything.

In the end, I moved to another provider, and proftpd works again with the setup we had before. Had I known about the kernel, I would have given it try - I suppose they switched their network gear during the outage, thus causing this compatibility issue.

Posted: Fri Jun 20, 2008 12:08 pm
by scott
Ah thats a good point, theres another condition that can cause that. If the upstream firewall isn't configured to track the FTP session correctly it can lose the transfer channel. Not really anything you can do from the client side other than use another protocol when that happens.