Connecting client to SQL Server via Cisco VPN

We are having one client PC running Win XP. SQL Server has been set to
Windows Authentication, TCP/IP 1433, Windows 2003 (!).
Via Cisco VPN we are making a connection. IAS has been configurated, so the
local user profile doesn't matter. The server recognizes the user that is
part of the domain that has been defined at the server. So far so good.
When the user tries to connect via any client software (Enterprise Manager,
Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
osql -l -S <hostname> -E
We have used several providers (dail-in, ADSL etc) and some of them works
fine, some not. You would probably say: use the one that works fine, but this
is not satisfying. Some client users are connected to a local network (no
dail in) and do also have the same problem.
The message we got is:
Login failed user '(null)'. Reason: not associated with trusted SQL Server
connection
I have seen at one of the Microsoft pages that we have to set the local
policies correct at the server where the domain has been defined (in case of
Windows 2003). We have done so. No results.
We first thought that it was a problem at the client, but since we have
proved that the same PC can connect to SQL it seems to be a networking
problem. We have also tried Named Pipes as a protocal but we did not succeed.
Since 50% of our clients are not able to connect (this is a world wide
application) we have serious problems. If anyone has any suggestion please
help us.
Thanks in advance
Jeroen
"Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> We are having one client PC running Win XP. SQL Server has been set to
> Windows Authentication, TCP/IP 1433, Windows 2003 (!).
> Via Cisco VPN we are making a connection. IAS has been configurated, so
the
> local user profile doesn't matter. The server recognizes the user that is
> part of the domain that has been defined at the server. So far so good.
> When the user tries to connect via any client software (Enterprise
Manager,
> Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
> osql -l -S <hostname> -E
> We have used several providers (dail-in, ADSL etc) and some of them works
> fine, some not. You would probably say: use the one that works fine, but
this
> is not satisfying. Some client users are connected to a local network (no
> dail in) and do also have the same problem.
> The message we got is:
> Login failed user '(null)'. Reason: not associated with trusted SQL Server
> connection
> I have seen at one of the Microsoft pages that we have to set the local
> policies correct at the server where the domain has been defined (in case
of
> Windows 2003). We have done so. No results.
> We first thought that it was a problem at the client, but since we have
> proved that the same PC can connect to SQL it seems to be a networking
> problem. We have also tried Named Pipes as a protocal but we did not
succeed.
> Since 50% of our clients are not able to connect (this is a world wide
> application) we have serious problems. If anyone has any suggestion please
> help us.
There are a number of areas that these clients could be failing... name
resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
guide will help:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/kb/827422
Steve
|||Thanks Steve,
The article helped us to get better focus on the issue. Instead of 50% of
the clients, almost all of them cannot connect when the try to establish a
connection via their local LAN.
We are almost sure that port 1433 is the problem. Since we got 3 dial in
providers 1 of them doesn't work. We have seen that NETSTAT -an shows us that
1433 is the problem. We have asked the provider and they have confirmed that
they give a random range of ports available.
Now the local LAN's... We have asked them to open port 1433 ingoing and
outgoing. But it still doesn't solve our problem. The VPN connection is
established via port 80 and this goes fine from any local LAN.
Windows authentication is chosen for a single point of entry. Some people do
not recommend this, but it is supported by Microsoft...
We are really lost, maybe someone has other ideas, maybe we can trace
somehow what goes wrong.
Regards,
Jeroen
"Steve Thompson" wrote:

> "Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
> news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> the
> Manager,
> this
> of
> succeed.
> There are a number of areas that these clients could be failing... name
> resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
> guide will help:
> How to troubleshoot connectivity issues in SQL Server 2000
> http://support.microsoft.com/kb/827422
> Steve
>
>