SQL Server Named Instance Over VPN: Discovery, Not Port 1433

Most people treat a SQL Server hostname as a complete address, and a VPN as either allowed or not. In practice a named instance makes the client perform a second lookup after DNS, and that lookup is the part a tunnel most often breaks. An explicit endpoint sidesteps it, which is why tcp:host,port can work while host\INSTANCE times out. The distinction is between finding the service and being allowed to use it.

The myth: one hostname means one port

The hostname resolves to an address, and that is where its job ends. A named instance adds an instance name that the server has to translate into a TCP port, and the client cannot guess it. Port 1433 is the default for a default instance, not a property of every instance on the machine. Treating the two as the same thing produces the classic symptom: ping works, DNS works, the scan of 1433 shows nothing, and the conclusion is that the network blocks SQL.

A second assumption fails in the same way: that opening TCP 1433 is enough. If the instance listens elsewhere, an open 1433 proves only that something else is there. The port has to match the listener, and the listener is a server-side configuration detail you should ask for rather than infer.

What the client actually does with a named instance

After resolving the host, the client sends a discovery request to SQL Server Browser on UDP 1434 and asks which port the named instance uses. The browser service answers from the server's own registry, and the client then opens a TCP connection to that port. Two protocols and two ports are involved before a login is even attempted.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

That is why a UDP-only block produces a timeout that looks like a dead host. If the browser service is stopped or disabled, the discovery request goes unanswered even though the database engine is running and its TCP port is open. If the instance is configured with a static port, the client still asks unless it was given the endpoint directly. Each of those failures looks identical in the application's error message, and they need different fixes.

The browser service is a discovery convenience, not the database. Stopping it does not stop the engine, and starting it does not open the instance's TCP port.

Why the explicit endpoint works when the name does not

An explicit endpoint removes the lookup from the sequence: the client connects straight to the address and port you named. That is a diagnostic first, not automatically a permanent fix, because the port can change if the instance is later reconfigured to a dynamic one. Compare the two forms with the same client and the same account before drawing conclusions.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

If the explicit form succeeds and the named form fails, discovery is the gap, and you can choose how to close it: allow UDP 1434 through the tunnel, or have the administrator pin a static port and document the endpoint. Both are deliberate decisions with different maintenance costs. Opening every port in the range is neither of them, and it is the option that tends to be proposed at the end of a long day. Record the choice where the connection strings live.

If neither form works, the problem sits upstream of discovery. Check the listener, the route and the access rule for the port the instance actually uses before blaming the browser service.

After discovery: authentication and identity are separate

A login failure is a different event from a timeout, and the VPN identity does not become a SQL login by virtue of the tunnel. Once the client reaches the right port, the database engine applies its own authentication and permissions. Mixing the two stages in one ticket is how a discovery problem gets assigned to the wrong team. Read the error number before you change anything.

Keep the documented hostname if the driver validates the server certificate, because connecting by numeric address can change that check instead of fixing the original problem. Recent Microsoft drivers encrypt by default, so a name mismatch surfaces as a certificate error after a successful TCP connection. That is progress rather than a new failure.

The myth to retire is that a SQL Server hostname is a complete address. It is a host plus, for a named instance, a lookup that the tunnel may not carry. Name the port, name the discovery path, and the next failure will tell you which layer to fix.