FTP connection using Vnet integration

[jahnwa]

Investigative information

We deployed a Azure Function using 2.2 runtime in November that connects to our FTP server using Vnet integration + Vnet peering. When we use this runtime we are able to connect to the server.

Keeping the app setting FUNCTIONS_EXTENSION_VERSION: ~2 causes the function to not being able to reach the FTP server through private IP. We see no sign of a connection in the NSG flow logs/FTP logs of a connection. However, we are able to connect to the FTP server through its public IP.

On our production function app we have tried upgrading to FUNCTIONS_EXTENSION_VERSION: ~3 and also the SDK. This did not fix the issue.

We are able to use kudu console and tcpping to our FTP server using the private IP regardless of ´FUNCTIONS_EXTENSION_VERSION´

For our test function that tried to run on FUNCTIONS_EXTENSION_VERSION: ~2

• Timestamp:2021-01-28T09:43:00.023
• Invocation ID: 32928a8e-c720-4489-a9d9-8251ca83e986
• Region: North Europe

For our production function that run on FUNCTIONS_EXTENSION_VERSION: ~3

• Timestamp: 2021-01-27T13:00:00.097
• Invocation ID: 65b597ee-43c7-4c58-89c4-f66f9a1d1415
• Region: North Europe

Repro steps

1. Set up function on a P2v2 plan
2. Set up VM that allows for ftp connection at port 21
3. Create a new Vnet and setup Vnet-peering
4. Integrate function app with Vnet
5. Use FUNCTIONS_EXTENSION_VERSION: ~2 while attempting to connect to VM.

Expected behavior

We expect that, since we are not affected by any breaking changes in 3.1, that it should still function.

Actual behavior

Upgrading function version causes our function app to fail.

Known workarounds

Opting out of the upgrade, setting FUNCTIONS_EXTENSION_VERSION: ~2.0, fixes the issue.

Related information

Source

```csharp string ftpDirectory = "ftp_server_address"; string userName = "ftp_server_username", password = "ftp_server_password"; FtpWebRequest listDirRequest = (FtpWebRequest)WebRequest.Create(ftpDirectory); listDirRequest.Method = WebRequestMethods.Ftp.ListDirectoryDetails; listDirRequest.Credentials = new NetworkCredential(userName, password); using (FtpWebResponse response = (FtpWebResponse)listDirRequest.GetResponse()) using (Stream responseStream = response.GetResponseStream()) { if( null == responseStream ) throw new Exception( "responseStream is null" ); using (StreamReader reader = new StreamReader(responseStream)) { log.LogInformation( "Succeeded" ); } } ```

[pragnagopa]

Tagging @fabiocav for follow up.

[pragnagopa]

Assigning to Sprint 96 for further investigation.

[fabiocav]

@jahnwa this might take some additional time for investigation. Have you tried updating your Functions project to target .NET 3.1? Do you have the same results if you redeploy with that target?

[jahnwa]

@fabiocav We have tried updating our Functions project to target .NET 3.1 and we experience the same issue. It only works as expected when we force the app to use .NET Core 2.2.

[brettsam]

I've been researching a very similar issue with SmtpClient on the auto-upgrade and I wonder if this will work?

https://github.com/MicrosoftDocs/azure-docs/issues/45991#issuecomment-755582909

@jahnwa -- would you be able to test setting the app setting WEBSITE_VNET_SUPPORT_DUAL_STACK_SOCKETS to 1 and moving to 3.1 again?

[jahnwa]

@brettsam This has solved our issue! Thank you!

Just a quick question. Will this app setting be a default setting in the future?

Please feel free to close this issue.

[fabiocav]

@jahnwa glad to hear this is working for you. We'll see what we can do to make this process simpler and avoid a configuration change.