Hi every one! I'm having trouble with clients trying to access File and
Printer Sharing + SQL over a RRAS VPN to a Win 2000 domain controller. RRAS,
File Sharing and SQL running on that server.
On the domain network at the company, some users relay on a 3-rd party
application to access the SQL database. Some of the users also want to have
access from their homes.
First the user has to establish the VPN - this step works properly.
Than he or she has to open \\server\app using Windows Explorer and login
with their domain account, choosing to save the password, so that the
downloader application can always access that path in the feature to
download or update the client application.
Unfortunately the name resolution only works some times and this seems a
real pain to fix.
The network traffic analyser show this:
[CLIENT-IP] to [255.255.255.255] NBNS Name query NB SERVER<00>
[SERVER-VPN-IP] to [CLIENT-IP] NBNS Name query response NB [SERVER-LAN-IP]
Both client and server are using UDP 137 to UDP 137.
For some reason the client cannot always resolve the server and retries that
a few times, failing in the end after a long delay. I see the query and the
response packets on the client and there's no firewall, but still it doesn't
resolve the server most of the times.
I managed to improve that a little by adding the server VPN IP and the
clients to the LAN IP segment 192.168.0.0/24:
server LAN IP=192.168.0.1
server VPN IP=192.168.0.2
RRAS policy restricts access from clients to access 192.168.0.1 and
192.168.0.2 and broadcast. Routing is enabled so I can ping or TCP to both
of server's IP addresses.
Now:
[192.168.0.5] to [255.255.255.255] NBNS Name query NB SERVER<00>
[192.168.0.2] to [192.168.0.5] NBNS Name query response NB [192.168.0.1]
and in the most cases the client resolves the server properly.
Then the client runs a downloader application that connects to the server
(File and Printer Sharing) and installs or updates the main application, and
executes it. As we are already logged on to File Sharing, this step works
properly.
For TCP it doesn't matter which address we connect to: 192.168.0.1 or
192.168.0.2, the server will replay from it and a TCP connection is
established.
Now comes the odd part:
The client application needs to determine the TCP port of the SQL server and
send a UDP message asking about the SQL database to SERVER:UDP1434.
For some reason the server always replays to UDP packets from it's VPN-IP
address, but indicates it's LAN-IP address in NBNS responses: NB
[192.168.0.1].
Because of that the client may use either 192.168.0.1 or 192.168.0.2.
Sometimes it chooses one, and sometimes the other.
This is what I get:
[192.168.0.5] to [255.255.255.255] NBNS Name query NB SERVER<00>
[192.168.0.2] to [192.168.0.5] NBNS Name query response NB [192.168.0.1]
[192.168.0.5:UDP 1707] to [192.168.0.2:UDP 1434] ... data base name;
[192.168.0.2:UDP 1434] to [192.168.0.5:UDP 1707] ...
tcp;1258;np;\\SERVER\pipe\MSSQL$data base name\sql\query;
this works properly, but if we try to use 192.168.0.1:
[192.168.0.5] to [255.255.255.255] NBNS Name query NB SERVER<00>
[192.168.0.2] to [192.168.0.5] NBNS Name query response NB [192.168.0.1]
[192.168.0.5:UDP 1707] to [192.168.0.1:UDP 1434] ... data base name;
[192.168.0.2:UDP 1434] to [192.168.0.5:UDP 1707] ...
tcp;1258;np;\\SERVER\pipe\MSSQL$data base name\sql\query;
Notice the replay still comes from 192.168.0.2. If there's no firewall on
the client or if it's set to accept all UDP traffic coming from that
address, for some reason the UDP message is accepted (although it shouldn't
be) and the client application connects successfully to the SQL server on
TCP 1258. But if the firewall drops that packet as it does not come from the
address that we requested - and it's not supposed to be accepted anyway!,
the client application will resend the query several times and fail after a
long delay.
I tried using the hosts and lmhosts files to set a static mapping for
server's IP.
If I use the LAN-IP:
192.168.0.1 SERVER
then File Sharing connects much faster and always works, but the UDP
response from 192.168.0.2:UDP 1434 may get blocked by client's firewall and
the application cannot determine server's TCP port.
If I use the VPN-IP:
192.168.0.2 SERVER
then the UDP response from 192.168.0.2:UDP 1434 is accepted, so the client
knows where to find the SQL server. Unfortunately there are long delays in
File Sharing and in Windows Explorer I'm getting errors like:
The specified path cannot be found; or The specified network name cannot be
found. So I cannot login to download the client application.
I made some tests using Windows 2003 RRAS VPN, which also suffers from the
same problem: when a VPN client sends a UDP packet to server's LAN-IP, the
replay comes from the VPN-IP of the server and get's rejected.
And while widows clients accept UDP responses from the wrong IP address
(which is a security risk), I made a test with my iPhone, which sends back
ICMP destination unreachable.
Can any anyone please help me with a solution for that problem?
I need to make the server replay properly to UDP messages.
George Valkov
|
Similar Threads
Linear Mode
