This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 33%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMM%3C/text%3E%3C/svg%3E)
We are trying to connect from an application installed on a virtual machine to a database as part of an AWS RDS in the cloud.
There are several routers and firewalls between the source and the target system and there is also NATting happening of the source IP.
A connection test in PowerShell works.
However, when trying to connect to the database with a connection string from within the application, a TDS pre-login handshake error message appears.
A traffic capture with Wireshark also did not provide a clear solution to the error.
We have also tested the connection to the database from SSMS (SQL Server Management Studio) and the same error message appears.
When testing the connection from a different virtual machine the problem does not occur.
So it is not due to a specific application.
My guess is that somehow the SQL Server can't understand the pre-login message and kills the connection.
Does anybody know how to analze this pre-login message in Wireshark to derive further possible solutions?
We turned off the encryption on the AWS RDS but this did not help.
I just wanted to give feedback that the problem has been resolved.
It was indeed due to a firewall activation that was not implemented correctly a few weeks ago.
Thanks for the update! I converted your comment to an Answer, as that is the best answer given in the thread. (But you are not permitted to accept your own answer.)
As I understand the screenshot with PowerShell, you are only testing the TCP connection as such. That is, there is no actual TDS traffic occurring. And thus, there can not be any TDS errors.
I can think of two things:
Are you using SQL authentication or Windows authentications?
As this may be something that is RDS-specific, you may have better luck in an Amazon forum.
Where is the Amazon Forum?
And you expect people in a Microsoft forum to know that? :--) I'm sorry, I don't work at all with RDS or any other Amazon service, so I don't know. But I assume that Amazon has some form of support channels.
@Margas, Marek (FDF2) , one forum for AWS RDS questions is DBA StackExchange. Tag your question with Amazon-RDS and sql-server.
Thank you
I now have the following SQL error message from the SQL-Audit-Log:
Network error code 0x274c occurred while establishing a connection; the connection has been closed.
This may have been caused by client or server login timeout expiration. Time spent during login:
total 40096 ms, enqueued 0 ms, network writes 0 ms, network reads 40096 ms, establishing SSL 0 ms,
network reads during SSL 0 ms, network writes during SSL 0 ms, secure calls during SSL 0 ms,
enqueued during SSL 0 ms, negotiating SSPI 0 ms, network reads during SSPI 0 ms, network
writes during SSPI 0 ms, secure calls during SSPI 0 ms, enqueued during SSPI 0 ms,
validating login 0 ms, including user-defined login processing 0 ms.
And just to make it clear: you found this message on the SQL Server side?
0x274c = 10060 and NET HELPMSG 10060 says:
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.
I can't say that I understand what is going on. But it sounds like there is a network problem of some sort. Like the reply packages from the server is being sent to somewhere else than the client. Or just being dropped somewhere.
Now, is that on your side, or on the Amazon side? Or a combination? That is, you need to configure some firewalls etc in RDS? But you said that things are working from another VM, so my gut feeling is that this is something local. But that is only a gut feeling, and I have been wrong before. One thing I would consider testing, if possible, is to try to make connections elsewhere, for instance an Azure SQL Database, if you have any such available.
That was the message inside the AWS RDS-Service from the SQL-Audit-Log-File.
And yes, i works from other VW-Machines but they are inside an other environement.
But i will try to connect from my laptop to see what will hapen then.
One possibility to check for is this could be a case of multiple IP-addresses. That is, your VM has the address 10.10.10.10, but there is another machine with the same IP elsewhere, and the reply packets from SQL Server ends up there.