Following the Azure VM cluster tutorial provided by Microsoft (https://learn.microsoft.com/en-us/azure/developer/terraform/create-vm-cluster-with-infrastructure),
I have a resource group created in Azure.
Under the Resource group, I have created VN, subnets, etc.
Now, I have two VMs created in the resources group. Both of them have a LoadBalancer on top. I have added NAT rule to LB to connect to individual instance, while they both share the same frontend IP.
I have created a new resource Azure MSSQL server, in the Firewall rule of the SQL server, added the public ip of the LB to the Azure Server
I have now logged in to the individual VMs, and tried to access the SQL server from the VM, but I am unable to connect to it.
I tried normal ping <hostname>
it fails 133 packets transmitted, 0 received, 100% packet loss, time 295ms
Then I try telnet from IP address (ip address was received from ping )
and I get
Trying <ip_address>...
Connected to <ip_address>.
Escape character is '^]'.
When I try to connect using an application, I get this error
com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset ClientConnectionId:8b2f0e3b
-fda0-41af-b8dc-ce80d0760b82
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.jav
a:3806) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:2109) ~[mssql-jdbc-11.2
.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.prelogin(SQLServerConnection.java
:3517) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection
.java:3325) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:29
50) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnecti
on.java:2790) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:
1663) ~[mssql-jdbc-11.2.0.jre8.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:1064) ~[
mssql-jdbc-11.2.0.jre8.jar:?]
at jet.server.db.core.ConnectorManager$ConnectionPool.£(ConnectorManager.java:712) ~[
JRESServlets.jar:?]
at jet.server.db.core.ConnectorManager$ConnectionPool.connect(ConnectorManager.java:4
32) ~[JRESServlets.jar:?]
at jet.server.db.core.ConnectorManager$ConnectionPool.getConnection(ConnectorManager.
java:504) ~[JRESServlets.jar:?]
at jet.server.db.core.ConnectorManager$ConnectionPool.getConnection(ConnectorManager.
java:487) ~[JRESServlets.jar:?]
at jet.server.db.core.DatabaseImpl.open(DatabaseImpl.java:839) ~[JRESServlets.jar:?]
at jet.server.db.core.GlobalDataService.<init>(GlobalDataService.java:103) ~[JRESServ
lets.jar:?]
at jet.server.db.core.GlobalDataService.init(GlobalDataService.java:37) ~[JRESServlet
s.jar:?]
at jet.server.ServerEnv.K(ServerEnv.java:2322) ~[JRESServlets.jar:?]
How do I make this work?
Azure SQL is only available through TCP port 1433. Check whether firewall is allowed outgoing TCP communication on port 1433.
You can check the connection by using below command:
Test-NetConnection -Port 1433 -ComputerName ServerName.database.windows.net
To resolve the error, make sure to open firewall in the path from Server like Windows Firewall, Corporate Firewall or Azure NSG (Network security group to allow access.
In the Azure SQL Server, select Networking and enable the below option:
Connect to the Azure Virtual Machine and restart SQL Server like below:
Reference:
IP firewall rules - Azure SQL Database | Microsoft Learn
Related
I have created the virtual machine on Azure and installed a free version of the SQL Server database. I have created a new login in the SQL Server to access the database. I also added the inbound rule to enable TCP port on the Azure portal of the virtual machine.
Now I am trying to access the SQL Server instance from my local computer over IP but it's not connecting. Is there anything I am missing? I am getting this error:
Use Configuration Manager to enable TCP/IP connections and listen on port 1433.
Add a Windows Firewall rule allowing inbound traffic on port 1433.
Configure the VM's Network Security Group to allow inbound traffic on port 1433.
I'm trying to connect to the sql server that has been created on Azure using SQL management studio, but i'm getting the following error.
Error message: An error has occurred while establishing a connection to the server. When connecting to SQL Server, this failure may be caused by the fact that under the default settings SQL Server does not 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.) (Microsoft SQL Server, Error: 10060)
I have enabled the client IP in the SQL server firewall settings.
Please let me know if anything else need to be taken cared. Thank you
To resolve this error, try one of the following actions:
Make sure that you have configured the firewall on the computer to allow this instance of SQL Server to accept connections. That is, If you are trying to connect from within a corporate network, outbound traffic over port 1433 may not be allowed by your network's firewall. If so, you cannot connect to your Azure SQL Database server unless your IT department opens port 1433. On the Azure Side, you also need to check if the NSG (associated with that subnet the Azure SQL server sitting in) allows the client IP with the specific port 1433.
Add the client IP in the SQL server firewall settings if you enable a server-level firewall.
Telnet the current IP of your Azure SQL Database server with the port to verify the network connection.
Ensure the server name you are connecting to is correct.
Check that your own firewall allows your connection across the internet to the instance.
Typically if it was the Azure firewall side, it would prompt you to add your IP to the firewall rules, provided you're connecting with an admin account.
This cause by network restriction in your lan. you can try by switching your network connnection. It worked for me.
I am trying to mirror a on premise SQL database to Azure ARM VMs running SQL server. One for the mirror and one for the witness. I have setup the mirroring end points on the servers. However, I am getting an error to the effect that the mirror server can not be reached.
Reading through the net pages, I tested the port using telnet. I am able to telnet to the mirroring port on my local server from the Azure VM but unable to telnet from the local server to the VMs.
I am able to telnet on the mirroring port between the VMs using the Private IP Address but unable to do so using the Public IP address.
I have added the port to the Security group being used by these VMs to allow inbound connections as well as outbound connections.
I have tested that the server is listening on ip 0.0.0.0 and my mirroring port.
Any help would be very much appreciated.
For whatever its worth, I was setting the Inbound connections source port range as the port I was going to use for mirroring. I changed this to "*" and it started working.
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.
Initial Attempt
I have an Azure VM with Windows Server 2012, on which I just installed SQL Server 2012 Express Database Engine component. Then, I followed the instructions here to connect remotely with SQL Server Management Studio.
Create a TCP endpoint for the virtual machine
Open TCP ports in the Windows firewall
Configure SQL Server to listen on the TCP protocol
Configure SQL Server for mixed mode authentication
Create SQL Server authentication logins
Determine the DNS name of the virtual machine
Connect to the Database Engine from another computer
After step seven I received the following 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)
(Microsoft SQL Server, Error: 53)
What else do I need to configure before connecting remotely?
Troubleshooting
I have been following the troubleshooting instructions here. Each blockquote below is a step described that that link.
Confirm the instance of the SQL Server Database Engine is installed
and running.
Done. We installed SQL Server Express, and it is running as a named instance called SQLEXPRESS.
If you are attempting to connect to a named instance, make sure the
SQL Server Browser service is running.
Done. We followed the steps here to turn on the SQL Server Browser service.
Get the IP Address of the computer.
Done. We will use these later for testing connectivity and maybe for setting up a static port for SQLEXPRESS.
10.241.62.155
fe80::45c:8c29:e19f:f78b%15
Get the TCP port number used by SQL Server.
Done. The SQL Server Management Studio server logs showed that the server was listening on port 49169.
Enable Protocols
Done. We had already enabled TCP/IP in the configuration manager, but we restarted the SQL Server Service just in case.
Testing TCP/IP Connectivity
Done. We used tcping.exe to test connectivity (cmd ping doesn't work quickly with Azure.) We were able to connect to port 80.
tcping.exe buddha.cloudapp.net > successful
tcping.exe buddha.cloudapp.net 80 > successful
Testing a Local Connection
Done. We used sqlcmd.exe from the command prompt and were able to connect locally via TCP with a username and password.
sqlcmd -S Buddha\SQLEXPRESS (success via shared memory protocol)
sqlcmd -S tcp:Buddha\SQLEXPRESS (success via TCP)
sqlcmd -S tcp:Buddha\SQLEXPRESS -U sa -P (success via TCP with username)
sqlcmd -S tcp:10.241.62.155\SQLEXPRESS -U sa -P (success with internal IP)
Opening a Port in the Firewall
We opened the port on which we SQLEXPRESS listens. The server logs (above) showed that SQLEXPRESS was listening on port 49169, but this is just one of many dynamic ports, and we wanted to set up the static port 1435.
Use WF.msc to create an inbound TCP rule for port 1435.
Use Azure Management Portal to create a TCP endpoint for port 1435.
The troubleshooting instructions also say:
If you are connecting to a named instance or a port other than TCP
port 1433, you must also open the UDP port 1434 for the SQL Server
Browser service.
Since we are connecting SQLEXPRESS (a named instance), we needed to open port 1434 for UDP.
Use WF.msc to create an inbound UCP rule for port 1434.
Use Azure Management Portal to create a UDP endpoint for port 1434
Further research about connecting to named instances revealed dynamic port issues. The reason why we are using port 1435 (static) instead of port 49169 (one of many effective options.)
Instances of SQL Server Express, SQL Server Compact, and named
instances of the Database Engine use dynamic ports. To configure these
instances to use a specific port, see Configure a Server to Listen on
a Specific TCP Port (SQL Server Configuration Manager). and
here.
Done. We went to SQL Configuration Manager > SQL Server Network Configuration > Protocols for SQLEXPRESS > TCP/IP, we did the following.
Protocol Tab > Listen All > NO.
IP Addresses Tab > for each listed address
Enabled > Yes
TCP Dynamic Ports > Blank (delete the zero)
TCP Port > 1435 (or your choice)
After restarting the SQLEXPRESS service, we again looked in the SQL Server Management Studio logs, and found that the Server is Listening on port 1435!!! Hooray!
Testing the Connection
Done. We opened SQL Server Management Studio on our local (non-Azure) computer and connected.
buddha.cloudapp.net,1435 OR buddha.cloudapp.net\SQLEXPRESS
sa
password
Success.
Here are the three web pages on which we found the answer. The most difficult part was setting up static ports for SQLEXPRESS.
Provisioning a SQL Server Virtual Machine on Windows Azure. These initial instructions provided 25% of the answer.
How to Troubleshoot Connecting to the SQL Server Database Engine. Reading this carefully provided another 50% of the answer.
How to configure SQL server to listen on different ports on different IP addresses?. This enabled setting up static ports for named instances (eg SQLEXPRESS.) It took us the final 25% of the way to the answer.
The fact that you're getting an error from the Names Pipes Provider tells us that you're not using the TCP/IP protocol when you're trying to establish the connection. Try adding the "tcp" prefix and specifying the port number:
tcp:name.cloudapp.net,1433
I too struggled with something similar. My guess is your actual problem is connecting to a SQL Express instance running on a different machine. The steps to do this can be summarized as follows:
Ensure SQL Express is configured for SQL Authentication as well as Windows Authentication (the default). You do this via SQL Server Management Studio (SSMS) Server Properties/Security
In SSMS create a new login called "sqlUser", say, with a suitable password, "sql", say. Ensure this new login is set for SQL Authentication, not Windows Authentication. SSMS Server Security/Logins/Properties/General. Also ensure "Enforce password policy" is unchecked
Under Properties/Server Roles ensure this new user has the "sysadmin" role
In SQL Server Configuration Manager SSCM (search for SQLServerManagerxx.msc file in Windows\SysWOW64 if you can't find SSCM) under SQL Server Network Configuration/Protocols for SQLExpress make sure TCP/IP is enabled. You can disable Named Pipes if you want
Right-click protocol TCP/IP and on the IPAddresses tab, ensure every one of the IP addresses is set to Enabled Yes, and TCP Port 1433 (this is the default port for SQL Server)
In Windows Firewall (WF.msc) create two new Inbound Rules - one for SQL Server and another for SQL Browser Service. For SQL Server you need to open TCP Port 1433 (if you are using the default port for SQL Server) and very importantly for the SQL Browser Service you need to open UDP Port 1434. Name these two rules suitably in your firewall
Stop and restart the SQL Server Service using either SSCM or the Services.msc snap-in
In the Services.msc snap-in make sure SQL Browser Service Startup Type is Automatic and then start this service
At this point you should be able to connect remotely, using SQL Authentication, user "sqlUser" password "sql" to the SQL Express instance configured as above. A final tip and easy way to check this out is to create an empty text file with the .UDL extension, say "Test.UDL" on your desktop. Double-clicking to edit this file invokes the Microsoft Data Link Properties dialog with which you can quickly test your remote SQL connection