Solved: Can’t Remote Desktop to a Newly Joined SBS 2008 Domain Computer Over a VPN

The Problem:

I added a Windows XP SP2 machine to a SBS 2008 domain via the Connect Computer application and could no longer use Remote Desktop to access it from across a VPN connection.

The Solution:

Make sure your VPN connection is assigning you an IP address on the local subnet. After a computer is joined to a SBS 2008 domain, it appears that the default remote desktop exception restricts access to the local subnet only. Some VPN connections can assign a remote computer a remote IP address or retain that remote PC’s native LAN IP address.

For example, I use SonicWALL’s Global VPN client. In its current configuration it presents remote PCs to the office network with the IP address that the remote PCs have on their native network. For example, my home network is 192.168.11.x while the office is 192.168.168.x. When I use a packet sniffer on the office network, all traffic coming from my computer is seen as coming from rather than a 192.168.168.x address provisioned via the office’s DHCP server. This is fine under default workgroup conditions but does not work using SBS 2008’s default Group Policy. When I connected via a PPTP VPN using one of the office servers as the endpoint (via RRAS), I could successfully RDP into the machine in question because the PPTP VPN provisions a local IP address for the tunnel adapter.

You must either find a way of assigning a local IP to your VPN connections or edit the group policy to allow the scope of the remote desktop connection to include the remote subnet or “Any computer (including those on the internet)”.

The Long Story:

I had a Windows XP SP2 workgroup machine that I join to my new Small Business Server domain. Immediately afterward, I could not access the machine via remote desktop from my workstation that is located across a VPN connection. I attempted to access the PC using both a local account and a domain account. I double checked to make sure that my account settings in the RDP connection were accurate. Still no luck.

The error that I received from my remote desktop management application (mRemote) was “RDP Disconnected! Error Code: 516 Error Description: WinSock socket connect failed”. Remote desktop was still enabled on the troublesome computer. I could remote into the machine from a computer on the LAN (in other words, I RDP into a computer on the LAN and then RDP from that computer into the computer in question). That seems to suggest some kind of routing issue.

I went to Network Connections (run >> ncpa.cpl) and looked at the properties of the LAN’s NIC. On the Advanced tab, I clicked “Settings” for the firewall, clicked the Advanced tab on the “Windows Firewall” properties box, selected the LAN NIC within the “Network Connection Settings” grouping and clicked “Settings”. From there, on the Settings tab, I put a check next to “Remote Desktop”. I could then connect to the PC via remote desktop across the VPN. The question that remained in my head was: why did this setting need to be selected even though there was an exception for remote desktop in the Exceptions tab of Windows Firewall?

The answer lies here: those options mentioned previously are there to select “which services running on your network that Internet users can access” (to quote the dialog box). That set my mind to wondering. I recall that some months back I noticed my SonicWALL VPN client didn’t give me a local address on the office network. I went back to the Windows firewall Settings dialog box and looked at the Exceptions tab. If you create a new exception or edit an existing one, there is the option to change the scope of the exception. By default, all exceptions are listed as “My network (subnet) only” and not “Any computer (including those on the internet). Aha!

It turns out that my SonicWALL GVC was showing my work computer to the office LAN using my work IP address and not an office IP address. All computers that I connected to saw it as being on a different subnet and thus sent it to their default gateway which happens to be the very SonicWALL device that is the VPN endpoint which took care of the routing. However, the default Windows Firewall settings when a computer is joing to a SBS domain is to refuse RDP connections from PCs that are not on the local subnet. Several obvious solutions to the problem present themselves immediately. Those are mention in “The Short Story” section.

Leave a Reply

Follow TheNubbyAdmin!

follow us in feedly

Raw RSS Feed:

Contact Me!

Want to hire me as a consultant? Have a job you think I might be interested in? Drop me a line:

Contact Me!

Subscribe via Email

Your email address is handled by Google FeedBurner and never spammed!

The Nubby Archives

Circle Me on Google+!

Photos from Flickr

Me on StackExchange

The IT Crowd Strava Group

%d bloggers like this: