PureFTPd Connection Problem on Virtual Server with Ubuntu 20.04/ISPConfig 3

Hi, this might be a bit tricky, but maybe someone can give me a hint or has allready some experience with this kind of problem:

Hoster in this Case is HostEurope in Germany and the Package is a so called Virtual Server 10+ with Ubuntu 20.04 and 2 necessary services (Nydus and Panopta) installed, that must be kept running. I installed as usually...Perfect Server with Apache for Ubuntu and ISPConfig and opened passive ports for FTP.

Everything is running fine, but when I'm connected over WinSCP (SFTP-3, SSH-2, OpenSSH_8.2p1, AES-256 SDCTR) and try to upload more than 100 files at once, it might happen once in a while, that the connection first goes down 1-2 seconds and then gets disconnected. Reconnecting is no problem and the upload seems to continue where it ended, but this is not, what I would like to put my trust in.

Even worse, if I try to connect with PHPFirestorm, the connection gets lost (QUIT) often directly after LIST:
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication

I already thougt, this might be because PHPFirestorm is expecting a binary connection as on other servers before:
150 Opening BINARY mode data connection for file list
On this server the connection only sometimes comes up with:
200 TYPE is now 8-bit binary
But then again after entering passive mode and LIST the connection gets lost again.

Any idea, what could be a reason for these disconnects...any idea where I could take a deeper look, maybe syslog, so I should be able to see, whats going wrong?

 

Hi Till,
ok, the difference between SFTP and FTP makes sense, sorry for combining it. However, pureFTPd and ISPConfig are already configured for use/allowing passive mode over 40110-40210, but I will ask HostEurope, if there is any kind of firewall in the back that influences the traffic twice.

Maybe another thing to mention: The server only has got an IPv4 to use (no IPv6), but "ip addr show" comes up on eth0 with showing my inet IPv4 and inet6 with an internal IPv6 fe80::5054:7cff:feaf:cf28/64.

"netstat -tanp|grep 21" tells me, pureFTPd is listening for tcp and tcp6 connections, and "ufw status" tells me, that 40110:40210 is opened for both tcp and tcp (v6).

However, if I use Filezilla and try to download a folder with 10.000 smaller Images, every 150-200 downloads it comes up with a disconnect/reconnect like this:

Code:

Status:    Dateiübertragung erfolgreich, 11,2 KB in 1 Sekunde übertragen
Befehl:    PASV
Antwort:    227 Entering Passive Mode (xxx,xxx,xxx,xxx,156,225)
Befehl:    RETR 1486741503667.jpg
Antwort:    150-Accepted data connection
Antwort:    150-The computer is your friend. Trust the computer
Antwort:    150 18.3 kbytes to download
Fehler:    Konnte vom Socket nicht lesen: ECONNRESET - Verbindung durch Peer zurückgesetzt
Fehler:    Verbindung zum Server getrennt
Fehler:    Dateiübertragung fehlgeschlagen
Status:    Starte Download von /teamarea/api/gfx/uploaded/320/1636628731392.jpg
Status:    Auflösen der IP-Adresse für srv.mts-gruppe.com
Status:    Verbinde mit xxx.xxx.xxx.xxx:21...
Status:    Verbindung hergestellt, warte auf Willkommensnachricht...
Status:    Dateiübertragung erfolgreich, 10,2 KB in 1 Sekunde übertragen

...after this, it goes on for another 150-200 files and so on. At the end - after downloading all files, so I guess that's ok - it comes up with:

Code:

Status:    Verbindung zum Server getrennt
Antwort:    421 Timeout - try typing a little faster next time
Fehler:    GnuTLS-Fehler -110 in gnutls_record_recv: The TLS connection was non-properly terminated.
Status:    Server hat die TLS-Verbindung nicht ordnungsgemäß geschlossen
Fehler:    Konnte vom Socket nicht lesen: ECONNABORTED - Verbindung abgebrochen
Fehler:    Verbindung zum Server getrennt

Could the missing IPv6 be a reason for this? I tried to configure pureFTPd with another Option/conf-file "ForcePassiveIP" and put my IPv4-Adress inside, but this didn't help either.

I tried to upload about 1.300 of these files after the download and there was no error at all. Redownloading, however, disconnected the transfer again periodly and deleting the folder from the server broke after maybe 500 files by listing all the files that could not be deleted because they could not be found....not funny.