I have two servers located on the DMZ and plugged into the same switch. Both servers are on the same subnet 192.168.0.0/24, and I'm unable to RDP from server 1 to server 2 but can RDP from server 2 to server 1. server 1 can ping server 2 and vice versa. I can RDP from a remote location to server 2 but not from server 1. All windows firewall are turned off. Both servers are on the same vlan 99. I used all my resources. Can anyone helps me ? Did anyone experience this before ? I will appreciate any help to resolve this issue. Thanks.
you might want to check the event logs to see if there isn't something application based going on...
I'm assuming because of icmp working that both arp tables are good, but you might want to check. (windows arp -a linux arp)
Can server 1 RDP to any other location?
There is a utility I posted called SLPing, which allows you to ping on TCP and UDP ports to find out if there is a connection via the ports.
Are there any other connections made to server 2 when attempting with server 1?
Would it be possible to try VNC just to rule out RDP being the issue?
server 1 can RDP to any other locations.If any other connections made to server 2 when attempting with server 1 I don't know. Unfortunately, VNC is prohibited to be used in our network. Thanks.
This is unusual.
Server 1 can RDP to other locations.
Server 2 can RDP to Server 1.
Server 1 can NOT RDP to Server 2.
ICMP works both directions.
Do you have a sniffer you can put on the network to capture the traffic? I think the only way to really know what is happening is to see the stream. This will tell you if a connection made or connection is refused.
You can use something like Ethereal, it is free.
ha...ok that blows that theory out of the water.
I was hoping it was something that easy. Along with the sniff, can you do a traceroute from server 1 to server 2?
You may want to check server 2 for any persistent routes to 192.168.0.0/24 on it.
Also, since you are using subnet zero, check if your servers both support subnet zero.
Next, ensure subnetmasks are set correct. Then check arp tables on router ans servers, and check the mac address table on the switch.
You may also want to check if there are any teaming settings for interfaces on the server causing this issue.
Can't think of anything else.
What IP adresses are the relevant adresses for the servers in question?
The cap file basically shows two host communication with RDP (x.y.z.68 and x.y.z.65), and another host (x.y.z.250) trying to find the MAC (ARP request) for x.y.z.12
Seems you have an ARP issue if host x.y.z.12 is the server having problems.
x.y.z.68 is the one trying to RDP to x.y.z.65 and it is failing. I believe the connection is getting established then dropped. The funny thing is x.y.z.68 can RDP to other servers on the same subnet and other servers on the same subnet can RDP to x.y.z.65 and vice versa. x.y.z.250 is the ip address of the gateway and x.y.z.12 is the DNS server.We even tried to connect to x.y.z.65 using the hostname and we got the same result. I have no more clues.
Okay, the capture only shows two sessions, both initiated from x.y.z.65
The first session is a short one, second is a longer one. I do not see any session initiation from x.y.z.68 (no syn packet from this source ip)
It seems it does not even try to connect in that case, unless your caputure is filtering something out.
This file shows one session initiated from x.y.z.68 to x.y.z.65
Filtering this out you can easily see what happens. It establishes the connection, then some packets are exchanged after which x.y.z.65 sends a tcp reset.
This means that for some reason the server rejects the connection by sending a tcp reset.
You will need to look into why x.y.z.65 sends the tcp reset. It does that for a reason.
The most likely cause I can think of in this case is that x.y.z.68 is an older client (using lower encryption) and x.y.z.65 is a higher version, and not configured for "client compatible" encryption level. That could explain why other servers work and this one does not.
Changing the encryption level is performed within the Terminal Services Configuration utility, located under All Programs, Administrative Tools. Open the Properties dialog box of the Microsoft RDP 5.2 protocol type in the Connections folder and click the General tab. This reveals the Encryption level box, which can be changed between high and client compatible.
Both servers .68 and .65 encryption level are set to "client compatible". I appreciate your help. I have no more clues. If you think of anything else, please let me know. By the way this problem started after I upgraded the code to a crypto to support SSH on the switch connecting both servers. Thanks.
I don't see any reason why upgrading the swtch would be relevant to this issue, but if it did start right after you upgraded the switch you might be hitting a bug (in that case, check the bug toolkit and if you can not find anything, open a TAC case).
My feeling though tells me it as nothing to do with upgrading the switch. Typically, such upgrades happen during maintenance windows and it might be that something changed on the x.y.z.65 server as well.
Check the event logs on the server and debug rdp on that server (you might need to check microsoft knowledgebase for the how to, if at all possible). I suspect the server just drops the connection it for whatever reason.
If you think the issue might be related to the switch upgrade, you could simply downgrade the switch to the previous image to rule out any bugs in the ssh image.
Good luck troubleshooting and let us know when you found the solution.
I backed out my code version 12.2(37)SE Image C3560-IPBASEK9-M and everything works fine. Server 1 can RDP to server 2. Server 1 can map drive to server 2. At this time, I'm running a non crypto software on my 3560-G connecting both servers.
Thanks all for your input and ideas. It is great to have this forum.