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.
@Liz please have the Engineers look at the timing of when the modems IPv6's are changing via DHCP vs when the users are dropping connections.
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