Julie Lerman's DevLife

DevLife Part I [May 2005 - March 2007]

My Links

Blog Stats

News

A blog for DevSource.com.

This blog was originally part of the blogs.ziffdavis.com site from May 2005 through June 2007 when the blog was moved to the Movable Type blog engine and hosted at blog.devsource.com/devlife.
The original blog was eventually shut down and I was given the posts so that I could host them on my own site.


Archives

VPN and Remote Desktop Conflict on local/server IP Range

Recently, I had to install Cisco's VPN Client program to work on a project that required connecting to a remote server which uses Cisco VPN.

The VPN client is installed on a computer that I access via Remote Desktop from another computer. Both boxes are on my own network.

I'm often using Windows VPN to connect to another client from that computer with no problems. However, with the Cisco VPN, when I connected, my Remote Desktop connection was dropped. This was a bit of a pain, since that meant in order to see that computer, I had to go plug a monitor, keyboard and mouse into it. (This is the system that I once had an octopus of a KVM set up on. I finally gave up on that and have been just RDP-ing into that box.)

Unfortunately I spent all of my time researching this problem focused on the Cisco VPN client.

Another person who was successfuly connecting in a similar manner was using Windows 2003 server for the client and host, so we couldn't compare apples to apples.

Finally, the reason for the problem was discovered by Brian Desmond, an MVP who is something of a boy wonder (in my mind, at least!) when it comes to networking. At 16 (or younger?) Brian was administring a network of 1000+ pcs at his high school. In 2005, Brian won the worldwide Imagine Cup competition in IT. (This is huge.) So, when I see him respond to any admin related questions on a listserv, I can be sure “the crops are saved!”

After sending him some routing info and ipconfig data, the problem was quite obvious to him.

My in-house network range was 192.168.0.xxxx. The server I was connecting to is 192.168.12.xxx.

In the route printout, Brian saw (this is just the last two columns of the listing):

Active Routes:
     Interface     Metric
   192.168.0.7         20
     127.0.0.1          1
   192.168.0.7         20
192.168.12.134          1

The key here is the metric. The computer's internal IP (192.168.0.7) has a metric of 20 while the IP assigned by the remote network has a metric of 1. The 1 was somehow taking precedent over the 20 and kicking it off of the 192.168.0.xx network. (To me it's “somehow“, to a pro, there's a more explicit reason.)

The solution Brian proposed was to change the IP range on my own network. Since he suggested an example of 10.10.10.xx, I went with that.

Problem solved!

posted on Friday, February 16, 2007 5:15 AM