VPN clients cause SMB problems on RRA server

[Guest]

I have recently setup Routing and Remote Access on a W2K3 server to support
several VPN clients. For the most part connections and access from the
client’s side work fine. However, the W2k3 server that is running RRA is
unable to make SMB connections to localnet resources only after a VPN client
has been connected for a short period of time. Here is the scenario

Windows 2003 server running RRA (Server)
Internal NIC: 192.168.1.10
Internet NIC: 207.189.x.x (public static address)

Internal Backup File Server: 192.168.1.121 (Backup)

VPN Client Range: 192.168.1.200-249 (Client)

Nightly backups copy .BKFs to the backup, so the server needs to make SMB
connections to the backup. Approximately 1-5 minutes after the client has
connected to the server, the server can no longer make SMB connections to the
backup machine. The client (connected via VPN) can, however, make SMB
connections to the backup, through the server, which is unable to make these
connections on its own. The VPN client can also make SMB connection to the
server, and visa versa. It is just that the server can not make SMB
connections to internal machines (SMB on 192.168.1.0/24, excluding VPN range
192.168.1.200-249).

Although I can not really prove this, but my belief is that these symptoms
occur after a VPN client makes SMB calls to other network resources (anything
on the 192.168.1.0/24 network).

I have tried moving the VPN clients over to a different subnet
(192.168.2.0/24) but it only created a longer delay before the symptoms
became apparent.

After the problem occurs, I can run a port scan on the backup
(192.168.1.121) from the server, and all ports reply open. So it is not that
the server’s packets can not traverse the network to the backup machine. I
can also ftp into the backup from the server while the SMB connections are
not working.

Disconnecting all clients does not repair the problem. The only way to make
localnet SMB connections available again to the server is by restarting the
RRA service.

My guess is that the server -- once a VPN client establishes an SMB
connection -- tries to send all SMB traffic over the VPN link (usually
auto-assigned to 192.168.1.200), from which point the server will not be able
to locate the backup (192.168.1.121).

So I guess my question is: Is there a way to (force) prioritize devices for
SMB traffic so that the 192.168.1.10 is always the default for SMB traffic?
That is assuming this is my problem.

I’ve tried moving the 192.168.1.10 device to the top in:
HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkStation\Linkage\Route
But each time RRA is restarted, the virtual (auto) VPN link (usually
192.168.1.200) device ID resets my values. On top of that, it has not solved
anything, even temporarily (although it may if I restart services?).

Any suggestions or tips are very appreciated at this point. Thanks!

-Kyle

 

[Robert L [MS-MVP]]

is the server alos DC or DNS? quoted from http://www.ChicagoTech.net
Connection issues on DC, ISA, DNS and WINS server as VPN server

Symptom: You have a Windows 2000/2003 server is configured as VPN running DNS, WINS, you may experience some connection issues. 1) the internal computers can't ping the server by name; 2) if the server is a DC and Master Browser, you may have a computer browsing issue; 3) you may receive Event ID: 4319 - A duplicate name has been detected on the tcp network; 4) You may receive error messages like "No Logon Servers Available to Service your Logon Request" when you try to open file shares or map network drives to the Routing and Remote Access server; 5) if the server is also a DC, you may not be able to logon the domain; 6) if the server is also running ISA, you cannot browse the Web from client computers on the local network, regardless of whether the computers are configured to use Web Proxy or the Microsoft Firewall Client. For example, "The page cannot be displayed" may appear in the Web browser with a "cannot find server or DNS" error message.

Cause: When a VPN client connects to the VPN server, the server creates a PPP adapter to communicate with the remote computer. The server may then register the IP address of this PPP adapter in the DNS or the WINS database. When the internal computers try to connect to the IP address of the PPP adapter, them cannot reach the PPP adapter, then the connections fail.

Don't send e-mail or reply to me except you need consulting services. Posting on MS newsgroup will benefit all readers and you may get more help.

Bob Lin, MS-MVP, MCSE & CNE
How to Setup Windows, Network, Remote Access on http://www.HowToNetworking.com
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
This posting is provided "AS IS" with no warranties.
I recommend Brinkster for web hosting!

I have recently setup Routing and Remote Access on a W2K3 server to support
several VPN clients. For the most part connections and access from the
client’s side work fine. However, the W2k3 server that is running RRA is
unable to make SMB connections to localnet resources only after a VPN client
has been connected for a short period of time. Here is the scenario

Windows 2003 server running RRA (Server)
Internal NIC: 192.168.1.10
Internet NIC: 207.189.x.x (public static address)

Internal Backup File Server: 192.168.1.121 (Backup)

VPN Client Range: 192.168.1.200-249 (Client)

Nightly backups copy .BKFs to the backup, so the server needs to make SMB
connections to the backup. Approximately 1-5 minutes after the client has
connected to the server, the server can no longer make SMB connections to the
backup machine. The client (connected via VPN) can, however, make SMB
connections to the backup, through the server, which is unable to make these
connections on its own. The VPN client can also make SMB connection to the
server, and visa versa. It is just that the server can not make SMB
connections to internal machines (SMB on 192.168.1.0/24, excluding VPN range
192.168.1.200-249).

Although I can not really prove this, but my belief is that these symptoms
occur after a VPN client makes SMB calls to other network resources (anything
on the 192.168.1.0/24 network).

I have tried moving the VPN clients over to a different subnet
(192.168.2.0/24) but it only created a longer delay before the symptoms
became apparent.

After the problem occurs, I can run a port scan on the backup
(192.168.1.121) from the server, and all ports reply open. So it is not that
the server’s packets can not traverse the network to the backup machine. I
can also ftp into the backup from the server while the SMB connections are
not working.

Disconnecting all clients does not repair the problem. The only way to make
localnet SMB connections available again to the server is by restarting the
RRA service.

My guess is that the server -- once a VPN client establishes an SMB
connection -- tries to send all SMB traffic over the VPN link (usually
auto-assigned to 192.168.1.200), from which point the server will not be able
to locate the backup (192.168.1.121).

So I guess my question is: Is there a way to (force) prioritize devices for
SMB traffic so that the 192.168.1.10 is always the default for SMB traffic?
That is assuming this is my problem.

I’ve tried moving the 192.168.1.10 device to the top in:
HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkStation\Linkage\Route
But each time RRA is restarted, the virtual (auto) VPN link (usually
192.168.1.200) device ID resets my values. On top of that, it has not solved
anything, even temporarily (although it may if I restart services?).

Any suggestions or tips are very appreciated at this point. Thanks!

-Kyle