Quick answer: If SSMS times out reaching a remote MSSQL server, enable TCP/IP in SQL Server Configuration Manager, set a fixed port (1433) under IPAll, restart the SQL Server service, then open port 1433 in Windows Firewall scoped to your IP.
If SQL Server Management Studio times out when connecting to a remote MSSQL server, the cause is nearly always that the TCP/IP protocol is turned off or the firewall is blocking the port. Here is how to enable both safely.
On the server, open SQL Server Configuration Manager. Under SQL Server Network Configuration > Protocols for [your instance], right-click TCP/IP and choose Enable. This is disabled by default on new installs, which is why fresh servers refuse remote connections.
Double-click TCP/IP, open the IP Addresses tab, scroll to IPAll, and confirm TCP Port is 1433 (or set your own). Clear any value in TCP Dynamic Ports so the port stays fixed - a dynamic port changes on restart and breaks saved connections.
In Configuration Manager under SQL Server Services, restart the SQL Server service so the network changes load.
Create an inbound rule for TCP port 1433:
Windows Defender Firewall with Advanced Security -> Inbound Rules -> New Rule -> Port -> TCP -> 1433 -> Allow
For security, scope the rule to your office or application IP under the rule's Scope tab rather than allowing the whole internet. Exposing 1433 to everyone invites brute-force attempts.
From the server, run netstat -an | find "1433" and confirm a LISTENING entry. Then retry the connection from SSMS using server-ip,1433.
Why is TCP/IP off by default?
New SQL Server installs disable it for security, which is why fresh servers refuse remote connections until you enable it.
Should I open 1433 to everyone?
No - scope the firewall rule to known IPs; an open 1433 invites brute-force attempts.
On a SoftSys managed Windows VPS our team configures TCP/IP, the fixed port, and an IP-scoped firewall rule as part of a managed SQL Server setup, so remote access works without exposing the database to the open internet.
