On our MS SQL server one of our teams implemented Azure Hybrid connector. So what I see happening in netstat is that the SQL server opens connection after connection to Azure from our on-premises network. But those connections never seem to die and eventually the source ports hit exhaustion. The pattern is the hybrid connecter makes one connection to itself (the ms sql server) then two connections to Azure public IPs which are all over the place - over and over into the thousands. This traffic traverses an ASA firewall and if I look at connections there are thousands of idle connections for the the replies. Has anyone run into this issue?
We reboot the MS SQL server which clears the ports and we live another day. But we don't understand why these TCP connections don't just die off.
Related
The installation on both Azure and Sql Server side is done exactly according to Microsoft specifications in
https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections.
The endpoint host is the SQL Server machine name using fixed port 1433.
The SQL Server is a named instance of SQL Server Express in a Windows 2012 Server.
The connection is also shown as Connected both on Azure and Server HCM sides.
I have done several similar installations before without any problems in more open networks, but in this case the
SQL Server is installed on a "security network" and the only TCP/IP connection opened from the server is to
the Service Bus relay on port 443. But this should be possible according to the specs.
When my Azure Web App tries to open the SQL connection it responds with the error:
"Connection Timeout Expired. The timeout period elapsed while attempting to consume
the pre-login handshake acknowledgement. This could be because the pre-login handshake
failed or the server was unable to respond back in time. The duration spent while attempting
to connect to this server was - [Pre-Login] initialization=0; handshake=15028; "
In Azure diagnostics tool tcpping also works fine to machinename:1433.
What could be the reason for this behaviour?
Are there still some more ports to open or some other settings to change?
EDIT: The solution which finally solved this problem was a quite obvious one. The original settings had the firewall for the on Premise server open only for the Service Bus relay on port 443, just as the specs said would be enough. By opening port 443 for all outbound TCP/IP addresses the connection started immediately to work from my Azure Web App. So there are obviously more addresses used by Hybrid Connection, but I haven't found which ones.
I am a Support technician for an Application using a 2008 SQL Server Express database and the our client app-installations occasionally loses connection to the SQL Server database.
Note: I am a total beginner with SQL and unfortunately our company no longer has an application Eng.
So where to begin? Our customers usually have a few client applications installed (say 2 to 10) and for the most part the application will connect to the server's DB without error. Then all of a sudden we fail to connect, usually with a simple "Unable to connect to the database" error.
Interestingly, in most cases they can wait 30+mins and the problem goes away.
We have the Named Pipes and TCP/IP enabled for remote connections. Any suggestions to consider?
I've got a client that is hosted on a dedicated Windows 2008 Server that we look after. They have recently failed a PCI Compliance check which is asking that we close the ports for SQL Server and MySQL (1433 and 3306).
If we do this we'll loose access to the database from all the hosted website on the server. Is there a way around this or can we connect to the databases whilst still closing the ports?
Thanks
Yes, you can change the port for SQL Server to use a non-default port setting. As long as the port for the SQL Server browser remains open, instances will still be able to retrieve the correct SQL port from the server instance. This is now named instances of SQL Server function while using a dynamic port.
http://support.microsoft.com/kb/823938
I am having a real hard time establishing SQL connection between servers within a Azure network. The really odd thing is that I can connect to SQL from my home machine which is outside the VM network. It seems like some type of network issue from within the VM domain which I have not been able to identify yet.
My configuration is as follows:
I have three VM's (Active Directory, Sql Server, and an App Server)
I am trying to establish SQL connection from app server to sql server
Both VM's Windows Server 2012
All servers are on the same azure network, affinity group, domain
All servers connected to the domain and have IP's
I can see DNS is resolving because I can ping the sql server from the app server using the sql server's computer name
I created Firewall rules allowing in/out on port 1433 on both servers
SQL Server is listening on the default port because of this command executed on the SQL Server (i'm not understanding the 0.0.0.0 IP though which may be a problem) (I can connect from home so I think this is ok)
netstat -an | find ":1433"
TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING
TCP [::]:1433 [::]:0 LISTENING
I created public & private endpoints on SQL for default sql port 1433
I can actually connect to SQL Server from my home machine
I have temporarily turned off firewalls on both servers
tracert from the app server looks like this.
tracert spsql01
Tracing route to spsql01 [10.0.0.7]
over a maximum of 30 hops:
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 5 ms <1 ms 1 ms spsql01 [10.0.0.7]
Trace complete.
On the App Server i create a connection.udl file to test the connection to my SQL Server but it never passes the connection test.
Have you created the appropriate Windows Azure SQL Database firewall rules for your VMs in Windows Azure? You can use either the special 0.0.0.0 for all of Windows Azure or, better, provide the public VIP of your IaaS cloud service (not the private DIP of the individual VMs). The latter limits firewall access to only your cloud service, since the outbound connection to WASD will use your public VIP. Note that if you delete (or stop/deallocate) all the VMs in your cloud service you will lose the VIP.
When I connect to the SQL Server 2008 remotely it only works once, after that the server hangs. The service cannot be stopped or restarted and when trying to connect again it gives a 'Timeout' error.
The server has TCP/IP connections enabled. The default port is set to 1433 and I cleared the 0 from the dynamic ports. I enabled the 127.0.0.1 IP and the public IP and set the 1433 IP to them. Named pipes and the other protocol (Shared Memory or something) are disabled.
I am connecting from the remote machine using the 'sa' user and a strong password. The server is set to accept both authentication modes.
Connecting for the first time from the remote machine works perfect. Queries work and data can be retrieved from the databases. After disconnecting and trying to connect again it gives a timeout error. This error is generated because the SQL Server is hanged somewhere.
At this point it is impossible to Stop or Restart the SQL Server service from the service machine. The only solution is to restart the computer. However, connecting to the server locally from SQL Management Studio still works.
I think it has something to do with going into an infinite loop somewhere, or it doesn't drop the connection on the 1433 port after disconnecting from the remote machine and it still waits for input from it.
have you ruled out anything at the network layer such as software or hardware firewalls, NAT'ing, proxies ect?
Are you running SQL Server as a default or named instance?
if you do a netstat while things are working & then when you get a time out, what do you see?
Try running network monitor or wireshark on the server to see if the request is getting through & if so is the server responding?
EDIT:
It's a bit of a concern that you can connect to the server on port 1433 when sql server isn't running you should be getting a connection refused (no firewall) or a timeout (with a firewall)
Run profiler on the server & audit logins/logouts you should be able to see the client connect? it may help you troubleshoot the issue?
Try a blunt instrument like re-installing the sql server connectivity driver eg. mdac, sql native on the client.