Solved

RDP dropping out over VPN

Posted on 2010-11-27
31
3,119 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
  • 14
  • 8
  • 8
  • +1
31 Comments
 
LVL 90

Expert Comment

by:John Hurst
Comment Utility
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 68

Assisted Solution

by:Qlemo
Qlemo earned 83 total points
Comment Utility
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
Comment Utility
Hi,

Thanks for the reply.

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

Thank you.
0
 
LVL 7

Assisted Solution

by:tstritof
tstritof earned 167 total points
Comment Utility
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 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
:) 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 68

Expert Comment

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

Author Comment

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

Many Thanks.

0
 

Author Comment

by:MCP200
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

 

Author Comment

by:MCP200
Comment Utility
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 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
So we need to use wireshark for this?
0
 
LVL 68

Expert Comment

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

Author Comment

by:MCP200
Comment Utility
I have installed wireshark and ill see what we can find
0
 

Author Comment

by:MCP200
Comment Utility
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 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
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 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
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
Comment Utility
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 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
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 167 total points
Comment Utility
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
Comment Utility
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
Comment Utility
Issue has been resolved. This was related to ipsec issue on the hq site.
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Secure VPN Connection terminated locally by the Client.  Reason 442: Failed to enable Virtual Adapter. If you receive this error on Windows 8 or Windows 8.1 while trying to connect with the Cisco VPN Client then the solution is a simple registry f…
The recent Microsoft changes on update philosophy for Windows pre-10 and their impact on existing WSUS implementations.
This tutorial will show how to push an installation of Backup Exec to an additional server in both 2012 and 2014 versions of the software. Click on the Backup Exec button in the upper left corner. From here, select Installation and Licensing, then I…
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…

744 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

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now