I have an Arch Linux system running vsftpd which has been functioning with FTPES for the past year now. Within the past two days, I have noticed that all of my FTP clients fail to connect over FTPES. When I connect using FileZilla 3.17.0 on Windows 7, I notice that a GnuTLS error -15 occurs when the directory list is being sent:
This is passive FTPES with host specified using WAN IP:
Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Response: 227 Entering Passive Mode (###,###,###,###,27,163).
Command: LIST
Response: 150 Here comes the directory listing.
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: Failed to retrieve directory listing
Status: Disconnected from server
FileZilla then retries the connection with identical results, then it stops attempting to connect. A previous version of FileZilla also showed a GnuTLS -110 error, though I do not have output saved containing that error.
I've read some posts which suggest that this issue is caused by a problem with the passive FTP configuration. Passive FTP has been working on this server for a while now, and I have not made any changes to any relevant configuration files. To be sure, I tried connecting using active mode. Everything seems normal until I receive an Illegal PORT command error, at which point FileZilla tries using passive again.
This is "active" FTPES with host specified using WAN IP:
Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PORT 192,168,0,7,240,98
Response: 500 Illegal PORT command.
Command: PASV
Response: 227 Entering Passive Mode (###,###,###,###,27,103).
Command: LIST
Response: 150 Here comes the directory listing.
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: Failed to retrieve directory listing
Status: Disconnected from server
The problem here seems to be that, even though I enter my WAN IP address, active mode still tries to use a local IP address in that PORT command. Another FTP client, FTP Client Pro version 3.0.4 on iOS, gives the error "Server doesn't seem to support Active mode." I then tried connecting to my server locally, and while this time the client didn't lapse into passive mode, the TLS error persists.
This is active FTPES with host specified using local IP:
Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PORT 192,168,0,7,240,129
Response: 200 PORT command successful. Consider using PASV.
Command: LIST
Response: 150 Here comes the directory listing.
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: Failed to retrieve directory listing
Status: Disconnected from server
Finally, I have tried connecting without using encryption. Though I avoid it if at all possible, I must leave unencrypted connections supported in order to connect from some restrictive networks. Both active and passive settings in FileZilla work over the public Internet with encryption disabled, though both types show the same output:
This is active/passive plain FTP with host specified using WAN IP:
Status: Connecting to 98.220.249.102:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Status: Calculating timezone offset of server...
Status: Timezone offset of server is 0 seconds.
Status: Directory listing of "/" successful
Because this server is behind a router, it is configured such that passive FTP will not work locally; see vsftpd.conf below. In the interest of trying out all of the connection possibilities, here is FileZilla's output for making an active, unencrypted connection locally. It fails, but I am not too concerned as I never use that combination of settings.
This is active plain FTP with host specified using local IP:
Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PORT 192,168,0,7,240,195
Response: 200 PORT command successful. Consider using PASV.
Command: LIST
Response: 150 Here comes the directory listing.
Response: 500 OOPS: priv_sock_get_cmd
Error: Failed to retrieve directory listing
Error: Connection closed by server
Here is my /etc/vsftpd.conf, minus the comments. This is essentially the same file that I have been using successfully for the past year.
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
port_enable=YES
connect_from_port_20=YES
ftpd_banner=Welcome to HOSTNAME (vsftpd on ArchLinux).
chroot_local_user=YES
allow_writeable_chroot=YES
listen=YES
ssl_enable=YES
force_local_logins_ssl=NO
force_local_data_ssl=NO
ssl_tlsv1=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem
pasv_min_port=7000
pasv_max_port=7100
pasv_address=###.###.###.###
The latest full upgrade to my Arch system prior to noticing this issue was on 17 April 2016 and included upgraded gnutls (3.4.10-1 -> 3.4.11-1). The most recent upgrade to vsftpd was on 9 March 2016 (3.0.3-1 -> 3.0.3-2), so instead of downgrading only gnutls, I restored the entire system to its state on 9 March 2016 using the Arch Linux Archive. This did not help, and I subsequently upgraded the system to match the current repositories. The output provided here was generated using the up-to-date system as of the date of this post (23 April 2016). I am uncertain as to when exactly this error began, as I do not use my FTP server frequently enough to notice it immediately.
As I stated earlier, my relevant configurations have not changed since my FTP server was last working, aside from changes made to post the information here.
My goal is to get passive FTPES working over the public Internet again. It is acceptable if I must sacrifice unencrypted active FTP, but I would still like to leave that available for those rare times that I need it. What do I need to do to repair this?
I had the same issue as you have and after a long time of searching the internet, I seem to have found a workaround here: Add the line
seccomp_sandbox=NOto your/etc/vsftpd.conf.My use case is a LAN-only, SSL-enabled FTP server, so YMMV. A possible explanation for this issue could maybe be found in me not having installed the latest kernel available in the repos due to an incompatible wifi-driver.
I hope this helps :)