DNSless DB connection won't work via VPN anymore 1

[1DMF]

Hi,

I have a DB application which used to work fine and connected to the SQL DB via IP address.

However since our reseller support corrupted our DB they had to create a new instance of SQL and so now in the DNSLess connection I have to include \new on the end of the IP address.

This works fine for those on the internal network, but now all remote users are getting errors...

ODBC -- Connection to 'SQL server192.168.0.1\new' failed.

Why can't the DB see the SQL server anymore for VPN Users?

Thanks,

1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[vbajock]

Addresses that start with 192 are IP addresses assigned to computers that are behind your corporate fire wall. They are private IPs, and are not accessible to anyone on the other side of your corporate firewall. IPs that are accessable via the Internet are public IP's - your VPN has an outward facing IP number that you can probably get by looking at your VPN setup or by contacting your network admin.

What puzzles me is why you are using IP addresses at all. The syntax 192.168.0.1\new is translated as

servername\sqlserverinstance

The servername can either be the actual name of the server or IP address, but it should be the actual name of the sql server computer, your connection string should be using that instead of some internal IP, if you do that, it would be accessible both internally and over the internet via a VPN. Get rid of the IP and substitute the computer name and it should fix your problems.

 

[1DMF]

Well i disagree with you vbajock, using a server name means that NETBIOS needs to always work, and as we know it doesn't.

Using the IP address is the best way to access a specific server without any required translation.

If you type an IP address in a browser it doesn't do an NSLookup to find the domain name, the actual mydomain.com means nothing to TCP/IP , name servers are for the purpose of translating real world words into IP addresses.

In fact doing what you suggest stops the DB from working on the internal network for logged on domain users as well as remote.

I sometimes can't even RDP to the server using the server name, I have to resort to IP address.

when NETBIOS and translation fails, always use IP if possible, ok if your IP changes, it can be a pain, but I have found the AD and domain name / server name translation to be flakey on our SBS 2003 box.

Using the IP has worked for us for 7+ years, so I can't accept that's the problem.

I am also puzzled why you think using the internal IP of the server is wrong for VPN users , the application needs to talk to the server by IP address and by an IP that is understood by the VPN users and by the internal domain users, we certainly wouldn't use our external IP address for internal users.

However, what I have realised in this discussion is the problem could be a conflict between the remote user's internal IP range and our internal IP range.

If his gateway and router is set up for their home network to use the same IP range 192.168.0.x, then the routing is trying to look for the server on his home network instead of checking down the VPN.

hmm, always good to sleep on a problem and discuss it here on TT, thanks vbajock





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[vbajock]

Well, do it any way you want to do it, but the main reason for using the name, is that the IP address could be changed by some network guy, which will make all your apps blow up.

You need to see what IP configuration your remote users obtain once they validate on your system. Make sure whatever IP configuration they receive matches what your SQL server expects.

 

[1DMF]

Yeah, I appreciate about the IP changing ,though it won't, it's a fixed internal IP and as I am the IT department, I won't be changing it anytime soon ;-)

Though my first thoughts on the IP range conflict isn't the problem I wish it was as it would have been easy to fix.

It seems anyone connected via VPN cant see our inhouse SQL server.

Connected internally works and the web apps accessing the SQL server via our dedicated VPN tunnel (router 2 router) also works, just VPN users don't?

Any ideas why this might be happening.

Cheers,
1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[vbajock]

Have you logged in via the VPN and then tried to ping the SQL Server?

If you can ping it, try setting up a DSN manually from a VPN log in, that will invoke a program that sweeps your network when you click the pull down on the "What SQL Server do you want to connect to" pulldown on the first screen. What happens? Does it list the SQL Server in the server list?

You also might want to post this over at the SQL Server forum, this doesn't really sound like an Access problem.

 

[1DMF]

Yes, I can ping the server and telnet to port 1433.

I'll try SQL,

Thanks.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[1DMF]

Finally got it sorted.

It seems if a user is connected via VPN , then 'named pipes' stops working?

I canged the connection string to 'Server IP, Port' from 'Server IP\Instance' and now it works however the user is connected.



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts