It connects on the server and fails from every desk in the office. Nine times out of ten the engine is fine and the firewall is doing its job — here is how to open exactly the right door, and no more.
SQL Server setup does not open the Windows Firewall for you, deliberately. A database should never become network-visible by accident. So after a fresh install, local tools connect and remote ones time out. The fix takes two minutes — but which port you open depends on your instance type, and opening the wrong things is its own security problem.
A default instance listens on TCP port 1433, fixed and documented. On the server, open Windows Defender Firewall's inbound rules and add one allowing TCP 1433. In PowerShell (run as administrator) the same rule is one line: New-NetFirewallRule -DisplayName "SQL Server 1433" -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. Then set the rule's scope to your local subnet — the office LAN needs the database; the internet does not, and the rule should say so. Test from another PC with SSMS before touching anything else.
A named instance starts on a dynamic port that can change at restart, so no single firewall rule can follow it. The tidy solution: open SQL Server Configuration Manager, find the instance's TCP/IP protocol settings, clear the dynamic port field and set a fixed TCP Port (1433's neighbours like 14330 are a common choice — anything free and documented), restart the instance, then write the firewall rule for your chosen port. Clients can then connect with ServerName,Port in the name and nobody depends on the Browser service at all.
When a client types ServerName\InstanceName, it asks the SQL Server Browser service on UDP 1434 which port that instance is using. That is a second service to run and a second port to open, and Browser has a long security history. In a small office it is acceptable inside the LAN. But the fixed-port pattern above removes the dependency entirely — and a dependency removed is a failure mode removed. If you do use Browser, ensure the service is actually started; it installs disabled in many configurations, which is the silent cause of 'works locally, invisible remotely' for named instances.
Everything so far is about your own LAN. Never forward port 1433 (or any SQL port) from your router to the internet. Internet scanners find open SQL Server ports within hours, and brute-force attacks against sa begin immediately — this is one of the oldest, most reliable ways small offices get breached and their databases encrypted for ransom. Staff who need the database from outside should reach it through a VPN or a remote-desktop session into the office, so the database itself stays invisible. This rule has no exceptions for 'just one evening'.
Work the path in order and change one thing at a time: is the SQL Server service running, does SSMS connect on the server itself, is TCP/IP enabled for the instance in Configuration Manager (it can be off), does the firewall rule match the port the instance is actually listening on, and is the client typing the exact server and instance name. Nine offices out of ten find their answer in one of those five checks — usually the third, quietly disabled since install day.
Watch the video to see the server accept its first connection — then use this checklist if your office PCs cannot reach it yet.
▶️ Watch Full VideoNo. When the application and SQL Server live on the same machine, connections stay local and the firewall is not involved. The rule in this guide is only for letting other computers on your network reach the server. Leaving the port closed in that single-machine case is the safer default.
Open SQL Server Configuration Manager, expand SQL Server Network Configuration for your instance, and inspect TCP/IP properties, IPAll section — TCP Dynamic Ports and TCP Port tell you the current state. The SQL Server error log also records the listening port at every startup, in a line like 'Server is listening on [ any
Yes — many third-party security suites replace or sit above Windows Firewall. If the Windows rule is correct and connections still fail, check the antivirus suite's network rules for sqlservr.exe and the port, or test briefly with its network shield paused to confirm it is the blocker. Configure the suite's rule rather than leaving protection off.