I have SQL Server Express 2017 running on Windows Server 2016 Standard (default instance, not named). It has remote connections enabled and is listening on port 1433 and has TCP/IP and Named Pipes enabled. I have several Surface Tablets running Windows 10 and Windows 11. These tablets make a VPN connection to the server to connect to SQL Server. All of the tablets, except one of them, can connect to SQL Server. All tablets connect using the server's IP address and with SQL Server Authentication. All tablets are connected to the same WiFi router - both the ones that CAN connect and the one that CANNOT, so I believe router settings are not the problem.
The tablet that fails to connect can ping the server successfully. It cannot, however, telnet to port 1433 on the server - this times out. All other tablets can make the telnet connection. Also, using sqlcmd to connect (sqlcmd -S ip-address -U user-name -P password) works on all tablets except the one. This returns error 53. Checking the SQL Server logs after attempting to connect using sqlcmd shows no errors. So this tablet is definitely not even reaching SQL Server.
I have disabled all Windows Firewall options on the tablet with no change - still cannot telnet or connect via sqlcmd.
I have walked through multiple remote connection troubleshooting guides step by step, but most of them assume that NO remote systems can connect to SQL Server. In this case, it is just one system. So I know that the server is configured properly to allow remote connections. I just cannot determine what is different about this one tablet that is preventing it from making a connection.
What might be preventing this one system from making this connection? Any settings or other options I should be looking at?
SOLVED: After performing tracert on multiple systems that connect to this server including the problem tablet as well as attempting to telnet to various ports at the server's IP address, I discovered that the WiFi network that the tablet was on had a conflicting IP address with the server. The previous tablets that tested fine were, unbeknownst to me, on different wifi networks that did not have this conflict. As a result, this tablet was attempting to connect to a completely different device despite being properly connected to the server's network via VPN.
So the additional piece of advice to add to this troubleshooting process would be to very closely scrutinize the output of ipconfig /all. Even though you may be connected to the network of the SQL Server system you are trying to connect to remotely, if the IP of the SQL Server system is duplicated on your local network, it can be very difficult to see that all of your connection attempts are actually routing to a different system - that is why the connection is failing.
What to look for in ipconfig /all... check the client system's IP address and the default gateway that it is using. If these are using private IP addresses (as most do) most commonly starting with 192.168.x.x, and you are trying to connect to SQL Server over VPN via which the server also has a private IP address, check if your local subnet is matching the server's subnet. For instance, both the client (tablet) subnet and the server subnet were 192.168.20.x There's a chance for an IP address conflict in these conditions.
Another check that I found was helpful was, on the client, to DISCONNECT from the remote server and then try to ping the SQL Server IP address. If the ping succeeds, the server's IP address is being duplicated by another system.
Related
I have to connect to a fresh SQL Server Express 2017 on a machine not part of my domain. I have configured
Mixed Mode Installation with sa with password
SSMS -> Server -> Properties -> Connections -> Allow remote connections
SQL Configuration Manager -> Instance "EXPRESS2017" -> TCP/IP: Enable and Active and Port 1438
Restarted the "SQL Server (EXPRESS2017)" service.
I now tried to access from a remote computer, and got a timeout. I then tried to connect from the local SSMS, which works without special settings, but when under options, forced "Protocol: TCP/IP" is set, with the same credentials as before, I also got a timeout.
So am I right that I can rule out the firewall or problems finding the instance, and everything points towards a configuration issue in TCP/IP protocol, or did I overlook some setting?
EDIT: I have disabled Windows firewall, and no other firewall is installed on the computer. I have restarted the computer. I also found this article about PortQry and had a check - locally:
C:\Users\Administrator\Downloads>PortQry.exe -n 172.17.41.124 -p UDP -e 1434
Querying target system called:
172.17.41.124
Attempting to resolve IP address to a name...
IP address resolved to WIN-AECL8CJVS7E.test.local
querying...
UDP port 1434 (ms-sql-m service): NOT LISTENING
EDIT: I have run NETSTAT and it seems no port in the 14xx range is open at all, although the SQL Server Browser service is running. I must be missing something there...
You did not show your connection string, but I suppose you use your instance name here.
In order to connect to SQL Server the network library has to know 2 things: IP address and a port. Your instance is named and uses non-default port 1438.
So your connection string should use 172.17.41.124,1438 as server name, or, alternatively, you can use instance name like this: 172.17.41.124\EXPRESS2017 but SQL Server Browser should run.
We have a client that connects to SQL Server using Windows authentication. They connect using the server name and port number (not 1433).
All our software installations thus far connect to SQL Server using SQL Server authentication, connecting with server name, user name and password.
I am trying to setup a test on my computer to see whether I can connect with our software using the setup used by this client, in other words Windows authentication, with server name and port number. The port number is what is new to me here.
The problem I am having is that I can connect successfully regardless of the port number of the SQL Server installation, and what I pass in as a port number from our software. So I am obviously doing something wrong, or misunderstanding how this works. Any help would be appreciated.
My first step was to open SQL Server Configuration Manager > Network configuration > Protocols for my instance > TCP/IP > Properties. I then opened the IP addresses tab, and changed the TCP port to 41000 (I sucked this number out my thumb) on all the IP1 - IPAll sections. The TCP dynamic port setting is blank for all these. I applied, saved and restarted the server.
In the DbExpress TSQLConnection connection parameters, I pass in:
TSQL1connection.Params.Add('OSAuthentication=True');
TSQL1connection.Params.Add('HostName='+SQL_server_name);
TSQL1connection.Params.Add('Port=123');
It doesn't seem to matter what I put in the port number, or whether I leave the port setting out altogether; I always manage to successfully connect.
I want to have it successfully connect only to the port number specified.
I am using SQL Server 2014 and Delphi XE8.
I don't know TSQLConnection, but I do know a bit about TCP/IP, and I suspect that the issue here is just a misunderstanding about ports. There are always two ports involved in a connection, in this case the server port and the client port. They are not the same. The 41000 is the server port in this case, and I assume that 123 is the client port. That is perfectly fine to establish a connection, and that is why it doesn't matter what port number you put in.
In terms of solving your problem, you need to reject the connection at the SQL Server end. The server will know the client port after the connection, but whether you can access that data and force a rejection, I am afraid I do not know.
I installed Oracle 11g Standard Edition on my machine ( Windows 7 X64 ) and configured a listener. While being on the network , when I tried to connect through Jdev 11g , connection was successful. But when I'm off the network , I'm not able to connect to the Database thru Jdev. EM console is not opening too.
Is there any way I can connect to Database while I'm not on the network ?
Your listener has to be configured to listen to your localhost internal interface, 127.0.0.1, for you to be able to connect when not on a network.
If it's only configured with your network adapter's IP address you will only be able to connect while on the network. When you unplug your LAN cable the interface associated with that IP is disabled and no longer reachable, even from within your PC. You will also have problems if your IP is allocated by DHCP, and would need to use a DNS name that follows reallocation; that's why servers usually have fixed IPs.
You can configure the listener to use both addresses if you need to be able to connect locally when off the network, but have other clients connect to your database when you are on the network. Having a DB that others need to access on a machine that isn't always connected would be a bit odd though.
I am attempting to connect to a SQL Server 2008 R2 instance from another machine using the TCP protocol over port 1433.
On the server side:
SQL Server is running.
SQL Server has had its "Allow remote connections to this server"
checkbox checked.
SQL Server has the TCP protocol enabled.
At least one of the IP addresses in the list of IP addresses that SQL
Server claims to be listening on is the correct one. None of the
items in this list are Enabled, but that is not anything that I
have touched. All are Active. All have their port set to 1433
(I never touched it). I have also set all of them to Enabled at various points; this made no difference. I have not been able to track down any documentation on why both an active status and an enabled status need to be maintained.
TCP dynamic ports is set to blank (I never touched it) for all IP
addresses. As I understand it, this is what you want to do for connections that should specify the TCP port explicitly in their connection information (which is what I want).
TCP port is set to 1433 for all IP addresses, including IPAll.
The firewall is off.
SQL Server authentication is set to SQL Server Authentication
(followed by Windows Authentication).
I am able to ping the box remotely.
The symptoms of not being able to connect are basically my client (a JDBC client) hangs. The URL is analogous to this: jdbc:sqlserver://my.host.here:1433;databaseName=frob and I specify a valid user and password (and in any event do not get a login/security error).
The URL is valid and well-formed.
I can telnet to port 1433 on the box without a connection refusal error so the port is open.
Thanks for any help you can provide.
And the answer is: it's a regression in the JDK, version 1.6.0 update 29 (you know, the version that is current on the Mac). See this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7105007
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.