VPN Connects but SQL Server Rejects Windows Authentication
VPN login works, SQL Server rejects Windows authentication: compare the tunnel account with the client's token, then read auth_scheme on the server.
Tunnels come up, servers answer ping, and the database login still fails with an authentication error. That combination is common on VPN links and it rarely means the network is broken, because a reachable listener and an accepted login are different results. The identity that satisfied the gateway is not necessarily the identity the database client offers. Working out which account arrived is the whole task.
The symptom: reachable server, rejected login
A timeout tells you the packet never reached a listener. An authentication error tells you the listener answered and refused the credential. Those two messages send you to different teams, and mixing them wastes a day on firewall rules that were never the problem.
When the error is a login failure, stop looking at ports. The remaining question is which Windows identity the client presented, whether the server accepted that identity, and whether it resolved to a database user with permission.
Two identities, one tunnel
The VPN account authenticates to the gateway and, in most deployments, ends there. The database client separately presents a Windows token, taken from the process that runs it, or a SQL login if the connection string asks for one. A gateway-local VPN user has no relationship to the domain that hosts SQL Server, and the tunnel does not create one.
Connecting a personal machine to a VPN does not join it to the domain either. Renaming a local account and matching its password to a domain user is not an enrollment procedure, and it produces a token the domain controller will not accept as that user.
Some native Windows remote-access clients can reuse the VPN credential for network resources when their profile is configured that way. That behaviour belongs to a specific client and profile, not to VPN connections in general, so verify it for the client in use rather than assuming it.
Read the mode the client asked for
The connection string decides which authentication path the client takes. Integrated security uses the Windows token; a user and password pair selects a SQL login. Those are separate modes in the server configuration, and only one of them can be enabled for a given connection attempt.
Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;Switching to a SQL login because the Windows login failed is a workaround that hides the identity question, and it usually needs a new login and password to be created anyway. If the deployment requires Windows authentication, keep the mode and fix the identity path. A SQL login also needs its own permissions, so the workaround buys a second account to maintain.
Also confirm which application is connecting. A service running as a system account, a scheduled task and an interactive query window can present three different tokens on the same machine, and only the last one matches what the user sees when they run whoami.
Ask the server what it actually saw
The server can tell you which login it resolved and how the connection authenticated. Run the query inside the session being investigated, because an administrator's separate successful connection proves nothing about the failing client.
SELECT ORIGINAL_LOGIN() AS original_login,
SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;The first row distinguishes the login that opened the session from the security context in force right now, which differ under impersonation. The second names the authentication scheme, so KERBEROS, NTLM and SQL become visible facts instead of guesses. A connection that reports NTLM where you expected Kerberos is a name-resolution or SPN problem, not a password problem.
The error number narrows it further. State 5 usually means the login name was not resolved at all, state 8 usually means the password did not match, and state 11 means the credential was accepted but access to the server failed. Ask the administrator for the state rather than the whole message, since the message alone is deliberately vague.
| What you observe | What it suggests |
|---|---|
| Timeout, no listener | Route, firewall or wrong port |
| Login failed, state 5 | Name not resolved in the domain |
| Login failed, state 11 | Authenticated but no server access |
| Connected as NTLM | Target name or SPN mismatch |
When the identity arrives and Kerberos still fails
If the server sees the intended Windows identity and integrated authentication still fails, the exchange itself is the problem. Kerberos needs the service principal name registered for the SQL service account and a client that requests the service by a name matching it. Connecting by IP address cannot match a name-based SPN, and an alias can match only if it is registered too. Check the name the client typed before anything else, because a connection that works by hostname and fails by IP describes exactly this problem.
Ask the administrator to review the registered identity and the service account rather than creating duplicate SPNs by trial and error. Duplicate registrations produce intermittent failures that are harder to diagnose than the original problem.
After authentication works, the login still needs a database user and permissions. A successful VPN login, a successful Windows login and permission to read a particular table are three separate results, and each one deserves its own check before the ticket is closed.