Connecting via VPN

Your machine and the customer's are not in the same domain so Windows
authentication won't work because there's no way to authenticate the user on
your machine. SQL Auth should work unless there's something else blocking
the TCP/IP connection. It might help to know what error you're getting and
if there is an error in the server error log. Running EM remotely is
actually the best solution in this case.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OitGvBWlGHA.4772@.TK2MSFTNGP04.phx.gbl...
> One my company's customers has allowed me to connect to their network via
> VPN. Overall, it seems to work fine. I can remote in, or map drives, etc.
> However, I have been unable to use my SQL2000 Enterprise manager to
> connect to their database. I can remote into the machine where that
> database resides and open up EM there, but I can't do it from EM on my
> machine. That is, I'm getting a 'logon failed' error, regardless of
> whether or not I am using Windows or SQL authentication.
> I did some digging, and found that ports 1433 and 1434 need to be open for
> this to happen. However, the customer has stated that he isn't blocking
> off these ports.
> Anyone know of any issues with doing this over VPN?
>One my company's customers has allowed me to connect to their network via
VPN. Overall, it seems to work fine. I can remote in, or map drives, etc.
However, I have been unable to use my SQL2000 Enterprise manager to connect
to their database. I can remote into the machine where that database resides
and open up EM there, but I can't do it from EM on my machine. That is, I'm
getting a 'logon failed' error, regardless of whether or not I am using
Windows or SQL authentication.
I did some digging, and found that ports 1433 and 1434 need to be open for
this to happen. However, the customer has stated that he isn't blocking off
these ports.
Anyone know of any issues with doing this over VPN?|||Your machine and the customer's are not in the same domain so Windows
authentication won't work because there's no way to authenticate the user on
your machine. SQL Auth should work unless there's something else blocking
the TCP/IP connection. It might help to know what error you're getting and
if there is an error in the server error log. Running EM remotely is
actually the best solution in this case.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OitGvBWlGHA.4772@.TK2MSFTNGP04.phx.gbl...
> One my company's customers has allowed me to connect to their network via
> VPN. Overall, it seems to work fine. I can remote in, or map drives, etc.
> However, I have been unable to use my SQL2000 Enterprise manager to
> connect to their database. I can remote into the machine where that
> database resides and open up EM there, but I can't do it from EM on my
> machine. That is, I'm getting a 'logon failed' error, regardless of
> whether or not I am using Windows or SQL authentication.
> I did some digging, and found that ports 1433 and 1434 need to be open for
> this to happen. However, the customer has stated that he isn't blocking
> off these ports.
> Anyone know of any issues with doing this over VPN?
>|||[vbcol=seagreen]
And your local firewall (if any)?
Try to connect with telnet on port 1433 and/or osql or sqlcmd with the
"tcp:"-prefix.
More infor here
http://blogs.msdn.com/sql_protocols.../22/483684.aspx
And the remote connection is not always the best solution - perhaps the
local machine is a development-station for test and debugging - porting
changes is a whole lot easier with local access...
/ola|||[vbcol=seagreen]
And your local firewall (if any)?
Try to connect with telnet on port 1433 and/or osql or sqlcmd with the
"tcp:"-prefix.
More infor here
http://blogs.msdn.com/sql_protocols.../22/483684.aspx
And the remote connection is not always the best solution - perhaps the
local machine is a development-station for test and debugging - porting
changes is a whole lot easier with local access...
/ola