A little background:
I have a Windows .NET application that is in use by approximately 40 field employees across North America. This program allows the users to enter data while in the field (away form internet access) and then synchronizes to our Sql Server 2005 database at night. A couple days ago, two of my users reported getting the following error when they performed an action that would attempt to connect to our server database (which uses .NET's SqlConnection class).
System.Data.SqlClient.SqlException: 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)
Our field employees are typically operating on a hotel Wi-Fi connection, and at first I thought that they both coincidentally got on an "uncooperative" network the same day. The following day, having moved to different hotels, the problem went away for one of these users, but continued for the other.
Besides providing the error message, the purpose of this background is to point out that
this is the first time this issue has occurred in over a year of using this software, and
the majority of our users aren't having any problem connecting to our server database with the same software.
This makes me hesitate to think that the issue is at the server (most forums and blogs I've read on this error provide steps to ensure the SQL Server is configured properly).
Noticing the Named Pipes Provider portion of the error message, I guessed that maybe this user's computer or network was causing it to attempt connection via pipes rather than TCP, so I did try configuring the server to allow BOTH TCP/IP and Named Pipes for remote connections, where it was previously set to TCP/IP only. The error continued for this one user after changing this setting.
So now I'm left to brainstorm about what could be special about this one user's computer / software / internet connection that would hinder it from being able to connect to our SQL Server.
Our connection string does use our server's URL (not IP address), and I wondered if his laptop was having problems finding it by that address. However, he was able to access a website hosted from the same URL, so I guess the problem is somewhere else.
Any ideas would be greatly appreciated. Thanks!
You've probably long since solved this problem by now or moved on, but for those having similar problems with the Error 40/named pipes issue when connecting to a SQL server instance, the following simple solution worked for us:
You can force your client program to use TCP (or named pipes, or other available methods) by adding a prefix in your connection string.
For the .NET SQLConnection example, specify in the SQLConnection's connection string like so:
Server=tcp:192.168.0.1;Integrated Security=SSPI; database=sampledb
See this blog entry for more info.
Is it possible that they are being blocked by the hotel's firewall, which may only allow traffic on certain ports?
Related
I have an Ubuntu VM installed on a client's VMware system. Recently, the client's IT informed us that his firewall has been detecting consistent potential port scans to our VM's internal IP address (coming from 87.238.57.227). He asked if this was part of a known package update process on our VM.
He sent us a firewall output where we can see several instances of the port scan, but there are also instances of our Ubuntu VM trying to communicate back to the external server on port 37258 (this is dropped by the firewall).
Based on a google lookup, the hostname of the external IP address is "feris.postgresql.org", with the ASN pointing to a European company called Redpill-Linpro. As far as I can tell, they offer IT consulting services, specializing in open source software (like PostgreSQL, which is installed on our VM). I have never heard of them before though and have no idea why our VM would be communicating with them or vice-versa. I'm also not sure if I'm interpreting the IP lookup information correctly: https://ipinfo.io/87.238.57.227
I'm looking for a way to confirm or disprove that this is just our VM pinging for a standard postgres update. If that's the case I'd like to restrict this behaviour. We would prefer to do these types of updates manually and limit the communication outside of the VM to what is strictly necessary for the functionality of our application.
Update
I sent an email to Redpill's abuse account. They responded quickly saying that the server should not be port scanning anyone and if it appears that way, something is wrong.
The server is part of a cluster of machines that serves apt.postgresql.org among other postgres download sites. I don't think we have anything like ansible or puppet installed that would automatically check for updates but I will look into that to make sure. I'm wondering if Ubuntu reaching out to update the MOTD with the number of available packages would explain why our VM is trying to reach out to the external postgres server?
The abuse rep said in any case there should only be outgoing connections from the VM, not incoming. He asked for some additional info so I will keep communicating with him and try to update this post accordingly
My communication with the client's IT dropped off so I did not get a definitive answer on this, but I'll provide some new details:
I reached out to the abuse email for Redpill-Linpro. He got back to me and confirmed the server corresponding to the detected IP address is part of a cluster that hosts postgres download sites, including apt.postgresql.org. He was surprised to learn we had detected a port scan from their server and seems eager to figure out why that is happening.
He asked if the client IT could pass along some necessary info for them to set up tracking on that server. But the client IT never got back to me. I think he was satisfied that it wasn't malicious and stopped pursuing it.
Here's one of the messages the abuse rep sent me that may be relevant:
That does look a lot like the tcp to the apt download server yes. It's
strange that your firewall reports that many incoming connections, but
they could be fallout from some connection tracking that's not
operating as intended. The timing appears to be matching up more or
less perfectly. And there should definitely not be any ping-back
connections from it.
Since you appear to be using the http version of the server (and not https) bringing the data in cleartext, they should be able to just
dump the TCP connection contents and verify exactly what it does. But
I bet they are going to see a number of http requests initiated by the
apt client that is checking for updates.
I'm trying to connect one of my databases to Google Data Studio but I keep getting the following error:
Unable to reach the host.
I read the help page and already added the necessary IP addresses to the pg_hba.conf file this way:
hostnossl google_data_studio all 216.239.32.0/19 md5
That is just an example, but I have added all IP addresses required for the connection, 12 in total.
The connection description in Google's help pages shows these connections are non SSL (That's why I set it to hostnossl)
I've also restarted the postgresql service.
"Unable to reach the host" is a Google Data Studio error message, not a PostgreSQL message. PostgreSQL settings are irrelevant at this point. You are not reaching the server at all.
Since this just became a networking and settings issue for Google, I'm voting to close.
We have moved our TFS data tier server to another machine. Everything was reconfigured and is working EXCEPT email alerts. Test emails are sent just fine. However, alerts are not happening. When I checked the event viewer, I'm seeing the following error:
ds:OLDSERVERINSTANCE db:Tfs_Configuration errors:-1 exception:System.Data.SqlClient.SqlException (0x80131904): 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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
So, it appears that the email is still looking at the old database (which has been retired). Where/how can I change this?
In case anyone else runs into this scenario. The TFSJobAgent wasn't smart enough on reboot to recognize the data tier change. Doing the following worked:
1. Stop iis
2. Stop the TFSJobAgent
3. Start the TFSJobAgent
4. Start iis
I have an application that can connect to the Principal, but can't connect to the Mirror during a failover.
(Note to moderator: please let me know if this question is more appropriate for serverfault. I posted it here because I found more questions similar to this issue than on serverfault.)
This is the error I receive when my application attempts to connect to the Mirror after a failover:
Named Pipes Provider: Could not open a connection to SQL Server [53].
Cannot open database "MY_DB_NAME" requested by the login. The login failed.
I am familiar with the fact that when initially connected to the Principal, the name of the Mirror server is cached to be used during the failover and that the failover partner I specify in my connection string is only used if the initial connection to the Principal fails.
This clearly describes the problem I'm having:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
...but the SQL Browser Service is running and I can't figure out why the name won't resolve when connecting to the mirror.
I'm assuming there is a service that must be running to enable NetBIOS name resolution that is not running, because this is what I see in WireShark consistently without a response from the Mirror:
Source Destination Protocol Length Info
10.200.3.111 10.200.5.255 NBNS 92 Name query NB SQL-02-SVR-<00>
Question 1: What could be causing the problem? ;-)
Question 2: I really don't want to enable NetBIOS (for security reasons) and I'm using IP addresses (no FQDNs) in the mirror configuration and in the connection string. Given the caching behavior of the mirror partner when connecting to the Principal, is there a way to force TCP/IP to be used so the value that is cached is the IP address and not the name? Do I need to run the SQL Server Browser/Computer Browser services?
The configuration:
App Is Delphi XE2 using SDAC 6.5.9 (I don't think this is relevant to the component I'm using because it works in other installations with mirroring and has no issues)
SQL Server 2012 Enterprise installed as a default instance on Principal, Mirror and Witness in a non-domain configuration using certificate authentication.
Windows Server 2008 R2 SP1 64-bit on all machines
Firewalls disabled on Principal, Mirror and Client (where app is running)
TCP/IP and Named Pipes enabled on Principal and Mirror
SQL Server Browser service running on Mirror
Computer Browser service running on Mirror
Mirroring is configured for automatic failover with a witness and works properly (I can fail back and forth between mirror and principal without issue)
SQL Native Client 2012 installed on Client machine
Same app login (with same SID and user rights) exists on both Principal and Mirror
Correct server, failover partner, database name, user name and password verified in my app log
In connection string, principal server is 'tcp:10.200.3.15,1433' and failover partner is 'tcp:10.200.3.16,1433' using the SQL Native client
I can ping both servers from the Client machine
NetBIOS over TCP/IP has been enabled in the adapter under the WINS tab (on the Mirror and Client machines)
I've been able to get the application working with mirroring on several other installations, but this one is baffling me.
I found the problem, which was that the customer had the Principal and Mirror in one VLAN and the Client(s) in another. Although the IP addressing scheme was the same, the policy for communication between the VLANs prevented broadcast messages, which is why the NetBIOS query was failing on the client. A WINS or DNS server will be implemented to resolve this issue.
However, I am still interested in an answer to my Question #2, above.
Recently we got a new server at the office purely for testing purposes. It is set up so that we can access it from any computer.
However today our ip got blocked from one of our other sites saying that our ip has been suspected of having a virus that sends spam emails. we learned this from the cbl http://cbl.abuseat.org/
So of course we turned the server off to stop this. The problem is the server must be on to continue developing our application and to access the database that is installed on it. Our normal admin is on vacation and is unreachable, and the rest of us are idiots(me included) in this area.
We believe that the best solution is to remove it from connecting to the internet but still access it on the lan. If that is a valid solution how would this be done or is there a better way? say blocking specified ports or whatever.
I assume that this server is behind a router? You should be able to block WAN connections to the server on the router and still leave it open to accepting LAN connection. Or you could restrict the IPs that can connect to the server to the development machines on the network.