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.
Related
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.
Sorry if this is not the place to ask, but I am not sure if there is a forum for SQL port questions. It seems that my SQL client is using a random port to connect to the SQL server, in spite of me stipulating a specific port in the ODBC DSN connector. this is from Microsoft Network Monitor I have included the image to better illustrate what I mean.
You are reading it wrong. I see two kinds of connections, from WEBSERVER to 192.*.6 which I assume to be the Sql Server (the requests), and vice versa (the responses from Sql back to the Web Server).
When WEBSERVER is making a request, the DstPort is always 49252. The SrcPort fluctuates in that case because that is just how TCP/IP works (and that is also how multiple parallel connections can be distinguished). The Sql Server then always replies to whatever port number initiated the request.
It is expected that the source port (client) be random. The destination port (server) will be constant. When a TCP/IP client connects, it chooses an unused client port and connects to the server listening on a known port. This is basically how TCP/IP sockets work.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
My application is using some old shared code that we have here to generate the connection string. So until now I didn't really know what was happening there. Due to a new requirement I found myself needing to examine the connection strings that I'm using to connect to the SQL Server.
What I found that was that for the connection string be built to connect to each of the SQL instances did not include Network Library, nor did they include the port number as part of the Data Source. The Data Source was just set to <Server Name>/<Instance Name>. I did find in the MS documentation that if the Network Library is not included then it is treated as (local), but it doesn't really explain how (local) is treated.
So my question is why is a connection string in this format able to connect to the SQL Server instance that runs on the non-default port? will this only work if the instances are on the local machine, or local network? Can I put <ip>/<sql instance> without the port if the server is remote?
I just need some clarity on how this works, and when is the port number needed and when it is optional as I'm trying to make my connection UI as simple as possible for our users.
There is such a thing called "SQL Server Browser Service":
http://technet.microsoft.com/en-us/library/ms181087(v=sql.105).aspx
It is intended to provide clients with information about sql server instances, ports. It actually listens on UDP port 1434.
With this service turned off you will still be able to connect to the instance, but you need to specify TCP/IP port.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
Just out of curiousity, why don't you just have them setup as named instances both running on the default of 1433 ?
As for why it works, if you search for SQL Configuration in your start menu, you'll find a screen similar to this.
Sql Server supports a number of different ways of connecting. TCP/IP is one way (ie IP addresses and ports) but it also supports a Shared Memory connection if you're on the local machine. that is, if you SQL Server executable, and management studio/client are also on the same machine.
At a guess I'd say it defaults to shared memory when you specify local and therefore you don't need to specify the port.
You could test this out by temporarily disabling shared memory in the above config, and see if your (local)\InstanceName stops working.
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
Check out this pic of my SQL 2008 Management Configuration screen for TCP:
I need to know what port I am running on. Based on this previous post, I don't believe that it is 1433, which I guess is the default.
When I check my port number in SQL Config Mgr., it is blank. Does this suggest a default port? Note that I have multiple SQL Server instances on the db server. One 2000 instance and two 2008 instances. I want to know the port of the 2008b instance.
The first display is for TCP. I'm not sure what VIA is, but check it out:
Can you help?
Update
I restarted my sql2008b instance and checked the log to look for a msg that indicated the port that it was using. It showed this:
2010-05-22 20:06:29.27 Server A self-generated certificate was successfully loaded for encryption.
2010-05-22 20:06:29.27 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQL2008B ].
2010-05-22 20:06:29.27 Server Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQL2008B\sql\query ].
2010-05-22 20:06:29.32 Server Server is listening on [ 127.0.0.1 <ipv4> 5786].
2010-05-22 20:06:29.32 Server Dedicated admin connection support was established for listening locally on port 5786.
Yet, when I tried to log on using the following as the server name:
(local)\sql2008b,5786
I still was unable to connect, while logged onto the remote box (hence using "local".)
A suggstion was made below to set the port myself. This occurred to me to try but there are a couple of things that are botehring me:
1) Why can I connect to my SQL 2000 instance without monkeying with anything to get it to work (but not my 2008 instance)?
2) The IP addresses shown in TCP1 and 2 don't appear correct. The one I blacnked out, presumably theIP address of my router and the one needed to make my server visible on the Internet, was not correct. Also , the local 192.168.1.100 was not correct. The db server server's IP adress end in a different number. perhaps I sh
TCP/IP is disabled in your screenshot so it isn't listening on any port. On start up when enabled it will write an entry to the SQL Server logs telling you what port it is listening to. (Accessible through Management Studio tree view Management -> Sql Server Logs nodes)
You might find this link useful How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port
Also do you have the SQL Server Browser service running on that machine (it might help you connecting to the right instance)?
If TCP/IP is disabled, the service can still listen via Named Pipes (for network connections) or Shared Memory (for local connections), so it will work with TCP/IP disabled if you choose to got that route.
On startup, there will be an event log entry to tell you what connection methods it's listening for, or you can do a "NETSTAT -A" from the command line to see which ports the server is listening on in general.