Develop Reference

Cannot connect to SQL from DotNet Core via VPN

I've tried solving this problem for days now, so I'm trying here to see if anyone have any more ideas to try.
I can connect fine to my local SQL Express, but when trying to connect to SQL located at two different companies with separate VPNs, I can't from .NET Core / VS Code / dotnet.exe.
I have this problem on a new laptop provided by my employer.
What I've tried so far to solve this:
Checked the ConnectionString a 1000 times
Tried from my personal stationary computer with the same applications and connected to VPN, works fine
Connected from Microsoft SQL Server Management Studio, works fine, same SQL account used as in ConnectionString
Checked server ports with PortQueryUI.exe: UDP port 1434 is LISTENING, TCP port 1433 (ms-sql-s service): LISTENING
Tried with IP in ConnectionString prefixed with "tcp:" and/or suffixed with ",1433"
Downgraded .NET Core SDK to use 2.1.1 (same as stationary computer), down from 2.1.16, same errors
Opened outgoing and incomming TCP 1433 and UDP 1434 in Windows firewall
Added VSCode and dotnet.exe to allowed applications in Windows firewall
Both wireless network and VPN connection is set to "Private"
Ran VSCode as Administrator (and not)
Tried both User version and Computer version of the installation
Verified that the ConnectionString in appSettings.json is actually used when running code (inspected while debugging)
ConnectionString format:
"DefaultConnection": "Server=<IPToServer>;Database=<DBName>;User ID=<UserName>;Pwd=<Password>"
Neither is a named instance, one is SQL Express, one is SQL Server.
Error without tcp::
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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
System.ComponentModel.Win32Exception (1326): The user name or password is incorrect
But the Username and Password is not incorrect. I get that message from MSSMS when switching to Names Pipes too, but when changing to TCP, I can connect (from MSSMS).
Error with tcp::
An exception has been raised that is likely due to a transient failure. Consider enabling transient error resiliency by adding 'EnableRetryOnFailure()' to the 'UseSqlServer' call.
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: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)
Anyone have any ideas what to try? Since it's working from my other computer I'm pretty sure it's something on my laptop that's causing it.

Final solution for me personally is found at the bottom in EDIT2.
I finally managed to get this working. I tried connecting to my router with a cable and adapter (took it from my other computer), no luck. Tried connecting to a mobile hotspot (my phone), no luck.
Disabled ALL not used network adapters (leaving only Wi-Fi and OpenVPN Connect TAP enabled), no luck.
Uninstalled Surfshark and it's belonging TAP adapter, uninstalled other OpenVPN software (not OpenVPN Connect), removed Surfshark VPN settings from Internet Explorer settings:
And also checked "Automatically detect settings" in "LAN Settings":
VOILA! Working!
But can someone explain why? Even with all network adapters disabled it was not. Was it caused by the Surfshark VPN setting in IE?
EDIT: I installed Surfshark again (settings in IE stayed the same, no VPN, auto-settings), and I could not connect to SQL again.
After uninstalling I can connect. So it seems to be a problem with Surfshark, even when it's not even used.
I have it installed on my other computer though, so it's a bit weird.
EDIT2: I narrowed it down to a specific setting in Surfshark, Features -> Whitelister -> Route via VPN where I had selected just a few applications to go through Surfshark. After disabling that setting (all traffic through VPN) it is working again, Surfshark connected or not.

How to force specific ciphersuites in the client-side when connecting to SQL Server?

I have enabled TLS1.2 on Microsoft SQL Server and the client is connecting to it using Entity Framework and the TLS connection is established successfully.
The problem is that I'm trying to get a security certificate for my application and the evaluators told that I need to force specific ciphersuites at the client-side.
I've googled for days and didn't find any way to implement a C# application which force a specific client-side ciphersuite for establishing TLS connection to SQL Server.
Is there any way to do it? Any help is appreciated.

C# FtpWebRequest with SSL to Ubuntu VSFTPD

I have spent hours trying to get the .NET FtpWebRequest library to communicate with my Ubuntu 16.04 FTP server using vsftpd over SSL.
No matter what I try, I always end up with the exception "A call to SSPI failed. The message received was unexpected or badly formatted."
I have tried generating client and server certificates, installing them in windows, loading them with the X509 class in .NET, toggling various client and server side options. No matter what I do, it's always the same error. I believe this has something to do with my certificate not being verified by an authority. Here are my basic questions:
1) Can .NET just ACCEPT a suspicious certificate?! Installing it 30 different ways seems to have no affect?
2) What does "a call to SSPI failed" really mean? I've read conflicting answers. I have no problem connecting with TLS/SSL via FileZilla, but .NET 4.5 just won't have it.
3) Can someone give the minimum amount of steps to have a Windows 7 client using the .NET framework connect to a Linux server using vsftpd over SSL? I strongly believe the problem lies in my Windows/.NET settings since FileZilla on my Windows machine has no problem connecting.
Thank you in advance.

Insert the line below in your vsftpd.conf:
ssl_ciphers=AES128-SHA

IIS / SQL Server connection error

I am doing a sample code and I got stucked in a really strange behavior, I am trying to connect to a SQL Server using this connection string
"Data Source=" + ServerName + "." + DomainName + ";Initial Catalog="+DBName+";Integrated Security = false;Persist Security Info=false;User ID=sa;Password=" & Mypassword & ";Connection Timeout=90"
Apparently I am not using Windows Integrated Authentication or (SSPI), when I use this on the web application I get this error:
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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
Just to note I created a .Net application that uses the same connection string and is running from the computer where the IIS resides and it works fine.
Here are the steps I have done:
I checked the SQL client configuration I opened it and enabled both of the protocol tcp and Named pipes.
I did impersonation on the IIS and used windows authentication and made sure that the IIS is working with the same credentials as mine.
I used Wireshark to see wut is the difference between the two connections and I couldn't understand the output however it seems that from the IIS it always tries to use windows authentication although I have clearly made the string such that it doesn't use windows authentication basically wut happens is that some negotiation in the beginning of the connection that seems the same from both application "not_defined_in_RFC4178#please_ignore" and then the IIS goes always to NTLMSSP noting the my user doesn't have access to the database except through user name and password so the negotiation fails with IIS while it succeeds normally from the application.
My question is how may I fix this, I kind of assume that there is some configuration that mandates that any SQL client from IIS uses windows authentication but I can't know where or how to disable it
I note I am not using web.config configuration for the SQL Server connection string and this issue happens with IIS7.

Here are the first things I would check:
Verify the Application pool user has rights to access network resources
Since you stated it works when you are logged into the machine, try changing the application pool user to the user with which you log into the machine.
Check if you have impersonation enabled in your web.config. If you do, make sure that user can access network resources.
Try changing the connection string to use an IP address (as a test). If that fixes the issue, maybe it is some sort of DNS problem.
Make sure you include a ,1433 at the end of the IP Address
Set Network Library=DBMSSOCN in your connection string. (See this article on ConnectionStrings.com for more info.)

If you have typed exact connection string as above, please check changing & around Password in connection string to +.
The connection string written above is not valid string at all since string can be concatenate another string using + not using & in C# as I know.

Aside from what the others have indicated, the only other time I recall the error message specifically with "Named Pipes" reference was based on how SQL-Server is setup.
To confirm, I went into my version of SQL Server Configuration Manager. Then, looked at the
"SQL Native Client 11.0 Configuration" (just in case, did for both 32-bit and 64-bit) and opened to show "Client Protocols". Within that it shows options for Shared Memory, TCP/IP and Named Pipes. Make sure your "Named Pipes" protocol is enabled.

You mention that SQL Server is on another machine. You should make sure the SQL Server Browser service on that machine running.
You will find it in the Windows Services management console (as well as other locations).
In addition, you will have to make sure UDP port 1434 is open in the firewall.

Check this first:
Make sure that you sql server accept remote connections
Sql Server Instance ->Properities->Connections->Allow remore connections.
following this step in second:
Try setting up a connection in VS with the Server Explorer pane:
1) Open Server Explorer.
2) Right click "Data connections" and select "Add connection"
3) In the dialog that follows, select your DataSource, and database, specify the security info, and press the "Test connection" button.
4) When the connection works, press "OK"
5) highlight your database in the Server Explorer pane, and look at the Properties pane. A working example of the connection string will be shown, which you can copy and paste into your app or config file.

Check the values of ServerName, DomainName, DBName & MyPassword.
Are they correct ??
How they populate?

Let us check into the steps to resolve this error.
1) SQL Server should be up and running.
2) Enable TCP/IP in SQL Server Configuration
3) Open Port in Windows Firewall
4) Enable Remote Connection
5) Enable SQL Server Browser Service
6) Create exception of sqlbrowser.exe in Firewall
7) Recreate Alias
Source here
Hope it helps

may be the SQL server was not recognized by client system
because the error occurred due to sql server network not available and also it may be some error for network failure

Initial connection to SQL Server Connection Is Slow. Why?

I have run into a situation with a C# application installed at two sites where the initial connection to SQL Server is extremely slow. I wrote a test application to verify where the slowdown occurs and it is on the first SQLConnection.Open statement. It was taking about 41 seconds to establish a connection to the server via named pipes. We thought it might be a DNS issue but its just as slow using a TCP/IP connection. After the initial connection is made the connection is pooled and the application responds normally. Both the workstation and the server are decent machines running Windows 7 Pro, Core 2 Duo 3.16 Ghz with 4 gig of Ram. I did find the following article on a microsoft forum:
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/f295994c-5812-4e46-8ac9-f05471d4dd54
Turning off the LLMNR protocol did cut the initial connection time in about half to 21 seconds. However, this is still a long time to get an initial connection to SQL Server. The only things slightly different from our norm is that DNS in this case is done thru a router and not an actual server. This has occurred at only two places so far, others run with no issues. Any help would be appreciated.
Thank You,
Dennis

In front of the server on the connection string, add np:
This becomes Server=np:server\instance and forces the Named Pipes instead of the default of TCP.
I could of probably changed the priority to use Named Pipes before TCP... but I did not want to mess with that on the server.

I saw similar problem but not sure it's the same as yours. In my case, it's not just the C# program being slow to make the SQL connection. It's any tools connecting to SQL server also experiencing the slowness. Also, once the initial connection made to the SQL server, any subsequent connections are fine for a period of time.
The reason was that SQL server was using a number of managed assemblies. It's trying to verify the cerfiticates assigned to the assemblies. It's connecting the crl.microsoft.com. My SQL server didn't have the internet connection. So, it waits for the timeout.
The solution was to make my SQL server to have internet access or disable the CRL checking. You can go to the SQL server machine. Select Tools > Internet Options > Advanced. Check if the publisher's certificate revocation under the secuity node is checked or not. If it's checked, uncheck it.

I tried specifying the connection string with integrated security = false (meaning the user id and password are in the connection string) and encrypt = false (just be be 100% sure SSL encryption is not being used). These specifications did not seem to help and I could not get a connection explicitly using the TCP/IP network library (NetworkLibrary = "dbmssocn"). This could have to do with the server firewall and the port not being open. I switched back to named pipes and put the named pipe network library specification in the connection string this time (NetworkLibrary = "dbnmpntw"). After this change, the connection was made instantaneously.

Establishing an integrated security connection to SQL Server using the IP address (instead of a host name), will prevent Kerberos authentication being used. In this scenario check the connection between the SQL Server and the domain controller.
If you connect using the host name (not the IP Address) Kerbos is in play, in this case you need to check the client machine's connection to the domain controller.

We had the same problem, and it turned out that our remotely-hosted Active Directory server was to blame.
We created a site-local Active Directory server to replicate the remotely hosted AD master and then all of our slow SQL Server integrated security authentication performance issues went away.
I hope that helps.

Yeah when you're using integrated security, Active Directory can be the one to blame, also the overall network since it all depends on it. Another thing I could think of is the edition of SQL Server you're using.
Also, when SQL Server is not being used by long periods of time, it behaves similar to IIS, putting the worker process to sleep, so when you contact the server again, depending on the machine (we can see that these have desktop machines configurations), it will take some time while the worker process gets back to life and is ready to work.

You did check the obvious I take it? That UDP port 1434 is open on the firewall and the browser service is running .... would take about 40 sec to authenticate otherwise.

there are other methods of creating connections to SQL databases. Try finding a tutorial which uses the
sqlconnection myCon = new sqlconnection(details);
myCon.Open()
instead of creating an object to instance the connection.

I don't have a concrete answer but have you tried running SQL Profiler to see what is going on from SQL's point of view?
Also have you tried connecting to SQL using the same credentials as your connection?
On the other hand it may all be much lower level but I always do the easy to check stuff first.
Good Luck.

It sounds like either name resolution is taking a while or authentication is taking a while. After the initial resolution or authentication's occured, then details of endpoints are cached by the server so it doesn't need to perform the lookups again until caches expire.
As an experiment, try ping'ing the server from the client box -- if this takes a long time to resolve the hostname, then you've found the culprit: hostname lookups (DNS or NBNS). Another alternative is to use the host IP address rather than name. So if you've got a SQL Server named instance of bob on server sql2005-01, and this server has an IP of 192.168.200.12, then try connecting to 192.168.200.12\bob instead of sql2005-01\bob.
Authentication's more awkward to resolve, but you might be able to test it with runas on the SQL server box (e.g., runas /user:domain\user cmd to see if you can open up a command prompt as the user you're attempting to authenticate as.

It could easily be a problem with either the connection or the authentication, it is normal that the first connection takes longer as ADO.NET has connection pool to avoid that long connection time.
There are many factors that can influence the speed:
- TCP/IP configuration
- Routers on the server-side
- etc.

Still if you are facing the issue, please see blow resolution:
Root Cause
The issue which we were seeing on Win7 VDIs could be due to the Network hardware device connected with the machine. If TCP/IP scaling is not supported by the network device then the performance will be slow.
Solution
Disable auto tuning level of the TCP. Please follow below steps:
1) Open command Prompt with admin right (Run as Admin)
2) Type “netsh interface tcp set global autotuninglevel=disabled”
3) After running above command restart the machine.
For other information on this command, visit link “http://support.microsoft.com/kb/935400”

I had the same problem. After vigorous research on google and stackoverflow, i changed the client computer's hosts file (In windows,located at C:\Windows\System32\drivers\etc).I entered my host's ip address and server name in this file and Viola!. Things became superfast!
Like everybody in stackoverflow said, it was the computer looking up the servername's address in the DNS service and getting a timeout.
The steps i did follows.Give it a try if nothing else works.
HOW TO ADD AN ENTRY IN HOSTS FILE
1.Open the command prompt and ping your server,where the remote database is located. To do this enter the following command:
ping servername
Here my remote computer name was Juno. So i should ping like this.
ping Juno
This command will ping my server and returns ip address like this.
Pinging Juno [192.168.0.3] with 32 bytes of data:
As you can see the ip address of the server is between the brackets.
Copy the ip address.
2.Now Open the Hosts file with elevated Notepad(Run as administrator).
At the end of the hosts file,there will be some lines like these:
#localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
At the very bottom (here,after the localhost),type # and enter the ip address of the server we just obtained preceeded by server name.
So, the hosts file should look like this.
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# 169.254.63.1 Juno
Now save the hosts file and restart the Client PC. (For me,it worked instantly without restart.)
Annd there you go!
For more info about editing your hosts file,click here

In my case the answer was:
Try everything with no result.
Remote Desktop to the (non-prod) SQL Server to double check settings.
Close down Visual Studio you left running after doing a quick SSIS job.
Go somewhere quiet and kick yourself.

Open Start -> Microsoft SQL Server 20XX ->SQL Server Configuration Manager
SQL Native Client 11.0 Configuration (32bit) -> Client Protocols -> (Ensure all items are marked as "Enabled")
SQL Server Network Configuration -> Protocols for MSSQLSERVER -> (Ensure only Shared Memory item is marked as "Enabled", others should be "Disabled")
SQL Native Client 11.0 Configuration -> Client Protocols -> (Ensure all items are marked as "Enabled")
Reboot computer
Ensure SQL Services are running and attempt to connect to local MSSQL
Connection should be much more rapid