Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a development server with an SQL 2008 EXPRESS instance running on it. The domain is called DEVAD, and the instance is enabled for Shared Memory, Named Pipes and TCP/IP.

My workstation PC is on a different domain called AD.

I have domain trusts set up between AD and DEVAD, and I can connect to the DEVAD instance using my AD credentials, via SSMS or .NET programs.

Unfortunately, the moment I connect to another network via a VPN using credentials for a different domain, I get the following error "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)".

My VPN connection has the option for "Use default gateway on remote network" unchecked for IPv4 and IPv6.

Any ideas as to how to prevent the VPN connection from breaking the trust?

Update: I have an additional VPN that I occasionally connect to, and I don't have issues connecting to SQL at the same time when this one is active.

I did some nslookup tests on the SQL host with various VPNs connected and not connected. My problem VPN ends up with a DNS timeout, which may mean that the DNS on the VPN is misconfigured and slurps up the request, rather than giving a Non-existent domain response (as my other VPN does), and letting the system get on with querying a DNS that does know about it.

share|improve this question
up vote 2 down vote accepted

I was also having this same issue and found the solution here:

You'll need to locate your VPN connections .pbk file.

You can find it here:


Or if you have it set to allow all users to use the connection, you can find it here:


Edit it with a text editor and find the line that says:


Disable it by setting it to 0

share|improve this answer

Did you ever figure this out? I think I know what your problem is.

  1. It's possible that the problematic VPN is a full tunnel, and if so, it could be the case that even unchecking the option for "use default gateway on remote network" won't help. With full tunnel VPN, when you're VPN'd in, ALL of your traffic will be on the VPN network, whether you like it or not. You can test this by going to a site such as before you connect to the VPN, and then refresh the page again after you're connected. If the IP changes, then you're on a full tunnel.
  2. How are you trying to connect to SQL Server? Are you using an application, or SQL Server Management Studio? If you can run the program from a command line, you may have luck using the runas windows command with the /netonly switch. It enables you to be logged into one domain but run a program as a different domain user. Like this:

    runas /user:MYDOMAIN\MYUSER /netonly "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"

Replace the domain, username, and path of SQL Server Manamgent Studio with the appropriate values.

When it asks you for the password, type in the password for the domain user you enetered. It will not authenticate the user at this point. Then when you open SSMS, connect to the DB in question like you normally would, and if it can't connect with your normal creds it should try to use the ones you entered with the runas command.

share|improve this answer
Haven't figured it out. The IPs are the same. Connections to the SQL server are all trusted. Via Management Studio, it's my credentials. But there's also the application(s) on IIS7. Each application pool has it's own user that also uses a trusted connection. – Reuben Mar 1 '13 at 0:29
I assume the app pool users can still connect when you're VPN'd in, it is only you with SQL Server that can't access the DB while VPN'd in? Does running SSMS with /netonly work? – TTT Mar 5 '13 at 19:01
It would appear that the app pool users can still connect when the VPN is active. It does not appear that Ssms for SQL Server 2012 has a /netonly option. ssms -? shows a dialog with -S, -d, -E, -U, -P, -nosplash, etc options. Specifying a username and password in the connection string is a work around, rather than a solution, and I'm after a solution for this one. – Reuben Mar 5 '13 at 23:50
Sorry I wasn't clear about how to use the /netonly switch. It must be used in conjunction with the runas command. I updated my answer with better instructions. – TTT Mar 7 '13 at 0:50
Ok, in that case, the vpn domain is taking precedent for some reason. I don't know if there's a way when you're logged into both to specify the precedent domain. Since you said you setup trusts, can you give your user in the vpn domain permission to sql server the same way your normal user has? That way you wouldn't have to use the runas /netonly command when vpn'd in. – TTT Mar 8 '13 at 14:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.