[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 810
  • Last Modified:

Use Remote Desktop between Domains

Please see the attachment, in Short: I am the network admin for Domain A, which is the Forest root for Domain A and Domain B. The domains are located in separate states connected by a MPLS Link. We have VPN setup on a Cisco ASA 5510 located at Domain A. We have setup users from Domain B to be able to connect to the VPN, which they successfully can; although, when they try to use Remote Desktop to connect to their PCs at Domain B the session fails to located their PCs. PCs located at Domain A can be successfully remoted into with no problem. Is this an issue with VPN, DNS/WINS, Remote Desktop, or something else I am missing?
RemoteDesktop.xls
0
tlowe2
Asked:
tlowe2
1 Solution
 
nappy_dCommented:
Are they connecting via the IP or the FQDN of the workstation?

Do you have a server on Domain A that you can try and connect to via RDP and does it work?
0
 
McNeticCommented:
I think the issue can have multiple reasons, but my first guess is that the sites (A and B) use different IP subnets. The VPN concentrator has to push a route for the subnet of site B to the client. If it does not (you can check this on the home users computer with the 'route print' command, the home users computers has not idea where to send packets to said subnet.
0
 
tlowe2Author Commented:
We have tried both, IP address; computer1.domainb.com.
Yes, if the user first remotes in to a PC on Domain A, then they can remotes in to a PC on Domain B. But you can see were that is not desirable, we don't want Domain B employees remoteing in to a Domain A PC just to get to a PC on Domain B. If possible they need to be able to access PCs on Domain B, from the VPN Connection.
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
tlowe2Author Commented:
Thanks McNetic...and yes they are on different subnets. Is there a way I can configure the VPN, in the ASA, to allow for the traffic to be routed?
0
 
McNeticCommented:
Unfortunately, I don't know about configuration of the Cisco ASA, but I'm quite sure that it is possible to configure this, as this is not an uncommon setup.

It should also be possible to manually configure the route in the client computer after the connection is set up by executing a 'route add <subnet ip> mask <subnet mask> <gateway ip>', where subnet ip and subnet mask are the addresses of the subnet of site B and gateway ip is the ip address the client computer got assigned by the vpn device.
0
 
tlowe2Author Commented:
Thanks again McNetic...for some reason the route add isn't working either. When I add in the route, it doesn't show up in the route print. I think maybe I need to look at this from the VPN config point of view. Even if the route add works, that means it needs to be done manually on each client PC, each time they connect to the VPN...and trying to talk a user through that each time would be a nightmare.
0
 
mgpremkumarCommented:
You would need to look at at the following details:

1. Route print from a home users machine after connecting to the VPN
2. Route print from the ASA after the VPN is established
3. Route print from the machine on domain B to which the user is trying to connect

The routes should be such that the home user can reach the machine in domain B and the machine in domain B should also know how to get back to the home users machine.

If you can update the attached file with the ip address and route print would be easier.

The route adds need not be done manually. If you are using a Microsoft DHCP to assingn IP address to the client machine then you can use the scope option 249 (classless static route) to push static routes to the vpn client machines.

Alternatively you can also use active directory to configure static routes on a per user basis. refer: http://technet.microsoft.com/en-us/library/cc728159.aspx
0
 
McNeticCommented:
That's not completely true for all setups.

Item 1) mentioned above:
Usually, the Cisco ASA will be assigning IP addresses and also static routes to the VPN clients. This can be configured in the admin interface, and this is what you will have to do for the network of site B.

2) The cisco ASA will also automatically set up correct routes for the local network to reach the VPN clients. This already works correctly, as the local network of site A and the VPN clients can communicate without problems.

3) If networking and routing is set up correctly in site B (which appears to be the case, as site A and B can also communicate without problems), there are two cases to discern:
a) Site B does not have any other connection to other networks aside from the link to site A - in this case, the default route for site B will point to the link to site A, and all traffic to the VPN clients will automatically be routed correctly
b) Site B does have connections to other networks (probably its own internet connection). Then there are also two scenarios:
b1) The additional connections of site B run over the same router as the link to site A - in this case, its sufficient to add a route to the VPN clients network on that device.
b2) The additional connections of site B run over other routers - in this case, the easiest way would be to assign static routes to the VPN clients network to all computers in site B, and this can be done via DHCP as pointed out by the previous poster.
0
 
tlowe2Author Commented:
Updated File with route prints for the VPN Client and destination client on Domain B...
Copy-of-RemoteDesktop-1-.xls
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now