File and Printer Sharing + SQL over RRAS VPN, problem with UDP packets

Discussion in 'Server Networking' started by George Valkov, Jun 3, 2010.

  1. 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
     
    George Valkov, Jun 3, 2010
    #1
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.