FluentFTP: Cannot connect to FTPS IIS server on windows 2019 from Azure functions V4
FTP Server OS: Windows
FTP Server Type: Windows Server IIS
Client Computer OS: N/A
FluentFTP Version: 46.0.2
Framework: .NETCore 3.1
There’s an issue connecting to FTPS IIS server on Windows 2019 from Azure functions v4 running on .NETCore3.1. The SSL handshake seems to be timing out.
The error from the library is : Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host .
On checking the network traces we noticed Client key exchange is not getting initiated somehow.
The issue doesn’t seem to happen on functions V3 and also doesn’t happen on .NET5 and above.
Code:
var client = new AsyncFtpClient(host: "www.anand-server.com", port: 21, user: "<user>", pass: "<pass>");
client.Config.EncryptionMode = FtpEncryptionMode.Explicit;
client.LegacyLogger = (level, msg) => log.LogInformation(msg);
await client.Connect();
var response = await client.GetListing("/");
We tried with a different FTP library and it can connect successfully.
Logs :
[2023-05-04T04:54:09.133Z] > Connect(False)
[2023-05-04T04:54:09.134Z] Status: FluentFTP 46.0.2.0
[2023-05-04T04:54:09.148Z] Status: Connecting to IP #1= ***:21
[2023-05-04T04:54:09.389Z] Status: Waiting for a response
[2023-05-04T04:54:09.620Z] Response: 220 Microsoft FTP Service [738643.204d]
[2023-05-04T04:54:09.632Z] Status: Detected FTP server: WindowsServerIIS
[2023-05-04T04:54:09.641Z] Command: AUTH TLS
[2023-05-04T04:54:09.649Z] Status: Waiting for response to: AUTH TLS
[2023-05-04T04:54:09.916Z] Response: 234 AUTH command ok. Expecting TLS Negotiation. [269ms]
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 67 (1 by maintainers)
I am back in the office and have more resources here to check.
Yes, here two weeks ago I mentioned this:
https://github.com/robinrodricks/FluentFTP/issues/1251#issuecomment-1540902083
But of course the magnificient idea of yours to test this in your environment. Because in my test environment(s), it was not the cause of any problems.
Here are some more comments about this:
On the control connection, (of course this is SSL protected), there is by standard no buffering, even if in config (default) it is being requested.
On the data connection, buffering is disabled in some cases: a). you have configured it to not be enabled, b.) .NET 5.0+ c.) proxy d.) NOOPs requested
You can set the buffering using
...Config.SslBuffering.After some digging, I think I know where the issue is. So it looks like the issue is when we use
BufferedStreamwith SslStream. So basically when I use this line in the test program it also hangs.Also when I change https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP/Streams/FtpSocketStream.cs#L1481 to use NetworkStream always it is able to connect too.
@FanDjango any specific reason we need BufferedStream in case of netstandard? If not could we make a quick fix please?
@anandgmenon
Not sure I am thinking along the same path.
You compile/build the App for target .NET Core 3.1 and manually choose to provide alongside with it: the FluentFTP .dll that was made for .NET Standard 2.0.
The code that is compiled (the compiler paths taken via #if, #endif etc.) are done at compile time.
It works natively on your system, under functions V4 it hangs. In both cases, the executed code will be the same. Only in the second case, this code does something that hangs.
Perhaps under functions V4 the SslStream implementation is actually different than expected by the code, which was compiled “some time ago” under the premiss that it would run with a suitable runtime.
But then the simple program “bottom branch” with “only manual” creation of the SslStream and then authorization should also hang? Well, no, because in our test program, we are not calling from “compiled for .NET Core 3.1” to “compiled for .NET Standard 2.0”.
We are actually staying “inside” our “.NET Core 3.1” island. Which is not the same. We need to make a “.NET Standard 2.0” mini - dll, which mimiks the setup when using FluentFTP.
Up to now, the tests were to find out if there is something “special and bad” that FluentFTP is doing, and nothing was found.
Now, a step further. I am not ready yet though, but soon. Making the “mini - dll” is not a big thing but I was busy with some other stuff.
I doubt this too, I will try to build this repo locally and debug with my setup to analyze this further
So, still searching for possible differences.
One thing I can see from your latest log is the question of “Buffered Stream” (it is not being disabled), which is probably being enabled on top of the streams in this scenario.
To check this out I will need some more time.
For that one would need to perhaps compare wireshark timestamps and traffic sequences between Azure functions v4 running on .NETCore3.1 and functions V3 OR .NET 5 and above for the handshake traffic. as a first step.
Oh there was nothing much after that, bunch of TCP keep alive messages and the session was closed. I can provide the full trace if needed
Oh I have a feeling this has nothing to do with certificates loaded. Is there any issue with running GnuTLS on 32 bit process? Becaue this is the error I see
I used the new nuget and the original code is working fine. Thanks for the quick fix 😃
I have released FluentFTP.GnuTls Version 1.0.11, which fixes this issue by loading the X509 System Trust list, thus a trusted certificate list is no longer missing and the certificate will be accepted without any further measures.
Thanks for reporting this.
Please update to the new Nuget and it should work for you with the original code.