In TLS/SSL protocol, the client announces a list of supported ciphers to the server, and the server is supposed to pick one that it considers acceptable.
These are two likely explanations for the issue you encountered:
a) Rebex FTP client did not announce support for any cipher that the server would consider sufficient. Therefore, the server only accepted the connection to be able to inform the client about the problem. (This could easily occur with .NET Compact Framework edition of Rebex FTP, where DHE_ ciphers are disabled by default.)
b) Rebex FTP client did announce support for ciphers that the server would consider sufficient. However, instead of selecting one of them, the server negotiated another cipher. (In this case, you would have to ask the server vendor or administrator about why they negotiate a cipher they later reject instead of a more suitable one.)
If you would like to determine whether any of these possible explanation applies to your scenario, please create a communication log using Ftp object's LogWriter property and see which suites were actually announced (in 'Applicable cipher suites' log entry). If you prefer, post the log here or mail it to email@example.com for analysis.
(If the issue persists even when you assign
Ftp.Settings.SslAllowedSuites, that would suggest explanation (b)).