Gnutls error 15 filezilla

Moderator: Project members

Status:	Connecting to 3x.xxx.xxx.91: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...
Status:	Server sent passive reply with unroutable address. Using server address instead.
Command:	MLSD
Error:	GnuTLS error -15: An unexpected TLS packet was received.
Error:	The data connection could not be established: ECONNABORTED - Connection aborted

Status:	Connecting to 3x.xxx.xxx.91:21...
Status:	Connection established, waiting for welcome message...
Status:	Initializing TLS...
Status:	Verifying certificate...
Status:	TLS connection established.
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/" is your current location
Command:	TYPE I
Response:	200 TYPE is now 8-bit binary
Command:	PASV
Response:	227 Entering Passive Mode (3x,xxx,xxx,91,234,34)
Command:	MLSD
Error:	GnuTLS error -15: An unexpected TLS packet was received.
Error:	The data connection could not be established: ECONNABORTED - Connection aborted

Status:	Connecting to 3x.xxx.xxx.91:21...
Status:	Connection established, waiting for welcome message...
Status:	Initializing TLS...
Status:	Verifying certificate...
Status:	TLS connection established.
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/" is your current location
Command:	TYPE I
Response:	200 TYPE is now 8-bit binary
Command:	PASV
Response:	227 Entering Passive Mode (3x,xxx,xxx,91,213,167)
Command:	MLSD
Error:	The data connection could not be established: ECONNREFUSED - Connection refused by server

Status: Resolving address of 3x.xxx.xxx.91
Status: Connecting to 3x.xxx.xxx.91
Warning: The entered address does not resolve to an IPv6 address.
Status: Connected, waiting for welcome message...
Reply: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Reply: 220-You are user number 3 of 10 allowed.
Reply: 220-Local time is now 15:27. Server port: 21.
Reply: 220-IPv6 connections are also welcome on this server.
Reply: 220 You will be disconnected after 10 minutes of inactivity.
Command: CLNT https://ftptest.net on behalf of 3x.xxx.xxx.91
Reply: 530 You aren't logged in
Command: AUTH TLS
Reply: 234 AUTH TLS OK.
Status: Performing TLS handshake...
Status: TLS handshake successful, verifying certificate...
Status: Received 1 certificates from server.
Status: cert[0]: subject='CN=192.168.1.5' issuer='CN=192.168.1.5'
Command: USER xxxx
Reply: 331 User xxxx OK. Password required
Command: PASS ***********
Reply: 230 OK. Current restricted directory is /
Command: SYST
Reply: 215 UNIX Type: L8
Command: FEAT
Reply: 211-Extensions supported:
Reply: EPRT
Reply: IDLE
Reply: MDTM
Reply: SIZE
Reply: REST STREAM
Reply: MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Reply: MLSD
Reply: ESTP
Reply: PASV
Reply: EPSV
Reply: SPSV
Reply: ESTA
Reply: AUTH TLS
Reply: PBSZ
Error: Carriage return without line feed received

Status:	Connecting to 3x.xxx.xxx.91:21...
Status:	Connection established, waiting for welcome message...
Status:	Initializing TLS...
Status:	Verifying certificate...
Status:	TLS connection established.
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Retrieving directory listing...
Status:	Directory listing of "/" successful
Status:	Disconnected from server
Status:	Connecting to 3x.xxx.xxx.91:21...
Status:	Connection established, waiting for welcome message...
Status:	Initializing TLS...
Status:	Verifying certificate...
Status:	TLS connection established.
Status:	Server does not support non-ASCII characters.
Status:	Logged in
Status:	Starting download of /D-Russo/Desktop/stampa.bollettino.pagamento_rotated.pdf
Command:	CWD /D-Russo/Desktop
Response:	250 OK. Current directory is /D-Russo/Desktop
Command:	PWD
Response:	257 "/D-Russo/Desktop" is your current location
Command:	TYPE I
Response:	200 TYPE is now 8-bit binary
Command:	PASV
Response:	227 Entering Passive Mode (3x,xxx,xxx,91,255,249)
Command:	RETR stampa.bollettino.pagamento_rotated.pdf
Error:	The data connection could not be established: ECONNREFUSED - Connection refused by server
Error:	Connection timed out after 20 seconds of inactivity
Error:	File transfer failed

Failed to get the folder list
I won't open a connection to 192.168.1.8 (only to 3x.xxx.xxx.91)

Hello,

Lots of googling with no solutions to this problem unfortunately and after at least a solid 12 hours trying to solve this i’m loosing it a bit!

Problem already exists here however none of the provided solutions helped and noticed it was already solved after I necrobumped (oops). Also went through at least first 2 pages of search results on google so can’t say I haven’t tried with this one!

As the title describes I am trying to enable SSL on my VSFTPD. I get different errors on different FTP clients however on FileZilla I get the most helpful one:

Attemping to mount the FTP server with curlftpfs gives the following error:

.

A lot of sites have suggested that SSL is hiding the actual issue however everything works fine when SSL is disabled.

Here is my vsftpd.conf file:

# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
nopriv_user=ftp
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
chroot_local_user=YES
#chroot_list_enable=NO
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd with two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES

# Set own PAM service name to detect authentication settings specified
# for vsftpd by the system package.
pam_service_name=vsftpd

ssl_enable=YES

# if you accept anonymous connections, you may want to enable this setting
allow_anon_ssl=NO

# by default all non anonymous logins and forced to use SSL to send and receive password and data, set to NO to allow non secure connections
force_local_logins_ssl=NO
force_local_data_ssl=NO

# TLS v1 protocol connections are preferred and this mode is enabled by default while SSL v2 and v3 are disabled
# the settings below are the default ones and do not need to be changed unless you specifically need SSL
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

# provide the path of your certificate and of your private key
# note that both can be contained in the same file or in different files
rsa_cert_file=/etc/ssl/certs/vsftpdCertificate.pem
rsa_private_key_file=/etc/ssl/certs/vsftpdServerkey.pem

# this setting is set to YES by default and requires all data connections exhibit session reuse which proves they know the secret of the control channel.
# this is more secure but is not supported by many FTP clients, set to NO for better compatibility
require_ssl_reuse=NO

#ssl_ciphers=AES128-SHA256
ssl_ciphers=HIGH

#pasv_enable=YES
#pasv_min_port=6000
#pasv_max_port=7000
#pasv_address=127.0.0.1

#debug_ssl=YES

In addition the full trace of FileZilla in debug mode:

Trace:	CRealControlSocket::DoClose(66)
Trace:	CControlSocket::DoClose(66)
Trace:	CControlSocket::DoClose(66)
Trace:	CControlSocket::SendNextCommand()
Trace:	CFtpLogonOpData::Send() in state 0
Status:	Connecting to 127.0.0.1:21...
Status:	Connection established, waiting for welcome message...
Trace:	CFtpControlSocket::OnReceive()
Response:	220 (vsFTPd 3.0.3)
Trace:	CFtpLogonOpData::ParseResponse() in state 1
Trace:	CControlSocket::SendNextCommand()
Trace:	CFtpLogonOpData::Send() in state 2
Command:	AUTH TLS
Trace:	CFtpControlSocket::OnReceive()
Response:	234 Proceed with negotiation.
Trace:	CFtpLogonOpData::ParseResponse() in state 2
Status:	Initializing TLS...
Trace:	tls_layer_impl::client_handshake()
Trace:	tls_layer_impl::continue_handshake()
Trace:	TLS handshake: About to send CLIENT HELLO
Trace:	TLS handshake: Sent CLIENT HELLO
Trace:	tls_layer_impl::on_send()
Trace:	tls_layer_impl::continue_handshake()
Trace:	tls_layer_impl::on_read()
Trace:	tls_layer_impl::continue_handshake()
Trace:	tls_layer_impl::on_read()
Trace:	tls_layer_impl::continue_handshake()
Trace:	tls_layer_impl::failure(-15)
Error:	GnuTLS error -15: An unexpected TLS packet was received.
Status:	Connection attempt failed with "ECONNABORTED - Connection aborted".
Trace:	CRealControlSocket::OnSocketError(103)
Trace:	CRealControlSocket::DoClose(66)
Trace:	CControlSocket::DoClose(66)
Trace:	CFtpControlSocket::ResetOperation(66)
Trace:	CControlSocket::ResetOperation(66)
Trace:	CFtpLogonOpData::Reset(66) in state 4
Error:	Could not connect to server
Trace:	CFileZillaEnginePrivate::ResetOperation(66)

Any advise on how to fix this would be greatly appreciated!

Many Thanks

Last edited by doctorzeus (2019-09-27 03:29:24)

vsftpd LIST causes GnuTLS error -15

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:

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:

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:

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:

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:

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.

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?

Источник

unexpected GnuTLS error -15 in nsdsel_gtls.c:178 #4288

Comments

vasiliyaltunin commented May 19, 2020

I have a problem with TLS.

I try many different guides and have same result, when i try to send message from client

logger — aptupdater -n 192.168.0.237 Test remorte —tcp -P 6514 -s
I get errors on server

on client i have a errors:

on service start

Here config of server

I generate my cert with this scripts:

The text was updated successfully, but these errors were encountered:

alorbach commented May 19, 2020

The error messages generated bei GNUTLS are not helpful, that’s why we implemented OpenSSL driver as well which is much more telling when it comes to error messages.

I would recommend to switch to OpenSSL and see if you get any error details:

vasiliyaltunin commented May 19, 2020

I get
could not load module ‘lmnsd_ossl’, errors: trying to load module /usr/lib/x86_64-linux-gnu/rsyslog/lmnsd_ossl.so: /usr/lib/x86_64-linux-gnu/rsyslog/lmnsd_ossl.so: cannot open shared object file: No such file or directory [v8.1901.0 try https://www.rsyslog.com/e/2066 ]

I think i need install driver, but cant find package name

rgerhards commented May 20, 2020

I think i need install driver, but cant find package name

It should be rsyslog-openssl or rsyslog-ossl.

vasiliyaltunin commented May 20, 2020

May be there a way compile from source?

alorbach commented May 20, 2020

Do you use rsyslog from our repositories?
If not you should switch to them:
https://www.rsyslog.com/ubuntu-repository/

vasiliyaltunin commented May 20, 2020 •

and still not luck — cant find ossl package

rgerhards commented May 20, 2020

and still not luck — cant find ossl package

thx — I am currently looking into the OBS repo to see what it takes to build them there. I’ll update this thread when I have more info.

rgerhards commented May 20, 2020

@vasiliyaltunin I have updated the OBS repo now. You should be able to install rsyslog-openssl. Pls let me know if it works out.

vasiliyaltunin commented May 20, 2020

Strange, but here

i able install it by hand

vasiliyaltunin commented May 20, 2020

Just in case for future, if you try to connect to host with ossl from host with gtls, you will have thi kind of errors:

vasiliyaltunin commented May 21, 2020

Now restarting rsyslog on both servers

May 21 12:54:15 zabbix-server rsyslogd: [origin software=»rsyslogd» swVersion=»8.2004.0″ x-pid=»33781″ x-info=»https://www.rsyslog.com»] start
Client:

May 21 12:55:03 netxms-server rsyslogd: [origin software=»rsyslogd» swVersion=»8.2004.0″ x-pid=»35783″ x-info=»https://www.rsyslog.com»] start

Now sending logs:

echo 123 | logger -t aptupdater -n 192.168.130.237 —tcp -s -P 6514

Client log did not have any new lines

All servers have same version of openssl

OpenSSL 1.1.1d 10 Sep 2019

davidelang commented May 21, 2020

the logger command cannot talk TLS, so you can’t use it to deliver logs to 6514 like you are trying

davidelang commented May 21, 2020

load the imptcp module and set it up listening on port 514 so that you can send logs to it via logger.
or on the client, just log to the local syslog and let it send the logs to the server.

vasiliyaltunin commented May 21, 2020 •

I tried but nothing happend, it appears in local syslog, but not sended to remote

present on client

vasiliyaltunin commented May 21, 2020 •

After few minutes on

i have error on client:

vasiliyaltunin commented May 22, 2020

It worked, but with some problems, some time i get
From client i do:

logger -t aptupdater AAAAAAAAAAAAA

on server i get

So it appear randomly

alorbach commented Oct 6, 2020

@vasiliyaltunin and @davidelang
I have found an issue in the gnutls doRetry handshake handler and created a PR to fix the problem.
#4439

Would be great if one of you could apply the patch and test it in your environment to see if the problem gets fixed.

alorbach commented Feb 19, 2021

@thiagofborn Can you check the client debug log for configuration loading errors and for OpenSSL errors?
And is rlsclient_ca_bundle.crt in PEM format?
Which version of rsyslog are you running?

thiagofborn commented Mar 5, 2021 •

Using the «gtls» driver.

Server Configuration that works:

Note: the chain.pem is the composition of the «ca_bundle.pem» and the «certificate.pem». Certs from ZeroSSL.

Some of those were coming up from the client rsyslogd.log.

alorbach commented Mar 11, 2021

@thiagofborn sorry for the delay, I took a look to your debug files now. The client configuration seems to differ from what you are using in your gtls configuration. You are only using the CA configuration on the client side:
«/opt/syslog-ng/etc/syslog-ng/ca.d/rlsclient_ca_bundle.pem». Does this ca bundle contain ca from «Let’s Encrypt»?

In the gtls config you posted, you are using «/home/born/certs_test/Root-CA.pem» now. I am a little confused now, but I think this problem is caused by wrong ca / certificate configuration.

If you take a look to https://github.com/rsyslog/rsyslog/tree/master/tests and search for «sndrcv_tls_ossl» tests, you will find many working configuration examples — all with selfmade openssl certificates.

thiagofborn commented Mar 11, 2021

Sorry for the confusion. You are right. It is a whole different story on my new configuration files. Should I delete the previous post? And focus on the «gnutls driver» since it is working. It probably would be a better fit for those reading these posts.

Question:
«/opt/syslog-ng/etc/syslog-ng/ca.d/rlsclient_ca_bundle.pem». Does this ca bundle contain ca from «Let’s Encrypt?»

Answer:
To be accurate, I have requested new certs on a different CA. The ZeroSSL. Their service provided a certificate bundle with the Root CA and the intermediate certificate. The client certificate and the private key. The process on Let’s Encrypt is the same by the way. I have used ZeroSSL because I was in

The was created as follows:

When I test it, it seems to be fine:

rgerhards commented Mar 11, 2021

@thiagofborn If this is a separate issue, I would suggest to open a separate issue — that makes it easier for everyone. But if it is closely related, it is of course fine to stick here.

Источник

vsftpd — ошибка GnuTLS -15: получен неожиданный пакет TLS

Как я могу исправить эту ошибку, когда я пытаюсь подключиться к серверу ftp на filezila:

И эта ошибка на возвышенном плагине ftpsync:

Это мои настройки vsftpd:

3 ответа

Я попытался добавить строку в мой файл конфигурации. Откройте конфиг здесь:

И поместите эту строку внизу:

После этого перезапустите сервис:

Это исправить это для меня.

Может быть, у вас есть ошибка, которая не имеет отношения к SSL.

1. Попробуйте деактивировать SSL ( ssl_enable=NO )
2. Связаться с вашим любимым FTP-клиентом.

Тогда вы, вероятно, видите настоящую ошибку.

Поэтому ответ Francisc IB не имеет отношения к SSL.

Я столкнулся с этой же проблемой. Другой поток не советует устанавливать allow_writeable_chroot=YES по соображениям безопасности, а именно, для смягчения «Атаки ROARING BEAST».

Установка allow_writeable_chroot=YES означает, что vsftpd должен разрешить ситуацию, когда домашний каталог пользователя доступен для записи для этого пользователя. Вместо этого по соображениям безопасности я изменил разрешения для корневой папки пользователя с 777 до 555.

Изменено на: dr-xr-xr-x /home/ftpuser/

Это сделало домашний каталог пользователя НЕ доступным для записи пользователем, и, таким образом, мне не пришлось использовать параметр allow_writeable_chroot=YES. Это хорошо (и более безопасно) для моей ситуации, так как у меня есть предустановленная структура каталогов, и я не хочу, чтобы пользователь делал новые файлы или каталоги в своей корневой папке в любом случае.

Я понял это, когда переключил домашний каталог в /var/ftp с помощью параметра local_root = [path] для vsftpd, и это работало без необходимости устанавливать allow_writeable_chroot=YES. Эта папка /var/ftp (755), но принадлежит root и, следовательно, не доступна для записи ftpuser.

Источник

VSFTPD An unexpected TLS packet was received

I am trying to setup several ftp users, each with its own subfolder (so the user can see only he his root folder, and nothing else).

current issue is that on filezilla I am getting

I tried all options of the FTP in Filezilla (TLS explicit or implicit). Error in all the options.

the user1 folder looks like this (after chmod+chown):

UPDATE

From what I am reading, this can be related to folder doesn’t exist, or wrong permissions. I added ‘allow_writeable_chroot=YES’ i the conf file. I also added ‘log_ftp_protocol=YES’.

This is the current log (/var/log/vsftpd.log):

after chown for the ‘user1’ folder:

/home/ftpmain/ftp is owned by ‘nobody:nogroup’

UPDATE #2

current situation is that I made sure that I can connect to the FTP using plain FTP-active mode. For plain FTP-passive mode I am still getting an error:

When trying with TLS, I am still getting the same unexpected TLS packet was received error, even after trying chmod on the user1 folder

2 Answers 2

Finally got it to work. Beside my debugging process which I outlined in the updates to the original question, here is what I did after.

For TLS to work, I recommend that you first make sure that passive mode is working without TLS. This is because from what I understand the encryption will prevent the server ip that is sent by the server to be received by the ftp client.

So first step, disable TLS by setting ssl_enable=YES in the conf file.

Passive mode requires additional ports. These are the lines that are related to that in the config file:

You have to make sure that the passive ports are open! I was using EC2, so you need to open the ports in the security groups. In addition check ufw:

With this I was able to connect using passive mode, and then enabling ssl_enable=YES just worked.

This final /etc/vsftpd.conf:

I have followed all the steps well explained in this link.

And then, yes I encountered similar error. So I followed the suggestion in your answer to first try to connect without TLS by commenting ssl_enable=YES .

However, this did not work (see following error):

Until I added this directive in the configuration file /etc/vsftpd.conf :

However, I have done some searches and found that for security reasons, this option must not be set to YES :

Allow chroot()’ing a user to a directory writable by that user. Note that setting this to YES is potentially dangerous. For example, if the user creates an ‘etc’ directory in the new root directory, they could potentially trick the C library into loading a user-created configuration file from the /etc/ directory.

As a reminder chroot is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. This modified environment is called a chroot jail.

So a good practice, is to set allow_writeable_chroot=NO and make an ftp directory which acts as chroot. Here is an example:

Источник

I set up two new CentOS 7 boxes simultaneously, so the configurations should be identical, just different ip addresses and host names.

I installed VSFTPD and configured for passive ports. One box connects fine, no issues, however the second box continuously throws me this error:

GnuTLS error -15: An unexpected TLS packet was received.

Here is the debug FileZilla trace:

Status: Connecting to 192.168.20.68:21...
Status: Connection established, waiting for welcome message...
Trace:  CFtpControlSocket::OnReceive()
Response:   220 (vsFTPd 3.0.2)
Trace:  CFtpControlSocket::SendNextCommand()
Command:    AUTH TLS
Trace:  CFtpControlSocket::OnReceive()
Response:   234 Proceed with negotiation.
Status: Initializing TLS...
Trace:  CTlsSocket::Handshake()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnSend()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  TLS Handshake successful
Trace:  Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD
Status: Verifying certificate...
Status: TLS connection established.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    USER datamover
Trace:  CTlsSocket::OnRead()
Trace:  CFtpControlSocket::OnReceive()
Response:   331 Please specify the password.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    PASS *******
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::Failure(-15)
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Trace:  CRealControlSocket::OnClose(106)
Trace:  CControlSocket::DoClose(64)
Trace:  CFtpControlSocket::ResetOperation(66)
Trace:  CControlSocket::ResetOperation(66)
Error:  Could not connect to server

The error is always right after the password check.

I know the problem IS NOT SELinux, as I disabled that. The problem is also not the firewall, as I tried disabling the Firewall Daemon (firewalld).

Here is the relevant portion of the /etc/vsftpd/vsftpd.conf file.

listen=YES
listen_ipv6=NO
pasv_enable=YES
pasv_max_port=10100
pasv_min_port=10090
pasv_address=192.168.20.88

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
ssl_ciphers=HIGH
require_ssl_reuse=NO

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem

I did a Google search but did not see any 15 error codes.

Thoughts?

I had same error after PASS command in CENTOS 7. (GnuTLS error -15: An unexpected TLS packet was received.)

My solution is following:

I had to add following to vsftpd.conf:

allow_writeable_chroot=YES

chroot_local_user=YES 
local_root=/ftphome/$USER 
user_sub_token=$USER