Remote Desktop points to a local address. Why not public static address?

Posted on 2012-04-10
Last Modified: 2012-06-08
I just got a new customer but I'm afraid I'm in over my head.

They have a server at office A, and at office B in a different town they are connecting to a Terminal Services session to run medical software. Each office has a CISCO 800 series router, not sure yet of the exact model, but will update.

My problem is that the Remote Desktop Connection at office B shows that it is connecting to the local server address ( and NOT the public static IP address that is provided by the ISP (Optimum online cable).

I'm not that familiar with CISCO routing, and I assume that the router at office B is translating the local 150.1 into the public IP address, but why would it be set up that way (assuming I'm correct)? Why not just have the Remote Desktop Session point to the static Public IP?
Question by:bricar1

Expert Comment

ID: 37830929
The two offices are probably connected by a VPN, so office B computers appear to be a local internal IP.

Accepted Solution

TasticVNT earned 500 total points
ID: 37830953
Hello Bricar1,

I don't feel there is enough information to give you a solid answer, but one thing comes to mind that I think you should check.

Just to clarify, you stated that you have a server at 'Office A,' and a server at 'Office B' in completely different towns.  Obviously, these networks need to communicate with each other, but communicate with each other securely... probably via VPN (Virtual Private Network) utlizing PPTP but most likely L2TP over IPSec due to its superior security advancements.  

You stated that the remote desktop connection at 'Office B' in a different town is connecting to the 'Local Server Address:, not the Public IP address (External IP Address as well).  I'm not sure if the 'Local Server Address' you're referring to is at 'Office B' or 'Office A.'  Based on the context, I'm assuming you meant 'Office B.'

Here's my suggestion:

1) Open up network devices in control panel and check to see if there is a 'VPN Connection' accepting incoming connections... something of that nature.  If there is, the IP it is pointing to may be the VPN utilized to network 'Office A' with 'Office B' which goes on a separate virtual network.

2)  If the Remote Desktop Connection is pointing to a local address, but connecting to a remote/offsite system then the network is most likely already 'OPERATING" to it's own personal VPN.

3)  The Cisco 800 Series Router is a VPN router, so open up the admin page and check the VPN settings.  If it's enabled, it's another strong clue that you're currently utlizing a VPN network and explains why the RDC connection is pointing to a local address.

4) There's a good reason why you don't want to point your RDC to the 'Public IP Address' (Especially in business environments) Security and inconvenience.  The default RDC port is 3389, so if you connect to the Public IP Address, you'll most likely request a RDC connection with the server, not the client machines & Data resources you wish to access.  If you have two remote server networks with several clients, then you would have to change the default RDC listening port from 3389 to something like 3390, 3391, 3392, etc.  In which case, you would connect to the client machine on an offsite/remote network by entering an IP following this syntax: <> or <> etc.  This is inconvenient because you have to go into the registry to change the default RDC listening port on every client machine you wish to access remotely.  More importantly, your connection will most likely not be encrypted if you're not connected via a virtual private tunnel that provides top-notch security from prying eyes.

Furthermore, you'll have to set up port-forwarding via your router/firewall so that when an RDC requests comes in pointing to say: <>, you'll have to forward TCP Port 3392 to: <>.  All in all, this may work alright in home situations, but definitely not ideal under business conditions.

A VPN network will connect to 'unlike' networks, ideally with completely separate subnets to merge as one virtual private network utilizing its own unique networking IP schema.  

So let's say for example the VPN network utilized this network scheme  Client machines on the last octet utlize .1, .2, .3, etc.  You would then be able to access all network resources by working on the same virtual private network.  

I hope this points you in the right direction.


Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

Haven’t we all been there – Mom (or Grandma) needs help on her computer, so calls her IT son (or grandson) for help.  Wouldn’t it be so much easier to just remotely connect to her computer and fix the thing rather than trying to go through it on the…
In this article, I'll explain how to setup a Plex Media Server ( on a Redhat (Centos) 7 based NAS with screenshots to help those looking for assistance.  What is Plex? If you aren't familiar with Plex, it’s a DLNA media serv…
How to install and configure Citrix XenApp 6.5 - Part 1. In this video tutorial we have explained step by step installation of Citrix XenApp 6.5 Server on Windows Server 2008 R2 is explained in this video. We have explained the difference between…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now