I've had the following problem for quite some time now, and finally resolved. At first blush, it seems like a simple enough issue to resolve, but in my particular case, it wasn't.
Basically what happened is that I have an instance of SQL (Express) installed on my primary development machine that is used as part of design, development, and building of the various applications I'm working on. I also have need to connect to a particular customer network via VPN (Aventail/SonicWALL). Everything was working fine until a few months ago when the customer updated the VPN client (from 9? to 10), at which point I was no longer able to access my SQL instance through trusted connection.
For example, if connected to the VPN and attempting a command line query, I'd see the following:
C:\>osql -S localhost\sqlexpress -q -E
Login failed for user ''. The user is not associated with a trusted SQL Server
connection.
In checking the event log, I'd see the following error:
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: nnn.nnn.nnn.nnn]
If I disconnected the VPN, the above works as expected (no error).
?
My first conclusion was that the new VPN client was tunnelling ALL traffic through the appliance, and local requests back to my machine, and therefore SQL was considering the request as 'remote' and denying it. I tweaked the necessary SQL properties to allow remote connections -- nada.
After spending a lot of time trying to diagnose, I temporarily gave up and just resolved that I'd either be able to do VPN work or SQL work, but not both simultaneously.
Not satisfied with that 'solution', I resolved to spend more time on it. I'll leave out the countless things that I did try and didn't work and mention what I did find that actually solved the problem for me -- hopefully it will help someone else:
I started looking at the SQL configuration a little more closely (Start Menu\Programs\Microsoft SQL Server 2005\Configuration Tools\SQL Server Configuration Manager) and noticed some differences from some of the other typical SQL installations I have floating around. Specifically:
Under SQL Server 2005 Network Configuration: all protocols were enabled.
Under Aliases, there were several aliases using the tcp protocol.
I reset the above to coincide with what appears to be the default configuration:
SQL Server 2005 Network Configuration
Shared Memory - Enabled
Named Pipes - Disabled
TCP/IP - Disabled
VIA - Disabled
Deleted all SQL Native Client Configuration Aliases.
After that, my VPN/SQL issues were resolved! I'm not exactly sure what was the cause (protocol or alias), but a little more post-fix experimentation leads me to believe tha that the aliases were the problem. How that relates to the updated VPN client, or if it was purely coincidental, I don't know, but it is fixed and I'm satisfied!
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment