We are having alot of trouble maintaining our connection to Remote Desktop server that my husband and I use for work. We both get kicked off the server multiple times per day - I'm talking 20-30 times - whenever we are connected to the server. This started happening to us when we upgraded our service to Gen5 with the HT2000W modem/router combo unit. I googled the issue and tried all the "fixes" recommended (which for me as a nontechie is a pretty good acheivement) but NOTHING has worked. I have spoken with the IT person that controls the server connection and he basically went through all the fixes I had already tried from the info I found online. The owner of the company I work for says its my network card that is causing the issue not the server. Since the problem started when we upgraded our service to Gen5 it has to be the HT2000W modem/router since nothing else has changed.
The error we are getting every time we get kicked off the server is "Because of a error in data encryption, this session must end. Please try connecting to the remote computer again."
We are using Remote Desktop Connection to access Windows Servier 2007R2 Standard.
PLEASE HELP! Any insight would be appreciated!
I have tried all recommendations posted on this feed - nothing has really helped. Was on the phone again today for another hour with tech support. They re-registered my modem/router but it has not changed anything. I can handle the slow speeds but the data encrytion error will not allow me to stay connected to remote desktop connection long enough to work. Especially for both me and my husband. It has gotten so bad lately only 1 of us can work and the 1 of us that is working is still having trouble with the error. We are having to work from a hotel room for this weekend since both of us work 13 hour shifts sat and sun. I just dont understand why it has gotten so bad lately. I hate being that person to complain. I hope HughesNet finds a resolution soon but unfortunately we will have to switch until that happens. Gen5 was great until this. 😞
I had started another thread for an issue I'm experiencing for work as well that only started after upgrading to Gen5. Gen4 worked pretty much flawlessly. My issue is with Skype for Business and my specific error is this:
About a minute into the viewing you got disconnect with the below error:
ms-client-diagnostics: 52164; reason="Appsharing session disconnected due to RDP stack closed the connection"
Microsoft have told me from the logs they can tell it is not my client that initiated the disconnection, meaning it was either the ISP or the Skype for Business online server. In my case I will be trying to perform a test while in town to isolate the issue - ISP or Skype for Business Online related. But as I said this problem started after moving to Gen5.
Curious if you have made any progress at all on your issue. I totally empathize with you. This past month plus since upgrading to Gen5 has been the most difficult in my past 20+ years in IT. I quite literally cannot get my job done the way things are working now. Trying to remain optimistic that the issue can be pinpointed and addressed.
I would be curious to know if this is a result of the way HughesNet is making the modems DHCP at strange (and short) intervals. Can you see (begin tracking) if your modem is getting a new ipv6 prefix each time your connection is dropped? Sometimes my modem is keeping the assigned prefix for days, and other times it's changing several times in an hour (without losing connection). The change in your ipv6 prefix would temporarily disrupt any kind of streaming connection.
On a typical ISP, when the modem DHCP's the "Dynamically assigned IP" is set to that modem for days, not hours/minutes.
Unlikely that is the cause as that was the behavior of IPv4/6 on the HT1100 units and RDP worked fine there.
My bad... I started with gen5.
What I have been seeing via an external monitor is that when my modem receives a new ipv6 prefix, that prefix is sometimes not immediately routable. There seems to be a delay between my modem receiving the prefix, and hughesnet knowing where to route that prefix. Sometimes this delay is > 1 minute.
No biggie, just thought I would throw that out there...
Really the HT2000w is a fancier and beefier version of the HT1100, and ES-19 is very similar to ES-17 in design from what I understand. That's why I can't figure out why the issue hasn't been resolved... The two are actually very similar, just ES-19 can handle far more customers overall. Which leads me to believe there may be something about the modem/router software of the modem that's having issues, since the 1100 didn't have a built in router.
@tracerrx I'm also noticing the connectivity blip when a new IPv6 prefix is assigned to the customer equipment. Not sure if that has anything to do with these RDP issues, though.
Just got off the phone with an engineer, they are investigating this, so once I have any updates to share, I'll post back.
Your patience and understanding are much appreciated.
Thanks I'll pass this along!
Curious you mention IPv6... I have IPv6 on my unit disabled, as well as disabled in my network, which means unless they are doing some form of IPv4/IPv6 tunneling at the modem side, this shouldn't affect me if your theory is sound, correct?
@C0RR0SIVE I dont think so... It appears that the carrier grade NAT they are using (which is basicaly invisible to you) is utilizing ipv6... I belive when you disable it, you are only disabling ipv6 DHCP6 features on local LAN. Not at home right now but can def check later
I think that only shows if you have WAS enabled... When I do lookups, WAS OFF, it shows IPv4 only, but WAS ON it will show an IPv6 addy.
@C0RR0SIVE once again it's a Carrier Grade NAT... you may not be able to see the actual IP transversal method they are using behid the scenes. Regardless of ipv4/6, there appears to be a "lag" of up to a minute in registering DHCP assignments within thier own network (which is easily verified by looking at the ipv6 prefix assignments sice they are public). So for example, you have x.x.x.1 and can ping x.x.x.1 publically, but then your modem gets y.y.y.1 and you cannot ping y.y.y.1 immediately (it takes about a minute in some cases to register on thier own network even though you already have it).
So if you have a remote desktop connection active when that happens, it's dropping because somewhere in the NAT it doesnt know how to get back to the modem thats assigned y.y.y.1
So, where, and how exactly are you determining your leases and the such?
First this applies to residential customers... The business customers prob function via the same NAT, but they have static IPv4's so it's irelevant. Second, Read this description of dual stack NAT's. Even with ipv6 disabled, your ipv4 is most likely being transported over an ipv6 NAT while inside the hughesnet network.
Im going to explain this in IPv6 terms, since thats all we can test. But rest assured they are nating ipv4 over ipv6 internally as well. While residential customers get public adressable IPv6/59's they are dynamic (which is not how ipv6 is supposed to work by the way). If you notice your modem also gets a local and public ipv6 (seperate from your assigned ipv6 prefix which are not pingable). Once assigned, you can ping the public ipv6/59 externally and all is good. What @pswired and I have discovered is that the assigned ipv6/59 prefix CHANGES OFTEN. Anywhere from 1-20 times a day (Which is the most often i have ever seen from any isp)! Most of the time when it changes, it's no big deal.
However, sometimes when it changes it takes minutes to become active (resgistered as belonging to your modem) on the hughesnet network even though it's already been assigned to a customer device. This is simple to test by performing a traceroute back to the assigned prefix, and you can watch it "die" at the hughesnet datacenter, even though it's active on your device. This tells us that there is sometimes a significant lag in assigning a prefix, and that prefix being registered as "in use" on the hughesnet backbone (Likely the result of just a bad card or single router out of ha sync). When this happens, and you have an open connection, that connection cannot make it back to your modem since this newly assigned ipv6/59 prefix has no route back to your modem.
@pswired and I have both setup vm/router/raspberry pi to use with a DynamicDNS service so we can have remote access, and discovered this by accident. I understand that with sattelite were looking at much higer latency, but worst case it should only take a couple of seconds to register an assigned ip, not minutes. I belive it's this significant lag that is causes the RDP disconnects. If the users could report/monitor thier assigned ipv6/59 prefix before and after the disconnect we may be able to correlate the events.
Does that make sense?
Here is a snippet from a log file showing when my assigned ipv6/59 changes.. You can see that sometimes its very stable, othertimes is changes every hour.
11/10/2017 21:14:09 addresses updated
11/11/2017 11:42:03 addresses updated
11/11/2017 12:42:02 addresses updated
11/11/2017 13:42:03 addresses updated
11/11/2017 16:42:02 addresses updated
11/11/2017 17:42:04 addresses updated
11/11/2017 19:42:03 addresses updated
11/11/2017 20:42:02 addresses updated
11/11/2017 23:42:04 addresses updated
11/12/2017 01:42:02 addresses updated
11/12/2017 02:42:02 addresses updated
11/12/2017 09:42:02 addresses updated
11/12/2017 10:42:02 addresses updated
11/12/2017 15:42:02 addresses updated
11/14/2017 03:42:03 addresses updated
11/15/2017 02:38:02 addresses updated
11/15/2017 04:03:03 addresses updated
11/15/2017 09:17:03 addresses updated
11/15/2017 11:21:04 addresses updated
@tracerrx are you on a beam that has congestion issues? One thing I've noticed is that during periods of extreme congestion/packet loss on the satellite link, the web acceleration process on the HT2000W will die, presumably due to needing 2-way IP communication with the gateway and some sort of watchdog timing out. Peraps there is some other connection-based timeout for the IPv4 over IPv6 tunnel back to the CGN device that runs out during periods of heavy packet loss and congestion, causing the behavior we're seeing?