Sqlclient: .NET Core 3.0 Docker Container Won't Connect to SQL Server

Created on 26 Sep 2019  Â·  53Comments  Â·  Source: dotnet/SqlClient

.NET Core 3.0 Docker Container Won't Connect to SQL Server

We have upgraded some of our .NET Core 2.2 applications to .NET Core 3.0. After the upgrade, our applications running in Docker containers fail to connect to SQL Server 2016 running on a standalone machine in our domain network. Reviewing the packet trace, we see that the connection hangs at the Pre-Login handshake, and eventually times out. Switching back to .NET Core 2.2 resolves the issue immediately, and our containers can again connect to our databases.

We have obviously verified that there are no DNS issues, since these containers are running in production with .NET Core 2.2. .NET Core 3.0 breaks them as they cannot connect to SQL Server over the network, so we are rolling back to 2.2 for now and terminating the upgrade until we can determine why .NET Core 2.2 containers connect to our SQL Servers but .NET Core 3.0 containers do not.

We have also created new .NET Core 3.0 projects from scratch to test the connection. The result is the same: the containers time out during Pre-Login to SQL Server. Changing the project back to .NET Core 2.2, along with EF Core back to 2.2.6, and the issue is immediately resolved.

As we are using EF Core for data access, we have also tried leaving EF Core at 2.2.6 but upgrading the project to .NET Core 3.0, but the connection still times out.

If we do not add Docker support and run the apps as Console or Web apps (not containerized), then there are no issues with .NET Core 3.0. It is only when we containerize them that .NET Core 3.0 apps fail to connect to SQL Server.

Per suggestion in Stack Overflow, I changed the data access in the test project to Microsoft.Data.SqlClient using hand-written SQL and a DataReader. I then recreated the Dockerfile for .net core 3.0 and verified that the correct container image was referenced. Same behavior: hung at PreLogin handshake with SQL Server. Switched to .net core 2.2 and was able to connect and read data from SQL Server.

External

Most helpful comment

@StijnStaelens can you please try:

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

All 53 comments

We have the same issue:
Microsoft.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught) ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL. ---> Interop+Crypto+OpenSslCryptographicException: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol

@MichaelSimons might have some insight.

@StijnStaelens What docker container image is being used?

mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim

and

mcr.microsoft.com/dotnet/core/runtime:3.0-buster-slim

both hang on pre-login handshake, switching back to their 2.2 counterparts is only solution we have been able to find.

here is the top section from Dockerfile from a Web API container that will not connect unless we flip it back to 2.2:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build

@bartonjs could this be Buster raising their OpenSSL TLS security level to 2 for OpenSSL 1.1?

So that image has:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

in /etc/ssl/openssl.cnf.

I would be curious if adding this to your Dockerfile improves the situation:

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf

Then rebuild your image and run.

This may explain the error that @StijnStaelens is seeing more than a hang.

Yep, it's probably the SECLEVEL.

Alternatively, you could try a different Docker image base like Ubuntu Bionic, which isn't quite as fast-paced as Debian is to more aggressive TLS configuration.

@vcsjones I tried the extra command, but it still doesn't work. My dockerfile now looks like this
`
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS builder
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
WORKDIR src

COPY ./project.csproj .
RUN dotnet restore ./project.csproj
COPY . .
RUN dotnet publish ./project.csproj --configuration Release

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
COPY --from=builder src/bin/Release/netcoreapp3.0/publish/ app
WORKDIR app

ENTRYPOINT ["dotnet", "project.dll"]
`

My code works fine when I run it on windows, in Docker it fails

Using mcr.microsoft.com/dotnet/core/aspnet:3.0-bionic worked.

@StijnStaelens hm. You're using different base images from @jeffgbradley2, I'll examine those.

What version of SQL server are you connecting to?

@vcsjones,
We tried with 2 servers. 1 is 'Microsoft SQL Server Web 2017 (64-bit)'. The other is a 'Microsoft SQL Server Web 2012 (64-bit)'. Both failed. These are both self-hosted and we try to connect with this connectionstring:
Password=xxxxx;Persist Security Info=True;User ID=xxxxxx;Initial Catalog=xxxxxx;Data Source=1xx.xxx.xxx.xxx;

@StijnStaelens can you please try:

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

We have confirmed that switching to Bionic fixes the issue.

Switching to bionic fixed our issue for asp.net core, but not for console containers. For console containers, after switching to bionic we get the following:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

Here is snippet from Dockerfile:

FROM mcr.microsoft.com/dotnet/core/runtime:3.0-bionic AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-bionic AS build
WORKDIR /src

@jeffgbradley2, can you make sure you have the latest version of the images pulled locally? If you have a previous version cached, you must explicitly pull the images to get any updates.

Another way to validate would be to run docker run -it --rm mcr.microsoft.com/dotnet/core/runtime:3.0-bionic dotnet --list-runtimes

This is happening locally and in our CICD pipeline.

Running that command is what I and our Devops group expect to see.

@jeffgbradley2 - I'm confused. You said:

For console containers, after switching to bionic we get the following:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.

  • No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

What do you mean by console container? Are you saying it is a containerized console app? Why is your console app depending on aspnet?

@jeffgbradley2 , I'm not following. Your screen shot shows Microsoft.NETCore.app which is what I expect for a console app. The error you included was for the Microsoft.AspNetCore.App.

This looks to me like there are two different issues here. The original report is about a hang. A different person (@StijnStaelens ) reported a pre-login handshake error.

I think it's doubtful that TLS implementation would be responsible for the hang, although I guess it's possible. The hang is probably the same as #22, #165, or #201

We're experiencing this hang and it's stopping us from deploying .NET Core 3 across our infra.

@jeffgbradley2 your CI troubleshooting sure is making a lot of noise in this issue, and an error about "not possible to find any compatible framework version" sure isn't related to the issue re: connecting to SQL server.

@StijnStaelens can you please try:

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

@vcsjones , I now used the standard image mcr.microsoft.com/dotnet/core/aspnet:3.0 (that didn't work before) and added those commands. Now it seems to work.

Should this issue have been closed or should it be left open? The end user experience doesn't feel optimal to me. This is going to affect a lot of users, how are they going to know how to address the problem? Downgrading the seclevel feels like a patch. What changes need to be made to work with seclevel2?

What changes need to be made to work with seclevel2?

This is ultimately a problem of the SQL server that is being connected to. The snippet I posted does two things: it lowers the required TLS version, and adjusts the SECLEVEL down to one.

For changing the minimum TLS version from 1.2 to 1.0, if this fixed the problem, then the SQL server needs to be patched and configured to use TLSv1.2 as described in this support article. I'm a bit out of my comfort zone with SQL Server + TLS.

If the SECLEVEL change was the source of the fix, then then this could be a few things, such as RC4 being used, or DHE-1024 getting used.

@StijnStaelens If you could help answer one more question, that'd be great. Given these two fixes:

1:

RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/DEFAULT@SECLEVEL=2/DEFAULT@SECLEVEL=1/g' /usr/lib/ssl/openssl.cnf

and

2.

RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

Do either of these resolve the issue without the other? That is, can you use 1 without 2 and it still works? Can you use 2 without 1 and does it work? Or does it only work with both 1 and 2?

@vcsjones

RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

These commands alone worked.

@StijnStaelens thanks you! Based on your experiment, it seems that your SQL instances do not support, or have enabled, TLSv1.2.

You can continue to change the minimum version of TLS to v1.0, which is what those commands are doing, or you can enable TLSv1.2 on your SQL server instances, then the configuration change in the containers will not be necessary. As far as I am aware, there are two steps for TLSv1.2 needed in the SQL server. Install any necessary patches, and enable it in configuration, both of which are covered in the support article.

Changing your docker file to this fixed the issue for me:
FROM mcr.microsoft.com/dotnet/core/runtime:3.1-bionic AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-bionic AS build

I had similar issue connecting to remote sql server from linux .net core web app. I was able to make it work by adding "Connect Timeout=60" to the connection string.

I can also confirm that using the following image fix the issue:
FROM mcr.microsoft.com/dotnet/core/runtime:3.0-bionic

I spent the better part of three days fighting with this same issue before finding this ticket. Switching my Dockerfile to use the 3.1-bionic images instead of 3.1-buster and 3.1-buster-slim allowed me to connect to external SQL Server databases using SqlClient; previous attempts would hang indefinitely.

Can anyone offer any insight into what the underlying problem is? Is there an issue with the buster variants or is there some network issue that Ubuntu-based images are not sensitive to? Before switching the image, none of the TLS-related commands described above made any difference.

Using mcr.microsoft.com/dotnet/core/aspnet:3.0-bionic worked.

You sir, you made our day ! 3.1-bionic images works for us .

I still have the connection problem even with
mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic

and this command

RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /etc/ssl/openssl.cnf
RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/g' /usr/lib/ssl/openssl.cnf

I am using a the standard aspnetcore3.1 image from the sample
https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/Dockerfile

Does anyone know what is the issue?
Btw I'm trying to connect my container to a remote azure sql instance.

And here is the exception I'm getting

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)

@reggieboyYEAH I'm have the same issue. My Kubernetes cluster runs on Ubuntu 18.04. My SQL Server is 2016 running on a standalone machine. I try to connect with an ASP.NET Core 3.1 api to this sql server.
My docker file is this:

See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY *.csproj ./
RUN dotnet restore
COPY . .

WORKDIR "/src/MyFirstDockerApi"

RUN dotnet build "MyFirstDockerApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "MyFirstDockerApi.csproj" -c Release -o /app/publish

FROM base AS final
RUN sed -i '/^ssl_conf = ssl_sect$/s/^/#/' /etc/ssl/openssl.cnf
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyFirstDockerApi.dll"]

My connectionstring looks like this: Server=someip,1433;Database=datebasename;User=username>;Password=password;MultipleActiveResultSets=True

When I run this application on my Docker Desktop cluster, I can sucessfully connect. But when I deployed run this image at my Ubuntu cluster connecting to the same database server, the connection fails.

The error message I receive is:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server) Inner exception [A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)]

The firewall is diabled. It seems my Kubernetes blocks outgoing traffic but I can't figure out what the problem is.

@reggieboyYEAH I'm have the same issue. My Kubernetes cluster runs on Ubuntu 18.04. My SQL Server is 2016 running on a standalone machine. I try to connect with an ASP.NET Core 3.1 api to this sql server.
My docker file is this:

See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY *.csproj ./
RUN dotnet restore
COPY . .

WORKDIR "/src/MyFirstDockerApi"

RUN dotnet build "MyFirstDockerApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "MyFirstDockerApi.csproj" -c Release -o /app/publish

FROM base AS final
RUN sed -i '/^ssl_conf = ssl_sect$/s/^/#/' /etc/ssl/openssl.cnf
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyFirstDockerApi.dll"]

My connectionstring looks like this: Server=someip,1433;Database=datebasename;User=username>;Password=password;MultipleActiveResultSets=True

When I run this application on my Docker Desktop cluster, I can sucessfully connect. But when I deployed run this image at my Ubuntu cluster connecting to the same database server, the connection fails.

The error message I receive is:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server) Inner exception [A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)]

The firewall is diabled. It seems my Kubernetes blocks outgoing traffic but I can't figure out what the problem is.

I have a similar issue. Have you solved the problem?

No, not yet

Outlook voor Android downloadenhttps://aka.ms/ghei36


From: albeserra notifications@github.com
Sent: Wednesday, April 1, 2020 3:38:16 PM
To: dotnet/SqlClient SqlClient@noreply.github.com
Cc: marcelbeeker marcelbeeker72@hotmail.com; Comment comment@noreply.github.com
Subject: Re: [dotnet/SqlClient] .NET Core 3.0 Docker Container Won't Connect to SQL Server (#222)

@reggieboyYEAHhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FreggieboyYEAH&data=02%7C01%7C%7C37cc7a94aec24e3fc8c008d7d641f0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637213451000875325&sdata=qMb7vzJpndbTg9sdS5LSxSl0uXrEBLiK2PHwrrMTvOs%3D&reserved=0 I'm have the same issue. My Kubernetes cluster runs on Ubuntu 18.04. My SQL Server is 2016 running on a standalone machine. I try to connect with an ASP.NET Core 3.1 api to this sql server.
My docker file is this:

See https://aka.ms/containerfastmodehttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fcontainerfastmode&data=02%7C01%7C%7C37cc7a94aec24e3fc8c008d7d641f0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637213451000885350&sdata=3PYk74kPjgDYtNuZga2I26LKz1ylO%2Bc3aLEO%2BjJTKOA%3D&reserved=0 to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY *.csproj ./
RUN dotnet restore
COPY . .

WORKDIR "/src/MyFirstDockerApi"

RUN dotnet build "MyFirstDockerApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "MyFirstDockerApi.csproj" -c Release -o /app/publish

FROM base AS final
RUN sed -i '/^ssl_conf = ssl_sect$/s/^/#/' /etc/ssl/openssl.cnf
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyFirstDockerApi.dll"]

My connectionstring looks like this: Server=someip,1433;Database=datebasename;User=username>;Password=password;MultipleActiveResultSets=True

When I run this application on my Docker Desktop cluster, I can sucessfully connect. But when I deployed run this image at my Ubuntu cluster connecting to the same database server, the connection fails.

The error message I receive is:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server) Inner exception [A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)]

The firewall is diabled. It seems my Kubernetes blocks outgoing traffic but I can't figure out what the problem is.

I have a similar issue. Have you solved the problem?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2FSqlClient%2Fissues%2F222%23issuecomment-607254704&data=02%7C01%7C%7C37cc7a94aec24e3fc8c008d7d641f0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637213451000895353&sdata=3HgeReL9c3EPn8KuQDDYQsmvCxwPMy36veZLb%2BXNPDc%3D&reserved=0, or unsubscribehttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAENYSNQQ2A4BVIUCS7TIUITRKM7URANCNFSM4I26TWZQ&data=02%7C01%7C%7C37cc7a94aec24e3fc8c008d7d641f0ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637213451000895353&sdata=pm8od%2FLG1DLn6j4beY7taUBet%2F6593DvWCAut9FkbeQ%3D&reserved=0.

@albeserra @marcelbeeker I tested today with the latest image. But the issue is not solved yet.
Have you guys figured it out?

@albeserra @marcelbeeker I tested today with the latest image. But the issue is not solved yet.
Have you guys figured it out?

not yet... :(

I am seeing this issue with mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1903 . I can't connect to a remote SQL server. In my case it is Azure. Any updates on this issue? I want to run a windows container.

My problem is solved. I have added an egress rule in my Calico config. Now I can connect to both the internet as SQL Server without any problem.

Outlook voor Android downloadenhttps://aka.ms/ghei36


From: Arra Derderian notifications@github.com
Sent: Thursday, May 7, 2020 4:45:24 AM
To: dotnet/SqlClient SqlClient@noreply.github.com
Cc: marcelbeeker marcelbeeker72@hotmail.com; Mention mention@noreply.github.com
Subject: Re: [dotnet/SqlClient] .NET Core 3.0 Docker Container Won't Connect to SQL Server (#222)

I am seeing this issue with mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1903 . I can't connect to a remote SQL server. In my case it is Azure. Any updates on this issue? I want to run a windows container.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2FSqlClient%2Fissues%2F222%23issuecomment-624996925&data=02%7C01%7C%7Cca599e1188f4408eea3e08d7f230b193%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637244163254963048&sdata=ellUCuPEMyIjPcy%2B1dNcc9kSGwzsuS63F%2B5wRy9nu0A%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAENYSNSHPQO6SZ5WFVXWBX3RQIOEJANCNFSM4I26TWZQ&data=02%7C01%7C%7Cca599e1188f4408eea3e08d7f230b193%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637244163254963048&sdata=XZZHOMExVB2wRTTAJJ9jKaEHQ%2BP9J14D%2F2gD4HK4Kuo%3D&reserved=0.

My issue seems to be related to the GlobalProtect gateway as well. It only works when I am on my VPN. Somehow this adapter is conflicting with DNS even when I disable it or change the interface metric order.

Any update about it ?
I tried using 3.1-bionic image but I got the same exception when there is huge number of request (like 3000 per min.)

A connection was successfully established with the server, but then an error occurred during the pre-login handshake.

Hi!
I have also created new .NET Core 3.1 projects to test the connection to my DB (Microsoft SQL Server 2008 R2 SP1). The result: the containers time out during Pre-Login to SQL Server. I changed the project to .NET Core 2.2 with EF Core 2.2.6, but it didn't help me.

It works without modification on
mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic
but does not work on
mcr.microsoft.com/dotnet/core/aspnet:3.1-focal

It works without modification on

mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic

but does not work on

mcr.microsoft.com/dotnet/core/aspnet:3.1-focal

Make a load test just like I did. 200-300 request per second and you will see that it will start throwing handshake exception. But if your app does not consume such number of request most probably you will not see any exception.

I suggest people look to see if they have a VPN connection or another connection that could potentially be messing with this. I had a GlobalProtect VPN that must have had some routing rules in place even when disabled. I have to have it on for it to work now, despite changing the order of the connection. I didn't have time to solve it further, this was the fix for now.

It works correct without docker.
It doesn't work in mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic too.

It works without modification on
mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic
but does not work on
mcr.microsoft.com/dotnet/core/aspnet:3.1-focal

Make a load test just like I did. 200-300 request per second and you will see that it will start throwing handshake exception. But if your app does not consume such number of request most probably you will not see any exception.

I tried with jmeter (number of threads is 300). It still works without exception. My app is a form submitting app which insert the form data to sql through ef core. It is running on aks with 1 pod and my sql server is "Microsoft SQL Server 2012 (SP3)".

I tried to re-build and deploy the image with 3.1-focal and it is stopped working in the first round.

Use mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic instead of
mcr.microsoft.com/dotnet/core/aspnet:3.1-buster
It works for me

use this image FROM mcr.microsoft.com/dotnet/core/runtime:3.1-bionic AS base
works for me too thx

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic
It works for me !

Im having the same issue. Im using the mcr.microsoft.com/dotnet/core/aspnet:3.1 image and trying to connect to a 2012 SQL Server. Problem started after upgrading from .net core 2.1 to 3.1. On my local machine (windows) I cannot reproduce the issue!

It Works for me thanks

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic
It works for me too

Was this page helpful?
0 / 5 - 0 ratings