I have a new installation with a HT2000W satellite modem. After the unfortunate realization that IPv4 is delivered via CGN and no inbound port forwarding is possible, I'm trying to get IPv6 working for inbound services (security cameras, etc.).
I have a Ubiquiti Edgerouter installed behind the HT2000W. The HT2000W has its firewall disabled and is properly assigning a /62 to the Edgerouter via DHCPv6-PD for assignment to its LAN. The Edgerouter has IPv6 connectivity and can initiate outbound connections properly. However, I can't ping the Edgerouter's IPv6 WAN address from the Internet. I can ping the HT2000W's LAN address from the internet. Traceroutes to the Edgerouter WAN address seem to die at the HT2000W. Taking a packet capture at the Edgerouter WAN (connected to HT2000W LAN) ethernet interface doesn't show any inbound ICMP echo when pings are being sent from the Internet.
Am I missing a firewall step on the HT2000W here to allow inbound IPv6 to the LAN?
Haven't heard anything back. I've pinged them for any news to share.
Where do we stand on a firmware update for the HT2000W to enable IPv6 inbound traffic and ultimately customers' ability to access LANs via public IP address without all the workarounds noted in this thread? Looks like the last response on this thread was on 11/20/2017...This is a very important issue that needs to be resolved for the rapidly expanding availability of the IOT's -- especially security systems that do NOT work through the vendor's server.
Ditto, any update from the "Engineers" regarding this issue?
I am new to this forum, but also have 3 "systems" inside a LAN that need to be remotely accessed by IP (IPv6 I guess, as IPv4 seems impossible via HT2000W). Anyway, these 3 devices include: pool-system controller, security camera NVR, and security system. I'm not sure all of these devices have the ability to change/set their IPv6 address, so I'm hoping that the HT2000W will be able to NAT from some IPv6 (or DDNS IPv6) address to a LAN IPv4 with an associated Port #.
From another forum:
"There are scenarios where a person may have already deployed a private IPv6 network using ULA space (unique local address; it's equivalent to the RFC1918 private IP space (192.168.x.x etc)). If they didn't want to re-IP their network, they could use NAPT (network address/port translation) to forward requests from the ISP supplied GUA (globally unique address aka public IP) to the ULA network and vice versa."
No updates, and I imagine that the whole Gen5 system grinding to a halt due to oversubscription is probably a big enough distraction that we won't see much progress on this anytime soon.
I will note that the frequency of my Hughes-assigned IPv6 prefix changing has gone way down since this thread started. It stayed constant for most of the month of December, then changed during the outage that took down everyone on Echostar 19 on New Years Day.
Thank you all for posting. I've asked engineering for an update, I'll post back once I have anything to share.
Checking in on any update from the "Engineers" regarding this issue?
We have added a 4th "system" on our LAN that needs to be remotely accessed by IP: lighting control by Lutron RadioRa. That is in addition to our pool-system controller by Pentair (ScreenLogic app), security camera NVR from Clare Vision, and security system from Bay Alarm. All of these systems want an IPv4 external address, or some DDNS equivalent, to remotely access their on-site hardware.
Should I be looking for another ISP, or is HughesNet management aware of this shortcoming - and considering a solution?
@Healdsburg If you have moderate experience with linux, you can use a raspberry pi to ddns with dynv6, then tunnel into the raspberry via the ddns ipv6 address and you will have access to your local ipv4's via the raspberry.
I know no other way around the issue currently... Even if your devices supported ipv6, the way hughes dynamically assigns ipv6 addresses and changes them frequently, would make them unaddressable anyway.
Only way I can think of for reliable and constant IPv6 addressing, or any IP addressing, to work on HughesNet constantly changing dynamic client addressing is if they invested in servers at each gateway that locked in MAC/IPv6 addressing by SAN and then interpreted it no matter the dynamic address on the system. Then give the customer some control to add/delete/publish addresses over the Internet.
In other words, a whole other server bank just to handle IPv6 addressing by client SAN.
Not so sure they'll invest in the software and equipment to do so. And would add one more layer of slowdown although should be quite small.
@pswired is correct, thats NOT how this works...
I've had several PM's asking basically the same questions so i'm going to respond in public here instead.
First if your device (DVR etc) being able to support ipv6 is only 1/2 the problem. The app you use on your remote iPhone/iPad etc also must be capable of supporting ipv6.
Second, you cant use dyn or similar for ddns, you must use an ipv6 ONLY ddns such as dynv6.com. If you use dyn, it will return the IPv6 and IPv4 records (of the gateway) when doing reverse lookups of the hostnames. Your offsite app will probably default to using this "false" ipv4 record.
Third, if both sides dont fully support ipv6 (Viewer app and DVR) then the only way to make it accessible over hughes remotely will be to create a VPN. You will need to create a ipv6 VPN from your home to your device and then create routes to tunnel the necessary ipv4 addresses through the ipv6 vpn. I know this works on a SonicWall, but I have no idea how to set this up on openWRT/pfSense/YourRouter. Note that this will be SLOW (especially for video) due to the extra overhead of the VPN and high latency of the connection... However it works fine for my Crestron control system. In leui of usig your router to create the VPN (if you have a basic consumer device that doesnt support VPN or allow ipv4-->ipv6 tunneling) you can use a raspberry pi instead. There are lots of examples of using openVPN on a raspberry on the internet. Either option will require "Moderate" computer skills to implement.
Fourth, hughes implementation of ipv6 is "strange". They "Shouldn't" be changing the ipv6 prefixes our modems are assigned, this defeats the purpose of implementing ipv6. What it appears they have currently setup is more in line with a carrier grade nat (CGN) which is common for ipv4, but unecessary for ipv6 implementations.
Finally, if you need access to your remote systems and you don't want to implement anything liek the above, you will need to purchase IOT items that use some sort of "Cloud" access control (a la unifi cloudkey type functionality).
I hope this helps clarify any of the confusion.
@tracerrx- I'm a new hughesnet customer, and like many others, i was told that i would be able to conduct inbound services. i've spent the morning reviewing and catching up on this and related threads, which indicate that it's just not going to be simple to make that happen. However, do i understand correctly that using dynv6.com and a router with OpenVPN, which supports IP6 protocols, behind the HT2000W, will allow for remote access to a Creston system (and other downstream IP6 addressable components)?
I have a business sytems linksys LRT214 VPN router with openVPN. I've had it working fine for some time off a conventional fiber line with DynDNS, but have moved to an area where Satellite is the only option, and Hughesnet was recommended.
I don't have anything running openVPN to test with... But as long as you have a way to get the devices ipv6 to dynv6 it should work...
Then from you iphone/android etc, once connected to the VPN you use the local crestron ip...just like when your in the house.
I was just researching the same problem as everyone else and had a thought of why the network IDs might be switching...
I have been noticing that location services on my devices (like for weather) have been switching locations fairly often, used to be Germantown a lot but I have been seeing Texas and a few other states lately (usually very far from me, but that is a different issue). This leads me to believe that the satellite may be handing off to different NOCs, if that is the case the network ID could change at the same time.
This is just my theory based on me observations. It doesn't really help anything but may be an explanation.
You location constantly changing is due to HughesNet using shared, rather than static, IPs, and those IPs changing on a regular basis. Because the IPs used have different registration locations, your device location services will change accordingly.