TOUGH ONE: ODBC connection over VPN tunnel on 2 seperate domains!

Hey guys - this is going to be a tough one i'm pretty sure :p

Here's the situation - we have two different sites - each with a different windows domain.  We have a SQL server on domain 1.  Then on domain 2, there is a computer that's not a member of either domain (it's just in a workgroup).  There is a VPN tunnel connecting the two sites together.  DNS doesn't work across the VPN tunnel, but i have edited the hosts file on the computer, and so i can ping the SQL server (across the VPN tunnel) by both hostname or by IP address.

I've tried setting up an ODBC connection to the SQL server using both IP address, hostname, the works.  I get the error that the SQL server doesn't exist, or access denied.  i've tried both TCP/IP, and Named Pipes, but neither work.

SQL server is running SQL 2005 standard, with all patches and updates.

CLIFF-NOTES VERSION:  VPN tunnel between two sites, and 2 domains.  One workstation (not on either domain) trying to connect to SQL server on domain across tunnel to set up ODBC.  it can ping the server, RDP to it, but can't set up ODBC connection.
Who is Participating?
Mystical_IceConnect With a Mentor Author Commented:
I could never get this to work in the end, so ended up just connecting to a computer on the remote end via terminal services.  Figured pulling SQL data over a (slow) VPN connection wasn't best practice anyway
Is your SQL server set up to allow connections frmo that IP address?  Is the client able to supply the credentials that the SQL server needs when it is not part of a domain?
How quickly do you get the SQL Server does not exist or Access is Denied?

If it's quick, it's Access Denied.  
If it takes several seconds, it's SQL Server does not exist (or cannot be contacted).

Try using telnet to access SQL Server on the port it is listening on (1433 by default for single instance machines).

Verify via tracert that the traffic is in fact going over your VPN link.


Have your VPN administrator verify that port 1433 is open over the VPN link.
Mystical_IceAuthor Commented:
Thanks for the answers - to answer your questions:

it takes a few seconds, so I figured it couldn't contact it, and wasn't a permission denied issue.  Also the SQL logs show that there are no requests or access denieds, so nothing was even getting to the SQL box.

I had tried accessing the SQL machine's sql port - 1433 - and wasn't able to, BUT THEN i just tried to telnet to the default port from a machine on its same domain, subnet, etc. and wasn't able to.  That's when i researched and figured out (as you mentioned) that NAMED instances (this is a named SQL instance) use a random port.  I researched a bit and found out how to find what port it was.  They said to dig through registry keys to find it, but i had a better idea - go to command prompt and type "netstat", to see which ports are open on the server.  I found out - port 2612.  Tried telnetting to it from another computer and it worked.

I am the VPN administrator, and all ports are open over the VPN link =P

I'm not at the client having the problem at the moment (and have no access to it right now), but tomorrow morning i will be, so will try it then.  Should work if i select "TCP/IP', and then pick the port in ODBC, right?
You don't want to specify the port unless you set a static part (even if it's not 1433).  If you are using dynamic ports, it can (and likely will) change with each service start.  Just because it's a named instance, doesn't mean it HAS to be a dynamic port.  Typically when you install a named instance, it's because the default instance is already installed.  You can always enable a static port.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.