[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

RDP dropping out over VPN

Posted on 2010-11-27
31
Medium Priority
?
3,721 Views
Last Modified: 2012-06-27
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
0
Comment
Question by:MCP200
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 14
  • 8
  • 8
  • +1
31 Comments
 
LVL 98

Expert Comment

by:John Hurst
ID: 34222306
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
 
LVL 71

Assisted Solution

by:Qlemo
Qlemo earned 332 total points
ID: 34222307
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
 

Author Comment

by:MCP200
ID: 34222336
Hi,

Thanks for the reply.

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

Thank you.
0
Q2 2017 - Latest Malware & Internet Attacks

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out our latest Quarterly Internet Security Report!

 
LVL 7

Assisted Solution

by:tstritof
tstritof earned 668 total points
ID: 34222560
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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34222573
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34222632
:) 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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34222639
1300 should be safe. Usually it is something not far below 1400.
0
 

Author Comment

by:MCP200
ID: 34223870
Thanks Guys, I'll do some testing today and will let you know!

Many Thanks.

0
 

Author Comment

by:MCP200
ID: 34227233
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34227257
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34227264
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
 

Author Comment

by:MCP200
ID: 34227307
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34227417
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
 

Author Comment

by:MCP200
ID: 34227480
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34227490
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
 

Author Comment

by:MCP200
ID: 34236183
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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34236884
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
 

Author Comment

by:MCP200
ID: 34236921
So we need to use wireshark for this?
0
 
LVL 71

Expert Comment

by:Qlemo
ID: 34236939
Yes, WireShark or MS NetMon, whichever you are more comfortable with.
0
 

Author Comment

by:MCP200
ID: 34274984
I have installed wireshark and ill see what we can find
0
 

Author Comment

by:MCP200
ID: 34277013
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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34277223
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
 

Author Comment

by:MCP200
ID: 34277447
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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34277520
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
 
LVL 7

Expert Comment

by:tstritof
ID: 34277539
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
 

Author Comment

by:MCP200
ID: 34277544
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
 
LVL 71

Expert Comment

by:Qlemo
ID: 34277559
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
 

Author Comment

by:MCP200
ID: 34277808
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
 
LVL 7

Accepted Solution

by:
tstritof earned 668 total points
ID: 34278029
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
 

Author Comment

by:MCP200
ID: 34298694
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
 

Author Closing Comment

by:MCP200
ID: 34332871
Issue has been resolved. This was related to ipsec issue on the hq site.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
A procedure for exporting installed hotfix details of remote computers using powershell
This tutorial will walk an individual through the steps necessary to enable the VMware\Hyper-V licensed feature of Backup Exec 2012. In addition, how to add a VMware server and configure a backup job. The first step is to acquire the necessary licen…
This tutorial will walk an individual through the steps necessary to install and configure the Windows Server Backup Utility. Directly connect an external storage device such as a USB drive, or CD\DVD burner: If the device is a USB drive, ensure i…
Suggested Courses

649 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