SQL Over VPN: Direct Client or an Internal Workstation?

Teams want SSMS on their laptops, and the quick fix is to publish the SQL port to the VPN pool. The slower answer asks where the client process should run, because direct access and an internal workstation produce different source addresses, endpoint trust and data paths. Neither is automatically safe, and VPN membership alone decides nothing. Compare the designs before an allow rule exists.

Two paths, two source addresses

With direct access the laptop carries the client configuration and opens the database connection itself. With a remote workstation the laptop opens a desktop session, and the workstation makes the SQL connection from its own address. The database therefore sees the VPN pool or a translated gateway in the first design, and the workstation's address in the second. That difference decides which firewall rule and which SQL permission actually apply.

The laptop still controls the remote session, so a workstation is not a substitute for user authentication or session policy.

Check what the database actually sees

The source address is something to measure rather than infer from a diagram. Read it from the server side of a live connection.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

The connectivity test proves the listener accepts TCP from that network, while the query proves which login and database the session reached. To see the address the server recorded, query sys.dm_exec_connections for the current session, which returns the client address after any translation. If that value is a gateway rather than the laptop, a per-user host rule cannot work on the database machine. Write the observed value beside the chosen design, because reconnects and pool changes move it.

Open the listener and nothing extra

Open only the service the deployment needs. The familiar 1433 is the default instance's port rather than a universal constant.

Get-NetTCPConnection -State Listen -LocalPort 1433

Named instances often listen on a dynamic port, with SQL Server Browser answering discovery on UDP 1434, and that dependency is a separate exposure to justify. Pinning a fixed port for the instance removes the need for Browser and makes firewall rules stable. Keep the encryption and certificate checks the client already performs instead of disabling them to make a test pass. Then grant database roles for the workload rather than adding the whole VPN group to a server role.

Prove the allowed path and the denied one

Open a fresh session as an ordinary approved user, and confirm the server identity, the database and the operation required. Then confirm the exclusion: a source or account outside the policy must fail the same test. For the workstation design, verify the laptop cannot bypass the boundary by reaching the database directly. For direct access, verify the route and source rule still hold after a reconnect.

Record where the client ran, which source the database observed and which rule allowed it. That is the evidence the next review will ask for.