Hi, We have some applications hosted on Azure Virtual machine (Windows 2019 server). We are trying to connect to Azure Data Lake storage from this VM for data migration using this application. We verified the network connectivity and even checked at firewall logs and found there was no drop in the traffic. All looks to be good. But we are getting SSL Handshake failure/TLS connection error when we do a curl from this VM. ADSL is configured with a private endpoint and this VM is using a private IP (all services are internal): "curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed" Curl from our local machine to the ADSL endpoint works fine. We also captured the Wireshark logs to check which cipher suite is missing on the client (Azure VM) but unfortunately not receive 'server hello' to verify the ciphers from ADSL. Could you guide us if anything is missing from our side to fix this connection issue?

Hi Ravichandran, Gopi Krishna , The error could be due to several reasons, some possiblities that you can verify is: TLS Version Mismatch: The app on your Azure VM might be using an older version of TLS that is not supported by Azure Data Lake Storage (ADLS) and the handshake will fail( https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version ) Cipher Suite Mismatch: The client and server need to have a common cipher suite for the SSL/TLS handshake to be successfull ( https://techcommunity.microsoft.com/t5/azure-paas-blog/ssl-tls-connection-issue-troubleshooting-guide/ba-p/2108065 ) Azure VM Configuration: There could be an issue with the configuration of your Azure VM. [For example, if the VM is not TLS 1.2 compliant, you might experience SSL/TLS handshake. Ensure that your system's date and time are correct, as this can also cause SSL/TLS handshake Let me know if the information is helpful, nonetheless Can you share me the curl command used, to try to reproduce the error and help you better. Cheers, Luis

TLS/SSL Connection failed

Accepted answer

Luis Arias 7,131 Reputation points

2023-11-29T10:51:13.92+00:00
Hi Ravichandran, Gopi Krishna,

The error could be due to several reasons, some possiblities that you can verify is:

TLS Version Mismatch: The app on your Azure VM might be using an older version of TLS that is not supported by Azure Data Lake Storage (ADLS) and the handshake will fail(https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version)

Cipher Suite Mismatch: The client and server need to have a common cipher suite for the SSL/TLS handshake to be successfull (https://techcommunity.microsoft.com/t5/azure-paas-blog/ssl-tls-connection-issue-troubleshooting-guide/ba-p/2108065)

Azure VM Configuration: There could be an issue with the configuration of your Azure VM. [For example, if the VM is not TLS 1.2 compliant, you might experience SSL/TLS handshake.

Ensure that your system's date and time are correct, as this can also cause SSL/TLS handshake

Let me know if the information is helpful, nonetheless Can you share me the curl command used, to try to reproduce the error and help you better.

Cheers, Luis
Please sign in to rate this answer.
Ravichandran, Gopi Krishna 161 Reputation points

2023-11-29T12:19:59.31+00:00

Hi @Luis Arias

Thanks for sharing some reference links.

VM is compliant with the TLS 1.2 version. We suspect that it could be with the VM cipher suite configuration and not on the application. Because this application was installed on a local machine and tested. Handshake was successful.

I have shared the curl command below

curl --location https://mltestcommonsa.dfs.core.windows.net/projects?directory=customer_acquisition_analyses%2FRFM%2Foutput_SEIP%2F&recursive=false&resource=filesystem --header "x-ms-version: 2018-11-09" --header "content-length: 0" --header "Host: mltestcommonsa.dfs.core.windows.net"

Luis Arias 7,131 Reputation points

2023-11-29T12:31:09.07+00:00

I will try to reproduce the error , meanwhile this information could help you if its's VM cipher suite configuration (It could be updates):

https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v20h2

https://azure.microsoft.com/en-us/blog/azure-services-ssl-tls-cipher-suite-update-and-removal-of-rc4/

https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/deploy-custom-cipher-suite-ordering

Ravichandran, Gopi Krishna 161 Reputation points

2023-11-29T13:48:42.9533333+00:00

Below are the message from Wireshark and not receiving response from ADSL.

Screenshot 2023-11-29 at 13.40.33.png

Screenshot 2023-11-29 at 13.40.41.png

Below is simple curl response from the VM

* Connected to mltestcommonsa.dfs.core.windows.net (10.XX.XX.XX) port 443 * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * schannel: failed to receive handshake, SSL/TLS connection failed * Closing connection * schannel: shutting down SSL/TLS connection with mltestcommonsa.dfs.core.windows.net port 443 curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

Ravichandran, Gopi Krishna 161 Reputation points

2023-12-01T07:35:29.0166667+00:00

Hi @Luis Arias

Were you able to reproduce the situation? Any updates.

/Gopi

Luis Arias 7,131 Reputation points

2023-12-04T18:42:23.4466667+00:00

Hi Ravinchadran, I did some test with different tls versions, including Vms and external machine , however I cannot replicate your environment.
Did you try from another VM in azure ? Is that working?

Ravichandran, Gopi Krishna 161 Reputation points

2023-12-04T20:25:02.8666667+00:00

Hi Luis,

I did the following things to check if I could narrow down the problem. Sadly, I did not find the cause.

Created a VM in a sandbox environment and could connect the ADSL seamlessly.

Verified network connectivity using connection monitoring from the VM to this ADSL and the probe succeeded. Although, the routing occurs in between two firewalls (no block in both firewalls).

Also, tried to connect any other ADSL residing in a different subscription, unfortunately, it is the same issue. These two ADSLs are behind the private endpoints integrated into a VNET (subnet).

This VM returns a curl response for the Storage account that is on public network access enabled as well as those in the same subscription.

/Gopi

Ravichandran, Gopi Krishna 161 Reputation points

2023-12-08T09:44:05.48+00:00

Hi @Luis Arias

I figured out the problem. We are using Azure firewall with only network rules and not application rules.

I think SSL/TLS Handshakes are verified at layer 6 or 7 in OSI model and Azure firewall is smart to sense that there is no rule defined in Firewall at Application rule.

After enabling the Application rule defining the source and destination FQDNS (of *.dfs.core.windows.net) then SSL/TLS handshake is established.

I am trying to understand the difference between the Network rule and the application rule and what will happen when the same rule is added to both Network/Application rules.

Luis Arias 7,131 Reputation points

2023-12-08T11:06:02.3333333+00:00

Hi Ravichandran, Gopi Krishna,

Good to know that you already fix your error. About the difference beetween Network rules in Azure Firewall and Application rule, the first one operate at the transport layer (Layer 4) of the OSI model and allow or deny traffic based on protocol, source IP, destination IP, and destination port. They do not take into the SSL verification for example.

So, if you add a rule as a network rule for the domain of a storage account, it won’t work as expected because network rules do not evaluate domain names. You should use an application rule for this purpose.

On the other hand about the processing Rule on Azure firewall:

https://learn.microsoft.com/en-us/azure/firewall/rule-processing

https://learn.microsoft.com/en-us/azure/firewall/threat-intel

https://learn.microsoft.com/en-us/azure/firewall/fqdn-filtering-network-rules

Based on that the Azure Firewall processes rules in a simplified flow:

DNAT Rules: If a match is found, the traffic is translated according to the DNAT rule and allowed by the firewall.

Network Rules: Network rules are applied next. If a match is found in network rules, then application rules aren’t processed.

Application Rules: If no network rule matches, and if the packet protocol is HTTP/HTTPS, application rules then evaluate the packet.

If no match is found in any of the rules, then the packet is denied by default.

This is the basic explanation your actual rule processing logic can be more complex, especially when is used Azure Firewall Manager or when rules are inherited from a parent policy.

I hope this help you.

Ravichandran, Gopi Krishna 161 Reputation points

2023-12-08T11:48:28.3066667+00:00

Thanks, @Luis Arias for clarifying the differences. I will explore more about this.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

TLS/SSL Connection failed

0 additional answers

Your answer