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.
Related
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 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'm attempting to access a SQL Server which is exposed through an IP NAT mapping. All the ports are open. I don't know the details of the NAT, if it's relevant, since that's somewhere else in the company hidden in a pile of red tape.
Here's what I figured out. When you attempt to access a named instance of SQL Server, the client asks what port the named instance is running on. If I RDP into the SQL Server I can use netstat to find out the port of that instance and can successfully connect through the firewall. However, connecting via the instance name doesn't work. My guess is that the server is responding at some point with it's internal IP address and the client is using that.
Does anyone know if this is true and if there's a way around it?
The instance listening port protocol discovery is subject to the SQL Server Browser Service. This uses UDP on 1434. With a NAT forwarding of UDP 1434 your client should be able to interact with the SQL Server Browser Service (if the SQL Server Browser's UDP response packet can reach back the client, a big if), but even a successful interaction will put your client in a tight spot: now that it knows the SQL Server dynamic listen port, how does it reach it? The NAT would have to dynamically forward the port picked by SQL Server, or it would have to forward all ports.
What I recommend is to have your SQL Server listen on a per-configured, statically assigned, port. See How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. Have your NAT forward that port. Then in your client use this port explicitly in the connection string. Do not use 1433, the standard port, since I assume that ahead of the NAT is the public internet and 1433 is subject to constant and frequent scans from all sort of bots and vile clusters.
Configure the named instance to run on a static port using SQL Server Configuration Manager. In configuration manager, SQL Server Network Configuration -> Protocols for <named instance> -> TCP/IP -> Properties.
Then supply the hostname and port for the named instance in the connection string. The hostname and port number are specified in the following format (assuming hostname is Test and listen port is 1492):
... Server='Test,1492'; ...
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.
If I can ping my DB server, is my SQL Server connection guaranteed to work?
I am using a default connection string in my code.
My program runs fine locally but overseas sites are having issues and I am wondering if SQL might be using a TCP or UDP port that is still blocked.
Here is the connection string "Data Source=xxxx.xxxx.com; Initial Catalog = xxxxx; User ID=xxxxx;password=xxxxx"
As far as I understand your question you are asking whether ICMP "ping" packet which returns guarantees you can open a connection on a particular TCP port? The answer is NO. It is also not the other way around - "ping" packets might be blocked by a firewall.
telnet xxxx.xxxx.com 1433 might be a better indicator.
No. The SQL Server Service must at least be running on the server for any mssql connections to work. The server itself can be up - running and pingable without the SQL Server Serice running.
You might also need to check whether the TCP/IP protocol is enabled using SQL Server Configuration Manager. Even when MSSQLSvc is running, it might not respond to remote requests.