Cannot connect to RDS SQL Server Database using Management Studio - sql

I created a SQL Server RDS Instance in AWS and it seems to be up and running, but if I try to connect to it using Management Studio I get this error:
Here is the text of the 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: TCP Provider, error: 0 - The wait operation timed out.) (Microsoft SQL Server, Error: 258)
I initially tried with the default security group that was created with the instance, but when that didn't work I created a new security group and modified the instance to use it.
Here you can see the details:
I tried this connection setup to connect:
Server Type: Database Engine
Server Name: valuationdlsdev.ck1qvjqhglyg.us-west-2.rds.amazonaws.com,1433
Authentication: SQL Server Authentication
Login: the Master User Login I created when creating the RDS Instance
Password: the Master User Password I created when creating the RDS Instance
I was kinda at my wits end and so I changed the setting on the Security Group to All traffic just to see if that would work, so here are all the settings on the security group:
At this point I'm wondering if port 1433 is not open, because I feel like I've tried everything. Could someone please help me.
Thanks.


In my case I opened the VPC Security group associated with my database
In the EC2 Security groups dashboard I selected Edit Inbound Rules from the actions dropdown and chose edit inbound rules.
At first, I looked at the inbound rules and thought everything was OK since this was the current setup
After all - if it was allowing all traffic, then what could possibly be wrong?
On a whim I added a rule for TCP port 1433. Ending up with this simple setup
Then it immediately started working for me.


Make sure it is publicly accessible, there is a radio button you have to check to make it publicly accessible.
Also add MS SQL inbound rule in inbound tab.After making the change wait for sometime so that the settings are updated in the instance.


In my experience this was counter-intuitive. With the options I selected, all ports and IPs seemed to be open, but after editing the inbound and outbound rules in the security group to have MS SQL for anywhere, I was able to connect.


For inbound rules, go to the VPC Security group of your database instance
In Inbound tab click modify
In column source change ip 0.0.0.0 by your IP by "My IP" or "Anywhere"


I had the same issue.
I ended up deleting the security group inbound rules, and just added a new inbound rule for port 1433, source being: 0.0.0.0
Image attached.
inbound rules


Thanks for the discussion here. Just post my finding in case anyone needs help in the future.
I initially followed this guide https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html.
then, I got some ideas from this post and figure out my particular issue in the end. https://forums.aws.amazon.com/thread.jspa?messageID=845682 The poster really did wonderful troubleshooting steps which could help fix most of the general Error 258 problems already. In the end I used the suggestion from the answerer to find out my problem.
In terms of my case of encountering error 258, I tried to connect to RDS SQL server 2016 inside a secure network from my workplace. When I switched to use the public network served by some Telecomm vendor, the connecting was succeeded.


If you want to access from different network were the instance was created, you'll need to open access to the IP range of where you want to access, by going to the "security group" assigned to your DB instance, and then adding the rule for your IP range.
PD. AWS by default only allow access from the IP range of the machine where you activated "public access" to the instance.


I was also not able to access it from my office laptop, but I was able to access it from my personal laptop. I think it is because of some company firewall rules.


In case anyone comes across this post looking for an answer, I just wanted to updated and make sure it's there if anyone needs it. The issue here turned out to be that I misunderstood the way "Publicly Accessible" works and set it to "Yes". Apparently it should have been set to "No". "Yes", however does work for the SQL Server Express version.

Related

Notepad++ and SFTP connection issue

I am trying to connect to SFTP server using notepad++ plugin NppFTP. However, while connecting to the remote server I always get below error:
Connecting
[SFTP] Connection failed : Timeout connecting to <IP address>
Unable to connect
Disconnected
Here are the important configuration details set in NppFTP window for your reference:
Port: 22
Connection Type: SFTP
Authentication: Try password authentication
I tried to go through some of the solutions stated in few the questions in Stack Overflow but to no avail.
Would really appreciate your suggestions/pointers to resolve this. If it is related to SSH private key, would appreciate if you can provide the steps as well.
Edit: I am able to access the server using another FTP tool FileZilla which eliminates any mess with the access front.

You need to find out more about where the issue is:
Can you ping the server you are trying to connect to?
ping 166.178.233.70
Did you try connecting with another ftp tool, like FileZilla, that gives more detailed log information?
The possible issues are numerous:
The ftp server config: set up to exclude connections from certain ip addresses or domains, requires public/private keys...
Your local connection/VPN is not passing the connection.
It may require a

I got the same issue. The problem was solved after I updated NppFTP.

in my case, I changed the wifi connection then, it works.

Accessing Azure SQL Database from Access (without port 1433)

So I'm building a pretty simple application in Access 2013, and our company recommended using Azure SQL Database for the backend (due to the cost and simplicity of setting up/maintenance). However, their recommendation left us with a massive problem. Port 1433 is blocked on our company's network, and it's such a big company, I can't get it unblocked.
I don't know too much about having a middle-tier, but what are my options here? Is there a simple way to connect to the database without accessing this port?
Thanks

You could fire up a Azure VM with SQL Server already installed. Then you should be able to change the ports to your liking.
Check out this post...
http://roberteichenseer.wordpress.com/2012/07/06/nderung-default-port-sql-server-innerhalb-einer-azure-vm/

You only need to open up 1433 outbound in your works firewall not the 1433 inbound.
Most security teams are ok to open the outbound port. Opening the outbound will give you the access to connect and access the data inside Azure.

Google Cloud SQL Authorized Network can't connect

I'm trying to connect to my Google Cloud SQL instance from my desktop but am getting the following error:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
According to the docs this means that the client's IP isn't authorised to access the instance. I have done the standard "what's my ip" google search and added the IP to the "Authorised Networks" list of the instance (as well as a bunch of variations and /x ranges - none have worked, yes I restarted the instance). I have set a root password and even tried connecting with the necessary SSL certs - yields the same error.
I can connect to other (non-google) sql databases, I can ping the database, and I'm not behind any significant firewalls.
How i'm typically trying to connect (also tried SSL):
mysql --host=the.instance.ip.add --user=root --password
Nothing I try seems to work.
I feel like I must be missing something obvious - any suggestions welcome (this is a nightmare).

Could you check again if you have authorized the correct IP address.
If using your desktop from home, you may be having a private IP address for the desktop. What you really need to authorize is the public IP address.

The "what's my ip" search on Google doesn't currently work properly when the ISP is proxying the web traffic transparently. Better information on the IP seems to be provided by Proxy Test from http://www.lagado.com/proxy-test.

Make sure that the IP you are using is the public IP, keep in mind that this can change from time to time depending on your Internet provider. The easiest way to authorize any network is to add 0.0.0.0/0 to the witelist
I check my ip addres in this page https://www.whatismyip.com/es/

Remote connection in sql connects one way

I have two sql instances:
instance-1 on server-A
instance-2 on server-R.
Both instances are on different domains. I can connect remotely to instance-1 from server-R successfully but I am unable to connect to instance-2 from server-A.
When I attempt the connection it throws error-26. I have allowed ports 1433,1434 through the firewalls and SQL Browser service is running on both servers.
What are some possible things I have overlooked?

There's an article about this on the MSDN blogs.
Click here to read: Error: 26 - Error Locating Server/Instance Specified
Suggestions from the article:
The client stack could not receive SSRP response UDP packet from SQL
Browser. It's easy to isolate the issue. Here are the steps:
1) Make sure your server name is correct, e.g., no typo on the name.
2) Make sure your instance name is correct and there is actually such
an instance on your target machine. [Update: Some application converts
\\ to \. If you are not sure about your application, please try both
Server\Instance and Server\\Instance in your connection string]
3) Make sure the server machine is reachable, e.g, DNS can be resolve
correctly, you are able to ping the server (not always true).
4) Make sure SQL Browser service is running on the server.
5) If firewall is enabled on the server, you need to put
sqlbrowser.exe and/or UDP port 1434 into exception.
Based on what you tried already, then maybe it could be a name typo, DNS or try both Server\Instance and Server\\Instance in your connection string.
The MSDN article have other notes to review as well.

About error 26 following link may help you probably:
http://www.codecandle.com/Articles/102/SQL/Administration/error-26-Error-Locating-Server-Instance-Specified%29-%28Microsoft-SQL-Server-Error-1%29/codedetail.aspx
Issue's source is high probability due to instance 2, not server A.
If you opened sqlbrowser port, also check if it actually listens via command prompt.

Not connecting to SQL Server over VPN

I have connected for the first time to an existing network over VPN. I can ping the IP address which is used by the SQL Server from the VPN client, but SSMS does not connect to the SQL Server. I am using the right login id and password.
Why could this happen? Any ideas?

On a default instance, SQL Server listens on TCP/1433 by default. This can be changed. On a named instance, unless configured differently, SQL Server listens on a dynamic TCP port. What that means is should SQL Server discover that the port is in use, it will pick another TCP port. How clients usually find the right port in the case of a named instance is by talking to the SQL Server Listener Service/SQL Browser. That listens on UDP/1434 and cannot be changed. If you have a named instance, you can configure a static port and if you have a need to use Kerberos authentication/delegation, you should.
What you'll need to determine is what port your SQL Server is listening on. Then you'll need to get with your networking/security folks to determine if they allow communication to that port via VPN. If they are, as indicated, check your firewall settings. Some systems have multiple firewalls (my laptop is an example). If so, you'll need to check all the firewalls on your system.
If all of those are correct, verify the server doesn't have an IPSEC policy that restricts access to the SQL Server port via IP address. That also could result in you being blocked.

When this happens to me, it is because DNS is not working properly. Try using the IP address instead of the server name in the SQL Server login.

Make sure SQL Server is enabled for TCP/IP (someone may have disabled it)?
This will also help you to check/verify the port number the SQL instance is using (in case someone changed it from the default of port 1433).
Obviously port 1433 (or whatever port SQL is listening on) needs to be unblocked by any firewalls between your machine and the box SQL is running on.
To check SQL's network configuration (requires SQL Server Client Tools installed):
Start -> Programs -> SQL Server 200x -> Configuration Tools -> SQL Server Configuration Manager
Connect to the machine you need then expand the Tree Item (LHS) "SQL Server Network Configuration", then pick instance. You should have four options - Shared Memory, Named Pipes, TCP/IP and VIA. You can check that TCP/IP is enabled in the RHS window.
If you double click TCP/IP and hit the "Advanced" tab, you can also view the Port number.
Other thoughts.. Are you using SQL Authentication or Windows (Domain) authentication?
If SQL Authentication (which I assume you are using given you said username and password), are you sure the SQL instance you're connecting to has mixed mode authentication enabled? If not, you have to connect as Administrator and change the default security settings to allow SQL authentication.
If Windows Authentication, could your network be using Kerberos potentially? One would think the VPN credentials would be used for the handshake. I'd check your account has appropriate login rights.

I also had this problem when trying to connect remotely via the Hamachi VPN. I had tried everything available on the internet (including this post) and it still did not work. Note that everything worked fine when the same database was installed on a machine on my local network. Finally I was able to achieve success using the following fix: on the remote machine, enable the IP address on the TCP/IP protocol, like so:
On the remote machine, start SQL Server Configuration Manager, expand SQL Server Network Configuration, select "Protocols for SQLEXPRESS" (or "MSSQLSERVER"), right-click on TCP/IP, on the resulting dialog box go to the IP Addresses tab, and make sure the "IP1" element is Active=Yes and Enabled=Yes. Make note of the IP address (for me it wasn't necessary to modify these). Then stop and start the SQL Server Services. After that, ensure that the firewall on the remote machine is either disabled, or an exception is allowed for port 1433 that includes both the local subnet and the subnet for the address noted in the previous dialog box. On your local machine you should be able to connect by setting the server name to 192.168.1.22\SQLEXPRESS (or [ip address of remote machine]\[SQL server instance name]).
Hope that helps.

Check that the port that SQL Server is using is not being blocked by either your firewall or the VPN.

I have this issue a lot with Citrix Access Gateway. I usually get a timeout error. If you are able to connect to the database from a client on the network, but not from a remote client via VPN, you can forget most suggestions given here, because they all address server-side issues.
I am able to connect when I increase the timeout from the default (15 seconds) to 60 seconds, and for good measure, force the protocol to TCP/IP. These things can be done on the Options screen of the login dialog:

As long as you have the firewall set to allow the port that your SQL Server instance is using, all you need to do is change Data Source from =Server name to =IP,Port
ie, in the connection string use something like this.
Data Source=190.190.1.100,1433;
You should not have to change anything on the client side.

You may not have the UDP port open/VPN-forwarded, it's port number 1433.
Despite client protocol name of "TCP/IP", mssql uses UDP for bitbanging.

SQL Server uses the TCP port 1433. This is probably blocked either by the VPN tunnel or by a firewall on the server.

When connecting to VPN every message goes through VPN server and it could not be forwarding your messages to that port SQL server is working on.
Try
disable VPN settings->Properties->TCP/IP properties->Advanced->Use default gateway on remote network.
This way you will first try to connect local IP of SQL server and only then use VPN server to forward you

I was having this issue too with SQL Server 2017.
I'm on the same network as the server via VPN and can ping it. After being frustrated that no authentication method would work - I set up an SSH server on the SQL server - and I was able to connect normally. This confirmed the correct port wasn't being hit for some reason. I even created a new user accounts, domain accounts, firewall checks on both ends, etc...
The solution for me was:
1. Set Connection to strictly use TCP/IP on SSMS
2. Use a custom string to point to the default port (ex: Data Source=192.168.168.166,1433;)
All the other comments above haven't worked so far. It looks like it was mandatory to include the port (even though its default).

This is what fixed my connection problem of accessing the SQL Server 2012 Database via VPN
With the SQL Server 2012 Configuration Manager,
I went to the SQL Server Network configuration
Then clicked on the NEW server instance and double-clicked the TCP/IP protocol
[I had also previously enabled this option and rebooted the server but that did still not fix it]
now that the TCP/IP was enabled, I noted that all of the IP port slots in the 'IP Addresses' tab of the TCP/IP Properties advanced dialog were set to Enabled=No.
I was curious to why my new installation set all of these IP slots to NO rather than Yes, so I just changed them to YES.
Now the connection to the sever via VPN works great, I did not change any port numbers.
Note: I also had SQL Server 2008 default from the Visual studio 2010 uninstalled, but I do not think that had a direct effect to the TCP/IP situation. A coworker told me that the 2008 and 2005 installations which come with visual studio may interfere with SQL 2012.

If you're using sql server 2005, start sql server browser service first.

Try changing Server name with its IP
for example
SERVERNAME//SQLSERVER -> 192.168.0.2//SQLSERVER
its work flawlessly with me using VPN

Make sure to add port 1433 to firewall exceptions and make sure "Any IP Address" is checked under Firewall port setting(see attachment).

In case everything works fine on your LAN, but fails when client application tries to establish connection thru a VPN, you might consider changing your router MTU (Maximum Transmit Unit) settings from AUTO to a lower than maximum value.
Further references:
https://faq.draytek.com.au/2021/03/15/adjusting-vpn-mss-mtu-settings/
https://community.spiceworks.com/topic/217130-mtu-issues-in-vpn-connections
https://community.ui.com/questions/EdgeRouter-4-FortiGate-VPN-Performance-issues/84932edc-d2ee-4bdd-bd47-e0993210f17e?page=1

My solution was enable and start the service "SQL Server Browser".
Be also sure, you allow this service in your firewall.

I have a similar problem but with a strange effect.
If I use SMSS over a VPN (site2site) I can't connect. But If I use OpenVPN client it's working.
And this isn't the only thing... Using the same site2site vpn but with DBeaver or HeidiSQL I can connect... I wrote a simple c# console app to test the connection and it's working. The only issue is with SMSS.
I don't know why but I'm very curious about that :)