HughesNet Community

HT2000W IPv6 inbound services

Showing results for 
Search instead for 
Did you mean: 

HT2000W IPv6 inbound services

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.


If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!

I would love to see your instructions for setting up with a RPi if you could post them

Here is a quick (Totally from memory) list of the steps to follow.  Note that if your hikvision DVR does not support IPV6 that it will still not be accessible.  I’m not sure of your tech/linux comfort level, but if you have ever used linux this should be very simple.
Note, prior to performing the below you need to establish a FREE account at
1. Download the latest and greatest image of raspbian from 
2. Follow instructions for burning the image to an sd card (google for your os)
3. You will need to place a blank file called "ssh" in the root (top level directory) of the sd card AFTER you burn the image (note you may have to remount the sd card to see it on some os's).  This will enable us to ssh headless into the pi. Also note that the file should have NO EXSTENSION (.txt etc).
4. Connect the pi to your home router via ethernet, the pi will dhcp and you can obtain the ip address from your routers assigned dhcp screen.  You should setup your router to always hand this mac address this IP, but thats not covered here.
5. SSH into the pi (on windows you will need a terminal like putty, on osx just use terminal).
6. You will be prompted for a password, by default the password is "raspberry"
7. Change your password
   $ passwd
8. You will be prompted to enter a new password, choose wisely as the pi will be publicly accessible
9. Get your pi up-to-date with patches etc
   $ sudo apt-get update
   $ sudo apt-get dist-upgrade
   $ sudo rpi-update
10.  Reboot your pi
   $ sudo reboot
11. Reconnect from your terminal
   $ ssh (note use the pw you set)
12. Since were public accessible lets change the default port for ssh
   $ sudo nano /etc/ssh/sshd_config
   Comment out the line that says "Port 22" by placing a hash in front of it like "#Port 22"
   Below that line add "Port 12345" where 12345 is a port number you choose
   $ sudo service ssh restart
   $ logout
13. From your terminal reconnect, note the new port number
   $ssh -p 12345
14. Lets install the dynv6 DDNS script
   $ cd ~/7a07f5ac901844bd20c9
   $ cp ~/
   $ cd .. 
   $ sudo chmod +x ./
15. Edit the dyn script
   $sudo nano ./
   Save and exit.  This will prevent dynv6 from updating your NAT'ed ipv4, remember we only want the ipv6
16. The dynv6 script is now executable and we can test it by running 
   $token=YOURTOKENHERE ./
17.  Add the script to cron to run every minute
   $ sudo crontab -e
   Add the line 
   */1 * * * * /home/pi/ >> /var/log/dynv6.log 2>&1
   Save the cron file and exit back to a prompt
18. Lets check the loggies and make sure it's working, it should run every minute (command below will read the log file in realtime)
   $ tail -f /var/log/dynv6.log
   To exit tail hit "control-c"
19. Your pi is now accessible via, you can test by using level3 looking glass, choose ping, check the box that says prefer ipv6.
This will send the ipv6 handed out from your hughesnet modem to dynv6.  Note that you will need to further customize the script in order to parse the pi's public ipv6, extract the hughesnet delegated /51, and append it to your "stateless" address of your other device that you want publicly accessible.  Regex will be your hated friend : )
I'm not going to cover hardening your pi here, there are plenty of guides out there on the internet, but at minimal you should at least install and setup 
$ sudo apt-get install unattended-upgrades
# sudo apt-get install fail2ban

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. 

@pswired Agreed... My assigned IPv6 is now changing much less frequently.... 





Good morning,


Thank you all for posting. I've asked engineering for an update, I'll post back once I have anything to share.


If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!


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?

Thanks you!


@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.

Assistant Professor

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.

That’s not the way this works.

@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  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 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.


@tracerrx Thanks. I’ll be trying that today and will post back results.

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.

Distinguished Professor IV



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.  


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro

Works from Level3 Looking Glass --> Atlanta


Screen Shot 2017-09-26 at 9.55.31 PM.png