Understanding and Configuring SQL Server Ports for Firewall Access

Firewall systems are essential components of network security, acting as gatekeepers to prevent unauthorized access to computer resources. In the context of SQL Server, a firewall, while crucial for security, can also inadvertently block legitimate connection attempts if not properly configured. When a firewall is enabled, it meticulously examines incoming network packets, and only allows those that adhere to a predefined set of rules. For SQL Server to be accessible through a firewall, specific configurations must be implemented on the machine hosting the SQL Server instance. This article delves into the intricacies of configuring Windows Firewall to ensure seamless and secure access to SQL Server, focusing on the pivotal role of Sql Server Ports. While the principles discussed primarily revolve around Windows Firewall, they are broadly applicable to any firewall solution.

It’s important to note that this guide provides a comprehensive overview of firewall configuration tailored for SQL Server administrators. For in-depth and authoritative information on firewalls, it is recommended to consult official firewall documentation, such as the Windows Firewall security deployment guide.

For those already familiar with Windows Firewall management and seeking specific configuration guidance, you can directly navigate to more advanced sections detailing the practical steps involved in opening SQL Server ports within the firewall.

Decoding Basic Firewall Functionality

Firewalls operate on a rule-based system, scrutinizing each incoming packet against a defined set of criteria. This process determines whether a packet is permitted to proceed or should be discarded.

Here’s a breakdown of the firewall’s decision-making process:

Packet Acceptance: If an incoming packet aligns with the established firewall rules, it is deemed legitimate and passed on to the TCP/IP protocol stack for further processing. This allows the communication to proceed as intended.
Packet Rejection: Conversely, if a packet fails to meet the criteria defined by the firewall rules, it is treated as potentially unauthorized or malicious.
- Discarding the Packet: In such cases, the firewall immediately discards the packet, preventing it from reaching the intended destination. This effectively blocks unauthorized access attempts.
- Logging (Optional): For auditing and security monitoring purposes, firewalls often have a logging feature. When enabled, any rejected packet triggers the creation of an entry in the firewall’s log file. This log provides a record of blocked attempts, which can be invaluable for security analysis and troubleshooting.

The firewall’s list of allowed traffic rules is populated through two primary methods:

Automatic Rule Creation: When a computer behind a firewall initiates communication, the firewall intelligently creates temporary rules to permit the response traffic. This is known as “solicited traffic.” The firewall anticipates and allows the returning packets related to the initiated connection without requiring any manual configuration.
Manual Exception Configuration: Administrators can manually define exceptions within the firewall. These exceptions grant specific permissions, either allowing access to particular programs or opening designated ports on the computer. This is crucial when the computer acts as a server, listener, or peer, needing to accept unsolicited incoming traffic. To enable connections to SQL Server ports, manual firewall configuration is generally necessary.

Developing an effective firewall strategy is a nuanced process that goes beyond simply opening or closing specific ports. A comprehensive approach requires careful consideration of all available rules and configuration options to align with your organization’s security needs. This article does not exhaustively cover every firewall configuration aspect. It is highly recommended to review detailed documentation on firewall strategies to design a robust security posture.

Understanding Default Firewall Configurations

Before making any modifications, it’s essential to ascertain the current firewall status on your operating system. If the system has been upgraded from an older version, existing firewall settings might have been carried over. Furthermore, domain-level Group Policies or administrative settings can influence firewall configurations.

It’s critical to remember that adjusting firewall settings has broader implications. Enabling or modifying the firewall impacts all programs relying on network access, including essential services like file and print sharing and remote desktop connections. Administrators must holistically assess all applications running on the system before implementing any firewall changes to avoid disrupting legitimate network operations.

Tools for Firewall Configuration

Windows Firewall settings can be managed through several tools, providing flexibility based on user preference and administrative needs:

Microsoft Management Console (MMC) – Windows Firewall with Advanced Security

The Windows Firewall with Advanced Security MMC snap-in offers a comprehensive interface for configuring advanced firewall settings. This tool provides a user-friendly way to navigate and manage a wide array of firewall options, encompassing all firewall profiles. Its intuitive design makes it a preferred choice for many administrators. More detailed instructions on using this snap-in are provided in the section Using the Windows Firewall with Advanced Security Snap-in.

PowerShell

PowerShell provides a powerful command-line interface for firewall management, enabling automation and scripting of configurations. For instance, the following PowerShell commands demonstrate how to open TCP port 1433 and UDP port 1434, the default SQL Server ports for the default instance and the SQL Server Browser Service respectively:

New-NetFirewallRule -DisplayName "SQLServer default instance" -Direction Inbound -LocalPort 1433 -Protocol TCP -Action Allow
New-NetFirewallRule -DisplayName "SQLServer Browser service" -Direction Inbound -LocalPort 1434 -Protocol UDP -Action Allow

For a wider range of PowerShell examples and advanced usage, refer to the official documentation for New-NetFirewallRule.

Command-Line with netsh

The netsh.exe command-line tool is a versatile administrator utility for configuring and monitoring Windows-based computers. It can be used interactively at a command prompt or within batch scripts for automated firewall management. netsh operates by directing commands to specific “helpers,” which are Dynamic Link Library (.dll) files extending the tool’s functionality. The advfirewall helper is dedicated to managing Windows Firewall with Advanced Security.

Many firewall configurations achievable through the MMC snap-in can also be performed via the command line using netsh advfirewall. For example, to open TCP port 1433, the standard SQL Server port, you can execute the following command in an elevated command prompt:

netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN

For comprehensive information on netsh and its capabilities, consult the following resources: (Links to netsh documentation would be inserted here in a complete article).

Firewall Configuration on Linux

While this article primarily focuses on Windows Firewall, it’s important to acknowledge that SQL Server can also run on Linux. On Linux systems, firewall configuration is equally crucial. Similar to Windows, you must open the necessary ports for SQL Server services to function correctly. However, the specific procedures vary depending on the Linux distribution and the firewall software being used (e.g., iptables, firewalld, ufw).

For illustrative examples of firewall configuration on Linux, consult the documentation for your specific Linux distribution and firewall. (Links to Linux firewall documentation examples would be placed here).

Essential Ports Used by SQL Server

Understanding the ports used by different SQL Server components is fundamental to effective firewall configuration. The following tables provide a detailed breakdown of SQL Server ports categorized by service.

Ports for the Database Engine

The Database Engine, the core of SQL Server, utilizes specific ports for communication. By default, common SQL Server ports include TCP 1433, 4022, 135, 1434, and UDP 1434. The table below elaborates on the purpose of each of these SQL Server ports. Note that named instances of SQL Server often employ Dynamic ports which are discussed in more detail later.

Scenario	Port	Comments
Default instance running over TCP	TCP port 1433	This is the most frequently used SQL Server port to allow through a firewall. It facilitates standard connections to the default instance of the Database Engine. It is also relevant for named instances if they are the sole instance on the server. (Named instances have specific port considerations, detailed in Dynamic ports).
Named instances with default port configuration	TCP Dynamic Port (determined at startup)	Named instances, by default, use dynamic SQL Server ports. The specific TCP port is dynamically assigned each time the Database Engine starts. See the Dynamic ports section for a detailed explanation. UDP port 1434 may also be necessary for the SQL Server Browser Service when using named instances.
Named instances with fixed port	Administrator-defined TCP Port	Administrators can configure named instances to use a static, fixed SQL Server port. See the Dynamic ports section for further discussion.
Dedicated Admin Connection (DAC)	TCP port 1434 (default instance), other ports for named instances (check error log)	By default, remote connections to the DAC are disabled. To enable remote DAC, utilize the Surface Area Configuration facet. Refer to Surface area configuration for more information.
SQL Server Browser service	UDP port 1434	The SQL Server Browser service listens for incoming connection requests directed to named instances. It then provides the client with the corresponding dynamic TCP SQL Server port number for the requested named instance. This service is typically started when named instances are in use. It is not required if clients are configured to connect directly to the static port of a named instance.
Instance with HTTP endpoint	Configurable TCP port (default TCP port 80 for `CLEAR_PORT`, 443 for `SSL_PORT`)	Used for HTTP connections via a URL. The SQL Server port can be specified during HTTP endpoint creation.
Default instance with HTTPS endpoint	TCP port 443	Used for secure HTTPS connections via a URL. HTTPS employs Transport Layer Security (TLS), formerly known as Secure Sockets Layer (SSL).
Service Broker	TCP port 4022 (default). Query `sys.tcp_endpoints` to verify: `SELECT name, protocol_desc, port, state_desc FROM sys.tcp_endpoints WHERE type_desc = 'SERVICE_BROKER'`	Service Broker does not have a fixed default SQL Server port, but TCP port 4022 is conventionally used in documentation examples.
Database Mirroring	Administrator-chosen TCP port. Query `sys.tcp_endpoints` to determine: `SELECT name, protocol_desc, port, state_desc FROM sys.tcp_endpoints WHERE type_desc = 'DATABASE_MIRRORING'`	Database mirroring also lacks a default SQL Server port. TCP port 5022 or 7022 are frequently used in examples. Carefully configure firewall rules to avoid disrupting mirroring endpoints, especially in high-safety mode with automatic failover, to maintain quorum. See Specify a Server Network Address (Database Mirroring).
Replication	Standard Database Engine ports (TCP port 1433 for default instance). Web synchronization and FTP/UNC snapshot access require additional ports. FTP (TCP port 21), HTTP (TCP port 80), File Sharing (UDP 137, 138, TCP 139/445)	Replication connections to SQL Server utilize the typical Database Engine ports. Web synchronization and snapshot distribution via FTP or UNC paths necessitate opening additional ports. For HTTP sync, IIS endpoint (default port 80) communicates with backend SQL Server on standard ports. FTP transfer in Web synchronization is between IIS and the SQL Server publisher, not directly with the subscriber.
Transact-SQL debugger	TCP port 135 (See Special Considerations for Port 135), IPsec exception might also be needed.	When using Visual Studio debugger on the host machine, add `devenv.exe` to firewall exceptions and open TCP port 135. For Management Studio, add `ssms.exe` and open TCP port 135. Refer to Configure firewall rules before running the Transact-SQL debugger.

For detailed step-by-step instructions on configuring Windows Firewall for Database Engine access, consult Configure Windows Firewall for Database Engine access.

Dynamic Ports and SQL Server

Named instances of SQL Server, including SQL Server Express, are configured by default to use dynamic SQL Server ports. Upon each startup of the Database Engine, it dynamically selects an available port. While a named instance might use TCP port 1433 if it’s the only instance, in environments with multiple instances, different TCP SQL Server ports are typically assigned. This dynamic port allocation poses a challenge for firewall configuration, as the SQL Server port can change unpredictably after each restart.

To simplify firewall management in scenarios with named instances, it’s highly recommended to reconfigure the Database Engine to utilize a fixed, static SQL Server port. This ensures consistent port usage and simplifies firewall rule creation. Refer to Configure SQL Server to listen on a specific TCP port for guidance on setting a static port.

Alternatively, instead of specifying a fixed port, you can create a firewall exception for the SQL Server program executable (sqlservr.exe). While this approach works, the dynamically assigned SQL Server port will not be visible in the “Local Port” column within the Windows Firewall with Advanced Security MMC snap-in’s Inbound Rules. This can complicate auditing and port management. Furthermore, service packs or cumulative updates might alter the path to the sqlservr.exe file, potentially invalidating the program-based firewall rule.

For instructions on adding a program exception for SQL Server using Windows Firewall with Advanced Security, see Use the Windows Firewall with Advanced Security snap-in.

Ports for Analysis Services

SQL Server Analysis Services (SSAS) also relies on specific SQL Server ports for communication. The default SQL Server ports for SSAS and related services are TCP 2382, 2383, 80, and 443. The following table details these ports.

Feature	Port	Comments
Analysis Services	TCP port 2383 (default instance)	This is the standard SQL Server port for the default instance of Analysis Services.
SQL Server Browser service	TCP port 2382 (named instances only)	For named instances of Analysis Services, client connection requests without a specified SQL Server port are directed to port 2382, where the SQL Server Browser listens. The Browser service then redirects the request to the actual dynamic port used by the named instance.
Analysis Services via IIS/HTTP (PivotTable® Service using HTTP)	TCP port 80	Used for HTTP connections to Analysis Services through IIS and a URL.
Analysis Services via IIS/HTTPS (PivotTable® Service using HTTPS)	TCP port 443	Used for secure HTTPS connections to Analysis Services through IIS and a URL. HTTPS uses TLS encryption.

When users access Analysis Services through IIS and the internet, the port on which IIS listens (typically port 80 or 443) must be open in the firewall. The client connection string then needs to specify this IIS port. In such IIS-mediated scenarios, direct access SQL Server ports to Analysis Services (like 2389 and 2382) should be restricted, along with any other unnecessary ports, to enhance security.

For step-by-step guidance on configuring Windows Firewall for Analysis Services, refer to Configure the Windows Firewall to Allow Analysis Services Access.

Ports for Reporting Services

SQL Server Reporting Services (SSRS) utilizes TCP SQL Server ports 80 and 443 by default. The table below provides more details.

Feature	Port	Comments
Reporting Services Web Services	TCP port 80	Used for HTTP connections to Reporting Services via a URL. It is recommended to avoid using the pre-configured firewall rule “World Wide Web Services (HTTP).” See Interaction with Other Firewall Rules for more information.
Reporting Services via HTTPS	TCP port 443	Used for secure HTTPS connections via a URL. HTTPS uses TLS. Similarly, avoid using the pre-configured rule “Secure World Wide Web Services (HTTPS).” See Interaction with Other Firewall Rules.

When Reporting Services interacts with the Database Engine or Analysis Services, the relevant SQL Server ports for those services must also be open in the firewall. For detailed steps to configure Windows Firewall for Reporting Services, see Configure a firewall for report server access.

Ports for Integration Services

The following table lists the SQL Server ports utilized by SQL Server Integration Services (SSIS).

Feature	Port	Comments
Microsoft remote procedure calls (MS RPC) – Used by Integration Services runtime	TCP port 135 (See Special Considerations for Port 135)	Integration Services runtime uses DCOM on port 135. The Service Control Manager uses port 135 for service management tasks like starting, stopping, and sending control requests. This SQL Server port cannot be changed. Opening this port is only necessary if you are connecting to a remote instance of Integration Services from Management Studio or a custom application.

For step-by-step instructions on configuring Windows Firewall for Integration Services, refer to Integration Services Service (SSIS Service).

Other Ports and Services Relevant to SQL Server

Beyond the core services, SQL Server may depend on other Windows components and services that utilize specific ports.

Scenario	Port	Comments
Windows Management Instrumentation (WMI) – For Configuration Management	DCOM-assigned ports, potentially TCP port 135 (See Special Considerations for Port 135)	WMI operates within a shared service host and utilizes dynamically assigned ports through DCOM. It may also use TCP port 135. SQL Server Configuration Manager uses WMI for service management. It’s recommended to use the pre-configured rule group “Windows Management Instrumentation (WMI).” See Interaction with Other Firewall Rules.
Microsoft Distributed Transaction Coordinator (MS DTC)	TCP port 135 (See Special Considerations for Port 135)	If your applications employ distributed transactions, firewall configuration for MS DTC traffic is necessary between MS DTC instances and between MS DTC and resource managers like SQL Server. Utilize the pre-configured “Distributed Transaction Coordinator” rule group. In clustered environments with a shared MS DTC resource group, add `sqlservr.exe` as a firewall exception.
Management Studio “Browse” button	UDP port 1434	Management Studio’s “Browse” functionality uses UDP to communicate with the SQL Server Browser Service to discover available instances. See SQL Server Browser Service (Database Engine and SSAS). UDP is connectionless. Windows Firewall has a setting (UnicastResponsesToMulticastBroadcastDisabled Property of the INetFwProfile Interface) that governs unicast responses to broadcast UDP requests. If set to `TRUE`, no unicast responses are allowed, and service enumeration fails. If `FALSE` (default), unicast responses are permitted for 3 seconds. Network congestion or latency, or heavily loaded servers, might lead to incomplete instance lists due to this timeout.
IPsec traffic	UDP port 500, UDP port 4500	If domain policy mandates IPsec for network communication, add UDP ports 4500 and 500 to firewall exceptions. IPsec can be configured using the “New Inbound Rule Wizard” in Windows Firewall snap-in. See Use the Windows Firewall with Advanced Security snap-in.
Windows Authentication with Trusted Domains	Authentication-related ports	Firewalls must allow traffic for Windows Authentication requests. Refer to How to configure a firewall for Active Directory domains and trusts for details.
SQL Server and Windows Clustering	Clustering-specific ports (beyond SQL Server ports)	Clustering requires additional ports not directly related to SQL Server services. See Enable a network for cluster use.
URL namespaces reserved in HTTP Server API (HTTP.SYS)	Typically TCP port 80, but configurable	For general information, see Configuring HTTP and HTTPS. For SQL Server specific URL reservation information using HttpCfg.exe, see About URL reservations and registration (Report Server Configuration Manager).

Special Considerations for Port 135

Port 135 is crucial for RPC (Remote Procedure Call) communication, which is used by various Windows services, including some SQL Server components. When RPC utilizes TCP/IP or UDP/IP, inbound ports are dynamically assigned to system services as needed, typically above port 1024 (these are known as “random RPC ports”). RPC clients rely on the RPC endpoint mapper (port 135) to discover these dynamic SQL Server ports.

While some RPC-based services allow configuration for specific static ports, or restricting the dynamic port range, port 135 itself remains a fixed, well-known entry point. Unfortunately, port 135’s ubiquity makes it a frequent target for malicious attacks. When opening port 135 in a firewall, it’s paramount to restrict the scope of the firewall rule as narrowly as possible to mitigate security risks.

Further details on port 135 and RPC can be found in these resources: (Links to resources about port 135 would be inserted here).

Interaction with Other Firewall Rules

Windows Firewall employs a system of rules and rule groups for configuration management. Each rule or group is associated with a specific program or service. Critically, these associated programs or services can modify or even delete their own rules without explicit administrator intervention.

For example, the rule groups “World Wide Web Services (HTTP)” and “World Wide Web Services (HTTPS)” are linked to IIS (Internet Information Services). Enabling these rules opens ports 80 and 443, which might inadvertently enable functionality for SQL Server features that also rely on these ports. However, IIS administrators might modify or disable these rules independently, potentially disrupting SQL Server access if it’s relying on them.

Therefore, if you are using ports 80 or 443 for SQL Server services, it is best practice to create dedicated firewall rules or rule groups specifically for SQL Server. This ensures that your intended SQL Server port configuration remains independent and unaffected by changes to other service’s firewall rules, like those managed by IIS.

The Windows Firewall with Advanced Security MMC snap-in operates on an “allow-any-match” principle. If multiple rules apply to the same port (even with different parameters), traffic matching any of those rules will be permitted. For instance, if one rule allows port 80 traffic from the local subnet, and another rule allows port 80 from any address, the effective outcome is that all traffic to port 80 will be allowed, regardless of the source.

To maintain effective and granular control over SQL Server access, administrators should periodically review all firewall rules enabled on the server. This proactive approach helps identify and rectify any unintended or overly permissive rules that could compromise security.

Understanding Firewall Profiles

Firewall profiles are a key concept in Windows Firewall, enabling the operating system to adapt firewall policies based on the network environment. Windows identifies and categorizes networks based on connectivity, connections, and network type.

Windows Firewall with Advanced Security defines three network location types, each with its own profile:

Domain: This profile is automatically applied when Windows can authenticate connectivity to the domain controller of the domain the computer is joined to. It is typically used in corporate network environments.
Private: Networks designated as “private” are considered trusted, such as home or small business networks. Users or applications can classify networks as private.
Public: Any network that is not a domain network is initially categorized as public. Networks in public locations like airports, coffee shops, or direct internet connections should remain classified as public due to the inherent security risks.

Administrators can configure distinct firewall policies for each profile. Only one profile is active at any given time, and profile application follows a defined order of precedence:

Domain Profile: Applied if all network interfaces on the computer are authenticated to a domain controller within the domain the computer is a member of.
Private Profile: Applied if all interfaces are either authenticated to a domain controller or connected to networks classified as private.
Public Profile: Applied in all other scenarios, when neither the domain nor private profile conditions are met.

The Windows Firewall with Advanced Security MMC snap-in is the central tool for viewing and configuring all firewall profiles. In contrast, the simpler “Windows Firewall” item in the Control Panel only allows configuration of the currently active profile.

Additional Firewall Settings via Control Panel

The “Windows Firewall” Control Panel item, while less feature-rich than the MMC snap-in, provides a convenient way to manage basic firewall settings for the current profile. A key security enhancement is the ability to restrict port openings to specific computers or subnets, limiting exposure to potential threats.

Using the “Windows Firewall” item in Control Panel configures only the currently active firewall profile.

Restricting Firewall Exception Scope via Control Panel

Open the Windows Firewall item in Control Panel.
Navigate to the Exceptions tab.
Select a program or port from the list and click Properties or Edit.
In the “Edit a Program” or “Edit a Port” dialog, click Change Scope.
Choose the desired scope option:
- Any computer (including computers on the Internet): Not recommended for production SQL Server environments due to significant security risks. This option allows any computer on the internet that can reach your computer to connect to the specified program or port. While it might be necessary for publicly accessible services, it drastically increases the attack surface. Enabling this option often also enables Network Address Translation (NAT) traversal, further increasing exposure.
- My network (subnet) only: A more secure option than “Any computer.” Only computers within the local subnet of your network are permitted to connect to the program or port. This is suitable for restricting access within a trusted internal network.
- Custom list: The most restrictive option. Only computers with IP addresses explicitly listed in the custom list are allowed to connect. This provides the highest level of control and security, but requires careful management of the IP address list. While more secure than “My network (subnet) only,” it’s important to note that client computers using DHCP might change IP addresses, breaking connectivity. Also, an unauthorized computer could potentially assume a listed IP address. The “Custom list” is best suited for explicitly authorizing specific servers with static IP addresses.
It is crucial to understand that IP address spoofing is possible. Firewall rule restrictions are only as robust as the underlying network infrastructure security.

Utilizing the Windows Firewall with Advanced Security Snap-in

The Windows Firewall with Advanced Security MMC snap-in provides a wealth of advanced configuration options not available in the basic Control Panel interface. The snap-in includes wizards to guide rule creation and exposes settings such as:

Encryption settings for connections
Service-specific restrictions for rules
Restricting connections based on computer names
Restricting connections to specific users or profiles
Edge traversal configuration for bypassing NAT routers
Configuration of outbound firewall rules (in addition to inbound)
Security rule configuration for connection security
Requiring IPsec for inbound connections for enhanced security

Creating a New Firewall Rule with the New Rule Wizard

Open the Run dialog from the Start Menu, type wf.msc, and press OK.
In the Windows Firewall with Advanced Security MMC snap-in, in the left pane, right-click Inbound Rules, and select New Rule….
The New Inbound Rule Wizard will launch. Follow the wizard prompts to configure the rule according to your specific requirements.

Adding a Program Exception for the SQL Server Executable

From the Start Menu, type wf.msc and press Enter or select the wf.msc search result to open Windows Defender Firewall with Advanced Security.
In the left pane, select Inbound Rules.
In the right pane, under Actions, click New rule…. The New Inbound Rule Wizard will open.
On the Rule Type page, select Program and click Next.
On the Program page, choose This program path. Click Browse… to locate your SQL Server instance’s executable file. The program is named sqlservr.exe. It is typically located at C:Program FilesMicrosoft SQL ServerMSSQL<versionnumber>.<instancename>MSSQLBinnsqlservr.exe. Click Next.
On the Action page, select Allow the connection and click Next.
On the Profile page, ensure all three profiles (Domain, Private, Public) are checked to apply the rule across all network types. Click Next.
On the Name page, enter a descriptive name for the rule (e.g., “SQL Server Database Engine”). Click Finish.

For more in-depth information about endpoints and SQL Server ports, consult the official SQL Server documentation. (Links to relevant SQL Server endpoint documentation would be added here).

Troubleshooting Firewall Configuration Issues

Diagnosing firewall-related connection problems often requires systematic troubleshooting. The following tools and techniques can be invaluable:

Effective Port Status Analysis: The effective status of a port is determined by the aggregation of all firewall rules that pertain to that port. When troubleshooting blocked port access, carefully review all rules related to the port in question. Use the Windows Firewall with Advanced Security MMC snap-in to examine inbound and outbound rules, sorting them by port number to gain a clear overview.
Active Port Review: Examine the ports that are actively listening on the SQL Server machine. This involves:
- Verifying Listening TCP/IP Ports: Use tools like netstat (described below) to list active TCP and UDP ports.
- Port Status Verification: Check the operational state of the identified ports.
PortQry Utility: The PortQry command-line utility is a powerful tool for querying the status of TCP/IP ports. It can report a port status as “LISTENING,” “NOT LISTENING,” or “FILTERED.” A “FILTERED” status indicates that the port is likely blocked by a firewall, and PortQry might not receive a response. PortQry is available for download from the Microsoft Download Center.

Listing Listening TCP/IP Ports using netstat

The netstat command-line utility is a built-in Windows tool for displaying active TCP connections and network statistics, including listening ports.

Open a Command Prompt window as an administrator.
At the command prompt, type netstat -n -a and press Enter.
- The -n switch instructs netstat to display addresses and port numbers numerically, rather than attempting to resolve names, which speeds up output.
- The -a switch tells netstat to display all listening TCP and UDP ports on the computer.

The output will list active connections and listening ports, allowing you to verify if the expected SQL Server ports are indeed in a “LISTENING” state.