1. Confirm the SQL port and instance

On the SQL Server machine:

1. Open SQL Server Configuration Manager →
   SQL Server Network Configuration → Protocols for <instance>.
2. Ensure TCP/IP is Enabled.
3. In TCP/IP → Properties → IP Addresses tab:
   • Under IPAll, note:
     • TCP Port (e.g., 1433), and
     • Ensure TCP Dynamic Ports is blank if you’re using a fixed port.
4. Restart the SQL Server service.

You must know which port to test (e.g., 1433).

---

2. Test connectivity ignoring SQL Server (pure network test)

From the client machine (the machine connecting to SQL):

3. Temporarily disable Windows Defender Firewall (to isolate the cause)

Only do this briefly, in a safe test environment.

On the SQL Server machine:

1. Open Control Panel → System and Security → Windows Defender Firewall.
2. Click Turn Windows Defender Firewall on or off.
3. For the profile in use (Domain/Private/Public), select Turn off Windows Defender Firewall.
4. Click OK.

Then, from the client, rerun:

powershell

Test-NetConnection -ComputerName SERVER_NAME_OR_IP -Port 1433

and/or try connecting with SSMS.

Interpretation:

• If it works when firewall is OFF, and fails when firewall is ON →
  The firewall is causing/participating in the problem.
• If it fails even when firewall is OFF → The cause is not Windows Firewall (look at SQL config, other firewalls, routing, etc.).

Re‑enable the firewall right after the test.

---

4. Verify or create proper inbound firewall rules for SQL

If the firewall is confirmed as the blocker, fix it by adding rules (rather than leaving the firewall disabled).

On the SQL Server machine:

1. Open Windows Defender Firewall with Advanced Security.

2. Go to Inbound Rules.

3. Look for an existing rule:

   • Allowing sqlservr.exe,
   • Or allowing TCP port 14331433 (or your SQL port).

4. If none exist or not enabled, create one:

   • Right‑click Inbound Rules → New Rule…
   • Choose Port → Next.
   • Protocol: TCP.
     Specific local ports: 1433 (or your port) → Next.
   • Select Allow the connection → Next.
   • Apply to Domain and Private (and Public if needed) → Next.
   • Name: e.g., SQL Server TCP 1433 → Finish.

If you use a named instance with dynamic ports, either:

• Set a fixed port (recommended), or
• Also allow:
  • SQL Server Browser service inbound and
  • UDP port 14341434.

---

5. Confirm firewall rule works

With the firewall ON and rule created:

From the client:

1. Test connection again:

powershell

Test-NetConnection -ComputerName SERVER_NAME_OR_IP -Port 1433

• Should now show TcpTestSucceeded : True.

2. Test with SSMS:

• Server name:
  • Default instance: SERVER_NAME or SERVER_IP
  • Named instance: SERVER_NAME\INSTANCE_NAME or SERVER_NAME,1433
• Try connecting. If SSMS works and Test-NetConnection succeeds, firewall is no longer the blocker.

---

6. Quick decision tree

From the client, testing port 14331433:

1. Firewall OFF → Test-NetConnection Succeeds
   Firewall ON → Fails
   → Windows Firewall is blocking. Fix rules.

2. Firewall OFF → Test-NetConnection Fails
   → Not Windows Firewall:

• SQL service not listening
• Wrong port
• Network routing/VLAN issues
• Other security appliances / third‑party firewall.