Common questions
ID #1095
TCP Ports Needed for Communication to SQL Server Through a Firewall
INF: TCP Ports Needed for Communication to SQL Server Through a Firewall
| Article ID | : | 287932 |
| Last Review | : | February 8, 2006 |
| Revision | : | 5.1 |
This article was previously published under Q287932
SUMMARY
loadTOCNode(1, 'summary');
This article documents the minimum TCP/IP ports that are
required to communicate to SQL Server over a firewall.
MORE INFORMATION
loadTOCNode(1, 'moreinformation');
SQL Server is a Winsock application that communicates over
TCP/IP using the sockets network library. The SQL Server listens for incoming
connections on a particular port; the default port for SQL Server is 1433. The
port doesn't need to be 1433, but 1433 is the official Internet Assigned Number
Authority (IANA) socket number for SQL Server.
A client application communicates to SQL Server using the client-side network library Dbmssocn.dll (or Dbnetlib.dll for SQL Server 2000) and any client using Microsoft Data Access Components (MDAC) 2.6.
When the client establishes a TCP/IP connection, a three-way handshake is done. The client opens a source port and sends traffic to a destination port, which by default is 1433. The client source port in use is random, but is greater than 1024. By default, when an application requests a socket from the system for an outbound call, a port between the values of 1024 and 5000 is supplied. For more information, see "Microsoft Windows 2000 TCP/IP Implementation Details" at the following Microsoft Web site:
The best way to observe this behavior is to trace a client-to-server communication by using Microsoft Network Monitor or a network sniffer tool. To configure the firewall, you must allow traffic from *ANY* to 1433, and from 1433 to *ANY*, where *ANY* is a port greater than 1024.
The firewall software should allow this dynamic
allocation to occur through the use of rules. If it does, you can configure
1433 -> *ANY* established; this will dynamically open the response port
after a syn followed by a syn/ack by way of a statefull packet
inspection.
There is no way to limit the number of source TCP ports used for a SQL Server client to connect; this would defeat the purpose of having the client allocate a new, unused dynamic port. This is a TCP/IP standard that is defined for Winsock applications; this is not a limitation of SQL Server client communication.
In addition, a named instance of SQL Server 2000 will use a dynamic destination port by default. This port should be changed to a fixed port prior to configuring the firewall. The SQL Server Network Utility should be used to configure the destination port. See SQL Server Books Online for information on how to use the SQL Server Network Utility.
Otherwise, the client computer would need to open a random UDP port and the server UDP port 1434 will be used to send the instance name, and if the instance is clustered, the version of the SQL instance, the TCP port number that the instance is listening on, and the named pipe that the instance is using. However, if the goal is to minimize the number of ports open on the firewall, a static port number should be chosen for the default instance and any named instance. The client computers would need to be configured to connect to a particular ServerName or ServerName instance and specific port number.
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
A client application communicates to SQL Server using the client-side network library Dbmssocn.dll (or Dbnetlib.dll for SQL Server 2000) and any client using Microsoft Data Access Components (MDAC) 2.6.
When the client establishes a TCP/IP connection, a three-way handshake is done. The client opens a source port and sends traffic to a destination port, which by default is 1433. The client source port in use is random, but is greater than 1024. By default, when an application requests a socket from the system for an outbound call, a port between the values of 1024 and 5000 is supplied. For more information, see "Microsoft Windows 2000 TCP/IP Implementation Details" at the following Microsoft Web site:
http://technet.microsoft.com/en-us/library/bb726981.aspx (http://technet.microsoft.com/en-us/library/bb726981.aspx)
The server (in this case, SQL Server) then communicates to the
client by sending traffic from 1433 back to the port that the client
established.The best way to observe this behavior is to trace a client-to-server communication by using Microsoft Network Monitor or a network sniffer tool. To configure the firewall, you must allow traffic from *ANY* to 1433, and from 1433 to *ANY*, where *ANY* is a port greater than 1024.
*ANY* -> 1433
1433 -> *ANY*
In addition to using Microsoft Network Monitor, you can also use
the TCP/IP Netstat utility to illustrate this. Issuing netstat -an from an MS-DOS command window produces the following results
showing three established connections to SQL Server. This example uses
157.54.178.42 as the IP address of SQL Server and 157.54.178.31 as the client
IP address. The ports opened by the client are 1746, 1748, and 1750
respectively.
1433 -> *ANY*
Proto Local Address Foreign Address State TCP 157.54.178.42:1433 0.0.0.0:0 LISTENING TCP 157.54.178.42:1433 157.54.178.31:1746 ESTABLISHED TCP 157.54.178.42:1433 157.54.178.31:1748 ESTABLISHED TCP 157.54.178.42:1433 157.54.178.31:1750 ESTABLISHED
There is no way to limit the number of source TCP ports used for a SQL Server client to connect; this would defeat the purpose of having the client allocate a new, unused dynamic port. This is a TCP/IP standard that is defined for Winsock applications; this is not a limitation of SQL Server client communication.
In addition, a named instance of SQL Server 2000 will use a dynamic destination port by default. This port should be changed to a fixed port prior to configuring the firewall. The SQL Server Network Utility should be used to configure the destination port. See SQL Server Books Online for information on how to use the SQL Server Network Utility.
Otherwise, the client computer would need to open a random UDP port and the server UDP port 1434 will be used to send the instance name, and if the instance is clustered, the version of the SQL instance, the TCP port number that the instance is listening on, and the named pipe that the instance is using. However, if the goal is to minimize the number of ports open on the firewall, a static port number should be chosen for the default instance and any named instance. The client computers would need to be configured to connect to a particular ServerName or ServerName instance and specific port number.
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
216415 (http://support.microsoft.com/kb/216415/EN-US/)
HOW TO: Set Up SQL Server with Proxy Server
148942 (http://support.microsoft.com/kb/148942/EN-US/) How to Capture Network Traffic with Network Monitor
169292 (http://support.microsoft.com/kb/169292/EN-US/) The Basics of Reading TCP/IP Traces
269882 (http://support.microsoft.com/kb/269882/EN-US/) HOWTO: Use ADO to Connect to SQL Server That Is Behind a Firewall
Tags: -
Related entries:
Last update: 2008-04-11 05:42
Author: Oleg
Revision: 1.2