Weird RDP issue
bearokopoulos
Member Posts: 2 ■□□□□□□□□□
in Off-Topic
OK here goes...
We have 4 clinics in 4 different locations, that connect to each other with RDP sessions.
Clinic 1:
Can connect to clinics 2, 3, and 4
Clinic 2:
Can connect to clinics 1, 3, and 4
Clinic 3:
Can connect to clinics 1 and 2, but not 4
Clinic 4:
Can connect to clinics 1 and 2, but not 3
We've replaced routers and modems, no avail. RDP is working in all directions except to/from clinics 3 and 4, but they can each connect to/from clinics 1 and 2. Attempting to connect to either clinic 3 or 4 using Active Directory User Names from locations other than clinics 1, 2, 3, and 4 works correctly.
Long story short, 2 clinics can connect to every other, 2 clinics can connect to every other except each other. Therefore:
RDP set correctly, otherwise wouldn't be able to connect to/from any clinics.
Router ports correct, otherwise no connections would be possible.
User names correct since we can connect to clinics 3 and 4 from locations other than 3 and 4 using the Active Directory User accounts. Therefore not a group or rights issue. Unable to connect between clinics 3 and 4 using any user names, but user names work from other locations correctly.
Unable to VNC between clinics 3 and 4, but VNC works correctly to/from other clinics.
Unable to ping static IP between clinics 3 and 4, but can ping successfully to/from other clinics.
Any ideas?
We have 4 clinics in 4 different locations, that connect to each other with RDP sessions.
Clinic 1:
Can connect to clinics 2, 3, and 4
Clinic 2:
Can connect to clinics 1, 3, and 4
Clinic 3:
Can connect to clinics 1 and 2, but not 4
Clinic 4:
Can connect to clinics 1 and 2, but not 3
We've replaced routers and modems, no avail. RDP is working in all directions except to/from clinics 3 and 4, but they can each connect to/from clinics 1 and 2. Attempting to connect to either clinic 3 or 4 using Active Directory User Names from locations other than clinics 1, 2, 3, and 4 works correctly.
Long story short, 2 clinics can connect to every other, 2 clinics can connect to every other except each other. Therefore:
RDP set correctly, otherwise wouldn't be able to connect to/from any clinics.
Router ports correct, otherwise no connections would be possible.
User names correct since we can connect to clinics 3 and 4 from locations other than 3 and 4 using the Active Directory User accounts. Therefore not a group or rights issue. Unable to connect between clinics 3 and 4 using any user names, but user names work from other locations correctly.
Unable to VNC between clinics 3 and 4, but VNC works correctly to/from other clinics.
Unable to ping static IP between clinics 3 and 4, but can ping successfully to/from other clinics.
Any ideas?
Give me Liberty or give me...Well, just give me Liberty and be done with it.
Comments
-
bearokopoulos Member Posts: 2 ■□□□□□□□□□BTW all 4 clinics servers running Server 2003 Enterprise SP1. Running qwinsta shows correct port listing.Give me Liberty or give me...Well, just give me Liberty and be done with it.
-
snadam Member Posts: 2,234 ■■■■□□□□□□bearokopoulos wrote:
Long story short, 2 clinics can connect to every other, 2 clinics can connect to every other except each other. Therefore:
RDP set correctly, otherwise wouldn't be able to connect to/from any clinics.
Router ports correct, otherwise no connections would be possible.
User names correct since we can connect to clinics 3 and 4 from locations other than 3 and 4 using the Active Directory User accounts. Therefore not a group or rights issue. Unable to connect between clinics 3 and 4 using any user names, but user names work from other locations correctly.
Unable to VNC between clinics 3 and 4, but VNC works correctly to/from other clinics.
Unable to ping static IP between clinics 3 and 4, but can ping successfully to/from other clinics.
Any ideas?
since you cant even ping them, try connecting to the servers via RDP using thier IP address instead of computer name just for fun. Then check DNS and make sure all the records are good firstly on their local cache, and then make sure the A and PTR records are correct in the forward and reverse lookup zones in DNS on whichever server 3 and 4 use to resolve names. Try that out and let us know the results.
You can also throw a packet sniffer on and see where these packets are being dropped too, but that might be too much too soon for this issue.**** ARE FOR CHUMPS! Don't be a chump! Validate your material with certguard.com search engine
:study: Current 2015 Goals: JNCIP-SEC JNCIS-ENT CCNA-Security -
darkerosxx Banned Posts: 1,343Also, turn on firewall logging and check your firewalls for dropped packets from the clinics.
-
dynamik Banned Posts: 12,312 ■■■■■■■■■□Isn't this what tracert is for
Run trace route and see where your pings are failing. I'd start there. -
blargoe Member Posts: 4,174 ■■■■■■■■■□Routing.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
Rikku Member Posts: 82 ■■□□□□□□□□I would also try pathping next to tracert and see what shows up in the statistics.
try a C:\>pathping -n destination address (-n to avoid name resolution useage and just get the results...if you suspect DNS/naming issues)
more descrip: http://www.windowsnetworking.com/articles_tutorials/Using-Pathping.html
-Rikku -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Okay....You're not connected with RDP, it's just a protocol you are trying to run over the connection it may sound pedantic but it's a misconception you can't afford when troubleshooting, its not an RDP issue it's a connectivity problem.. So what does connect your sites - Leased lines/Managed WAN Service/Your own VPNs between your routers? Is it meshed or hub and spoke? I'm presuming that it's meshed VPNs, check your configs to make sure the VPNs are being formed between 3 and 4 in the first place (your endpoint devices should be able to tell you this) and also that your routing is correct for those subnets. As has been suggested tracert is your friend, pathping is a good tool but better for including packet loss in the results than troubleshooting base connectivity imho.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?