Hello,
We are experiencing an issue when using the native FTP/FTPS entry in Remote Desktop Manager to connect to a FileZilla Server 1.12.6 instance.
The connection to the server succeeds and authentication completes successfully over the control channel.
However, when RDM attempts to retrieve a directory listing or transfer data, the operation fails with the following error returned by FileZilla Server:
425 Unable to build data connection: TLS session of data connection not resumed.
From our analysis, this appears to be related to TLS session resumption requirements enforced by FileZilla Server. The server expects the FTPS data channel to reuse the TLS session established on the control channel, which is a common security measure against certain FTPS attacks.
It seems that the native FTPS engine used by RDM may not be reusing or resuming the control channel TLS session when establishing the data connection, causing FileZilla Server to reject the data channel.
Any feedback or confirmation from other users would be greatly appreciated.
Thank you.
Hello,
Thanks for the detailed report It made this easy to check.
This is a known FileZilla Server issue, not something specific to RDM.
Newer FileZilla Server versions require the data connection to reuse the TLS session from the control connection.
When TLS 1.3 is used, that reuse depends on session tickets.
Most FTP client engines, RDM's included, do not yet support that specific reuse.
That gap is why FileZilla Server sends back the 425 error you saw.
FileZilla Server cannot turn this requirement off.
You can still change the TLS version it uses.
Open FileZilla Server's admin panel, go to TLS settings, and set the maximum version to 1.2.
TLS 1.2 uses the older session-ID method, which works with far more clients.
That change should let RDM connect through its native FTP entry again.
If TLS 1.3 must stay on for policy reasons, use an outside FTPS client, like FileZilla Client or WinSCP, launched from RDM.
We are logging this as a gap in our engine, so the team can consider TLS 1.3 support later.
I cannot promise a date for that yet.
Could you try TLS 1.2 on the server and tell us if that fixes the connection?
Best regards,
Carl Marien
Hello,
Thanks for the detailed report It made this easy to check.
This is a known FileZilla Server issue, not something specific to RDM.
Newer FileZilla Server versions require the data connection to reuse the TLS session from the control connection.
When TLS 1.3 is used, that reuse depends on session tickets.
Most FTP client engines, RDM's included, do not yet support that specific reuse.
That gap is why FileZilla Server sends back the 425 error you saw.
FileZilla Server cannot turn this requirement off.
You can still change the TLS version it uses.
Open FileZilla Server's admin panel, go to TLS settings, and set the maximum version to 1.2.
TLS 1.2 uses the older session-ID method, which works with far more clients.
That change should let RDM connect through its native FTP entry again.
If TLS 1.3 must stay on for policy reasons, use an outside FTPS client, like FileZilla Client or WinSCP, launched from RDM.
We are logging this as a gap in our engine, so the team can consider TLS 1.3 support later.
I cannot promise a date for that yet.
Could you try TLS 1.2 on the server and tell us if that fixes the connection?
Best regards,
@Carl Marien
Hello,
Thank you for your feedback.
We have checked the FileZilla Server configuration and the server is already restricted to TLS 1.2. TLS 1.3 is not enabled on this instance.