RDP dropping out over VPN

Hi There,

I need some advise on Remote Desktop dropping out.

I'm having issue with my Remote Desktop dropping out after few minutes of connecting.
This issue is occuring over VPN and i have no issue over LAN  .

Once the rdp connects it then can drop out at any time.The issue has never occured in the past and recently started to happen . No changes were made on the router/firewall

I'm running windows server 2003 64 bit and VPN is setup on cisco 2621 series


Thanks
MCP200Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
tstritofConnect With a Mentor Commented:
Well, 10.10.60.90 is an address taking part in your communication and it seems you have multiple NICs configured with it.

Whose address is 10.10.60.90? Client or server? If client - how do you assign IP adresses to VPN clients? DHCP? Fixed range? However - if this were client address I'd believe that it would cause problems when connecting to other servers too. Could it be that you have disbanded the NIC team on your server and left them with same IP address?

And regarding the troubleshooting, please try to stick with the original problem setup as much as possible. That way you'll be able to eliminate problems one by one. E.g. after you eliminate the MTU issue in one setup, moving to another server would require you to eliminate it there too, before proceeding.

I'm having a bit of trouble following the testing environment now, also I've lost track of whether RDP still works on LAN and only causes problems through VPN.

Regards,
Tomislav
0
 
JohnBusiness Consultant (Owner)Commented:
What kind of VPN?  I had to raise the timeout in one of the phases of a new IPsec installation for RDP to keep up its connection, but that was all. ... Thinkpads_User
0
 
QlemoConnect With a Mentor Batchelor, Developer and EE Topic AdvisorCommented:
Are you using the Cisco VPN client?
Anyway, it sounds like a timeout issue. Is your VPN stopping, too, or only RDP? If latter, I assume the Cisco is idling out the session in error though there is still traffic.
Debugging on the Cisco might reveal what is happening. But don't ask - I do not know Cisco well enough to be of any help with the config or commands, though I know there is a debug command.
0
Building an Effective Phishing Protection Program

Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.

 
MCP200Author Commented:
Hi,

Thanks for the reply.

Im using cisco 2861 and it's setup as a vpn server.

Thank you.
0
 
tstritofConnect With a Mentor Commented:
Hi,

you've said that no changes whatsoever were made to your VPN router, and that it's been working fine before. Were there any other changes on your network? Perhaps your terminal server?

Are you experiencing the problem on all RD clients or only on specific machines (what OS)?

One possibility (although I haven't hit that one in a while) is that you are having problems with MTU settings on your RD client or your terminal server. Since you say that the issue only occurs through VPN and not through LAN I suspect one side in the communication is sending a packet that when encrypted by VPN becomes larger than the MTU size of your router (maybe the server side, but i suspect the client side router since Cisco should be able to handle this, possibly even split the packets). If one side in communication doesn't allow packets to be fragmented the communication dies.

To set maximum MTU size for VPN connections in XP and W2K3 server follow the instructions here.

In order to find the correct setting establish the VPN connection and then try pinging terminal server from the client:

ping <tsname> -f -l <packet size>

You can start with packet size of 1500 and decrease it until you get proper ping response. After you determine the precise packet size that pings correctly you can use that number increased by 28 (ICMP header) as maximum MTU (or that exact number if I'm wrong about ICMP header size).

Regards,
Tomislav

0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
There is a better means to measure MTU: download mturoute from http://www.elifulkerson.com/projects/mturoute.php, and use
  mturoute -t «TS-IP»
  mturoute -t «VPN-Gateway public IP»
That should show both the unencrypted and encrypted packet MTU.
0
 
tstritofCommented:
:) Nice tool, basically automates the manual ping procedure.

One more thought though. The settings for MTU size determined this way are basically different things on your client side and on your server side.

Your client is establishing connection with Cisco VPN and is aware that it should use the proper VPN setting for MTU. However, your terminal server treats the the traffic coming from Cisco router as normal LAN traffic and isn't aware it needs to drop the MTU size. That means you may be required to decrease the MTU size for all TCP/IP communication on the network interface of your terminal server that receives the RDP traffic from router.

To do this you will have to modify the following registry key on W2K3 server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<network interface>

by adding a new DWORD value to that key named MTU set to the MTU size you determined before. The value which works for my terminal servers is 1300 (decimal) however it may be different in your case depending on routers and type of VPN encryption.

Regards,
Tomislav
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
1300 should be safe. Usually it is something not far below 1400.
0
 
MCP200Author Commented:
Thanks Guys, I'll do some testing today and will let you know!

Many Thanks.

0
 
MCP200Author Commented:
After some further investigation

I found out that RDP is dropping out only to this server. Quiet strange.
I have tried to telnet t to this server on port 3389 and there is no issue.
Also i ran extended pings while RDP to the server and there's is no packet loss.
No issue to other servers on same subnet.

I have ACL applied inbound to allow RDP so i don't belive the firewall is causing the issue.
I don't want to rebuild this server as yet

Any other ideas ? please



0
 
tstritofCommented:
Hi,

just to confirm:

1) You still only have problems when connected through VPN and on LAN no problems.

2) You have tested the ping from the client computer while it is connected to VPN and which gets the RDP connection dropped at random times soon after it successfully establishes it.

3) When you ping your TS from that client while connected through VPN with this command

ping <servername> -f -l 1500

you get normal "Reply..." answers not "Packet needs to be fragmented...".

Regards,
Tomislav
0
 
tstritofCommented:
One more thing.

What did you mean by "only to this server"? Are you by any chance accessing a load balanced TS server farm?

Regards,
Tomislav
0
 
MCP200Author Commented:
Hi Tomislav , Thanks for the reply.

Well  i;m accessing this server from another remote location via RDP.
The server that i'm having issue with with has only one NIC, Previously this server had 2 NICS with load balancing enabaled now that's no longer the case.

I can rdp to domain controller  on the same vlan from location with no issue. Note that this server has two nics and are not teamed.

Thank you


0
 
tstritofCommented:
Are you using VPN connection before establishing RDP or not?

Sorry if my question on load balancing wasn't clear - I was reffering to the situation where you have multiple terminal servers set up as load balanced server farm - I guess this is not your situation.

What I'd like to know is with what packet size can you ping TS server address with from the location you are connecting from? You should ping the TS address directly from command line of the client before establishing RDP connection.

I hope I'm clear about my instructions. For examply my home ISPs router allows only packets up to 1300 bytes to pass through without fragmentation. It seems strange to me that you can pass the 1500 byte unfragmented packet to your TS remotely and get a normal ping reply.

Also, there are differences between OS versions of servers in this regard - I've only experienced this problem with W2K3 terminal servers.

Please confirm the maximum ping size passing to TS remotely and then try modifying the registry settings for NIC MTU on TS (or you may just set it to 1300 without testing - it should allow for any situation).

Regards,
Tomislav
0
 
MCP200Author Commented:
Hi Tomislav ,The two sites are connected via site to site IPSEC VPN . I have now set the  MTU to 1300 on the server that i'm having issue with. Note i have rebuild the tcp/ip stack on this server.

This week we will be uprading the link between the to sites to SHDSL but i'm treating this fault separate as i don't have any issues with other remote servers. Below are some of the tests i've done.

####################################################
ping 10.10.30.4 -f -l 1300 -t

Ping statistics for 10.10.30.4:
    Packets: Sent = 302, Received = 301, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 61ms, Maximum = 263ms, Average = 71ms
Control-C

Tracing route to MNACSRVAPP01 [10.10.30.4]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.10.60.1
  2    33 ms    33 ms    30 ms  172.16.113.1
  3    29 ms    30 ms    30 ms  MNACSRVAPP01 [10.10.30.4]

Trace complete.
####################################################
0
 
tstritofCommented:
The ping looks fine.

I'm not 100% sure how rebuilding tcp/ip stack affects the changed MTU settings so I would check the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<network interface> key for your NIC once more and restart the server just to be sure (although that may be completely unnecessary after rebuilding the tcp/ip stack).

Report if the RDP issue persists.

Regards,
Tomislav
0
 
MCP200Author Commented:
Hi,

issue is still occurring with rdp. I installed vnc on the server and it's working.

So it's not a nic issue or bandwidth issue, whatever the issue is  it has something to do with remote destop
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
The only way to find out that is to capture related traffic on both client and server ...

RDP is different from the VNC protocol: RDP transmits commands (like "draw rectangle from .. to ..."), while VNC transfers differences of screen snapshots. Thus packet size is different, rate of packets sent is, and many more. Might be very well that VNC works better than RDP here.
0
 
MCP200Author Commented:
So we need to use wireshark for this?
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Yes, WireShark or MS NetMon, whichever you are more comfortable with.
0
 
MCP200Author Commented:
I have installed wireshark and ill see what we can find
0
 
MCP200Author Commented:
I have captured some data from Wireshark from source ip 10.10.60.90 to 10.10.30.4 and it shows  Header checksum: 0x0000 [incorrect, should be 0x3098]

See the attached file
RDP.txt
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
You can ignore that. Modern NIC drivers use checksum offload, so the correct checksum is inserted and checked by the network card chip itself; WireShark cannot see that checksum for outgoing packets.
0
 
MCP200Author Commented:
Man I'm running out of ideas
I rebuild the router configuration for the remote site this afternoon and the same issue. I'll be  doing the same for tomorrow for the hq site. It can't be a link issue as it's after hours.

0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Sorry being not of much help here, but you need to capture RDP traffic while it is "dropping". And you need to do that on at least two locations ...
0
 
tstritofCommented:
Hi,

Qlemo's mentioning of NIC checksum offload gave me an idea. If you have Broadcom NIC on your failing server, you should try disabling any offloading features on the NIC and see how it goes (IPv4 Large Send Offload and Receive Side Scaling to start with - there may be others too depending on NIC version).

These are known to cause issues for both RDP and Citrix.

Regards,
Tomislav
0
 
MCP200Author Commented:
What's the best way of filtering the traffic on wireshark?Yea I'll do that tomorrow. I was running wireshark when rdp was dropping.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Good idea about switching CRC offload off, and worth a try. The same is valid for some other NIC brands and/or particular driver releases.

Regarding capturing, there are two approachs: Capture-all and Capture-Nothing. Capturing all traffic, excluding anything really uninteresting, will reveal ARP and broadcast issues, in addition to ICMP Redirects or route broadcasts, but generate a lot of captured contents. Since we are interested in the headers only, capturing only say 64 data should be enough.
The other approach is to capture nothing but the interesting traffic. That is more difficult, as you need to know exactly what traffic might be interesting. E.g. capturing RDP only will not show ICMP messages from routers (e.g. MTU wrong).
0
 
MCP200Author Commented:
Hi Tomislav I have Broadcom NICs on the server since they are  all DELL servers. I have now disabled (IPv4 Large Send Offload and Receive Side Scaling  and checksum offload and rebooted the server. Still experience the same issue.

I ran wireshark and it showed some warning with a sourcr server that has duplicate ip. I'll have to tracr this one, this could be one of the source of the problem causing communication issue between 10.10.60.90 and 10.10.30.4 . I ran the rdp session from different server though.

When i try to filter by destination ip address the capture won't show live data . Maybe im doing something wrong ?







Wireshark.png
rdp-new.docx
0
 
MCP200Author Commented:
Hi Tomislav,

The issue occurs only over VPN.

From LAN no issues connecting to these server directly BUT if i rdp from a  server at HQ to a server at branch site the RDP drops out.

I think it's sometthing to do with tIPSEC tunnel between the two sites.

0
 
MCP200Author Commented:
Issue has been resolved. This was related to ipsec issue on the hq site.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.