0

We maintain a Windows 2003 Terminal Server for one of our remote offices to connect to to get all their work done. Every morning, when they try to connect, they get an error that the server is unavailable. From our ouwn internal network, we are able to log into that server using RDP just fine. After rebooting the server, the remote office is able to connect once more. It would seem to me (maybe incorrectly though) that given the symptoms the problem isnt with the network (which doesnt change after a reboot) or with all the licenses used up (we are able to log in.) But I have no idea what the problem could be. Any ideas in troubleshooting this will be greatly appreciated.

Additional Information: (5/1/2012)

First, I want to thank everyone who has had suggestions so far. They have been great. So I tested a few things and these were the results: When the connectivity is lost from the outside subnet, I logged into the server locally and attempted to access the subnet. It failed saying "No Network Path Provider was available." Then I did a quick Google search in the browser and after calling up the Google page I was once more able to see the blocked subnet.

We have used the Windows ARP command to check that the MAC addresses of the NIC cards on the server match the ARP cache, and likewise we have checked the Cisco ASA 5500 Router's ARP cache for incorrect entries.

Peter Lange
  • 107
  • 10
  • Are the working internal systems on the same subnet as the server? – Shane Madden Apr 12 '12 at 15:41
  • Hi Shane. Yes they are on the same subnet. – Peter Lange Apr 12 '12 at 16:01
  • Next time it happens, check outbound connectivity from the server (through the console or RDP from one of the local systems) - I bet it won't be able to access anything outside the subnet. – Shane Madden Apr 12 '12 at 16:20
  • Ok, good advice I will try that. – Peter Lange Apr 12 '12 at 16:26
  • Or, alternately, it will both be able to communicate *and* restore remote RDP connectivity. I'm betting some kind of ARP issue between the server and the subnet's gateway - what kind of device is it? – Shane Madden Apr 12 '12 at 16:28
  • Their office (and its subnet) connects to ours through a point to point vpn tunnel. What is ARP? I am not familiar with that, but I can look up some stuff? – Peter Lange Apr 12 '12 at 17:25
  • The (potential) concern, then, would be in the device handling your side of the VPN tunnel. ARP is the protocol that handles resolving an IP address (layer 3) to a machine's ethernet MAC address (layer 2) so that IP packets can be addressed to the right ethernet device. It depends on broadcast traffic between the devices, sometimes connectivity problems there will cause one device to be unable to see the other on the same broadcast domain. – Shane Madden Apr 12 '12 at 17:32
  • Maybe this will be helpful somehow; http://serverfault.com/questions/78505/rdp-connectivity-to-windows-server-2003-servers-intermittently-lost-after-date-c – Vitali Tikaev Apr 12 '12 at 18:09
  • Is this a virtualized server? – SpacemanSpiff May 03 '12 at 00:08
  • No its a physical server. – Peter Lange May 03 '12 at 00:14
  • Also my support/network guy had a webex today with Cisco and they confirmed all the settings (though I am too cynical to put too much weight in that.) – Peter Lange May 03 '12 at 00:16
  • 2
    It would help if we could see a diagram of the network topology that shows how the server, ASA 5500, and any other devices sitting between your site and the remote subnet are connected to each other. That said, LAN-to-LAN IPsec VPN tunnels on Cisco devices are brought up "on demand", meaning the ASA will only try to bring a tunnel up if it sees a packet that it thinks needs to cross that tunnel. I've seen cases where a tunnel will only come up when triggered from one end, which may be what's going on here. – James Sneeringer May 03 '12 at 02:18
  • Its a pretty simple topology. The computer is connected to an HP Proliant switch (dont recall the model # off hand) which is in turn connected to the Cisco ASA Router. I dont think it is the switch because the local subnet would be connecting to it through there as well, but I am open to the argument none the less if there is a good theory behind it. – Peter Lange May 03 '12 at 07:26
  • So the lost of connectivity is not limited to RDP but applies to all network services, right? Is it in DMZ or available both from ouside and inside directly? – yrk May 04 '12 at 14:31

2 Answers2

0

Try performing a series of tracert commands from your local subnet and from the remote subnet during the day. See if the route changes, or can't be resolved.

Garrett
  • 1,638
  • 4
  • 15
  • 25
0

It turns out that the problem was with the multiple NIC cards on the server. Each NIC was for a different subnet. For some reason, the server would eventually get confused and stop responding to RDP requests on the NIC unless I first logged into the server and made an outbound request. Once I disabled the other NIC, it was golden.

Peter Lange
  • 107
  • 10