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?
You actually will need to enable the firewall, and forward the appropriate service under Firewall > IPv6...
As far as pinging and such, pretty sure that's droped regardless at the modem unless you disable the Intrusion Detection settings.
Thanks for the reply.
I actually did try re-enabling the firewall and enabling IPv6 rules for an inbound service or two. I suppose I could have gotten the syntax wrong though, do you know if there are any documents for this feature?
I do have intrusion protection disabled- is there any other way to allow ICMPv6 (echo requests specifically) through to the LAN?
I sent this up to the engineers who are better equipped to answer this. I'll let you know what I find out.
No reply, I've pinged them back for any insight into your concern.
I also have this question. When I signed up for services they explicitly told me I would have a dynamic but ROUTABLE ipv6 address (asked twice to confirm). After my install today my router got a fdxxx(PRIVATE) ipv6 address. Called and they told me they only assign public addresses to business accounts?!
Willing to upgrade (even though the first call explicitly told me I would get a dynamic but routable ipv6), but want to make sure your actually assigning routable ipV6's... Need a way to get back in so I can control my whole-home automation system.
@tracerrx, the address you see in the HT2000W's WAN status section is just the link-local address on that interface. There is a routable block that's assigned to the HT2000W's LAN interface. If you plug a device into the LAN, it will be assigned a public routable address block via an IPv6 router advertisement. Also, you can connect a router to the HT2000W's LAN port and receive a public IPv6 block via DHCPv6's prefix delegation feature, which will allow that router to assign another routable subnet to its inside (LAN) interface(s). The HT2000W is giving a /62 to my router in this case.
HOWEVER, it appears to me that the HT2000W is filtering all inbound IPv6 connections to devices connected to the LAN network regardless of the firewall being enabled or disabled, or adding allow rules in the IPv6 section of the configuration. I can ping my HT2000W's LAN IPv6 address from the public Internet, but can't ping any of the devices connected to it. Running packet captures on those devices shows no inbound ICMPv6 at all from the host on the Internet sending the pings. So it appears that the firewall in the HT2000W is not being disabled when instructed to do so through the web UI.
Input and suggestions from a Hughesnet network engineer would be very helpful!
@pswired interesting... will try again but my Sonicwall is set to dhcpv6 for the port connected directly to the lan of the HW2000W and it doesnt seem to be getting anything other then an FDxxxx ... Will play around with my settings and see what happens.. But totaly agree we need a tech to weigh in here on how this works. I'm not trying to sream video out our anything, just net access to my home network to send commands to my crestron system etc.
Yup, looks like you're well on your way to getting that block assigned to the Sonicwall LAN. Let me know if you have any results different than mine as far as accessibility to those addresses from the Internet.
Unfortunately I have a feeling we'll need to wait for a future software version of the HT2000W for this to work. All of my testing shows that the "disable firewall" checkbox option doesn't work for IPv6.
Thank you for your patience, I was just informed that we have two engineers working on addressing outside IPv6 requests on the HT2000w. I'll let you know once I get any updates from them.
@Liz Thanks for the update
@pswired Im not an IPv6 expert, but I think you want your router to assume one of the ipv6's instead of handing our ipv6 from your router to internal devices. Unless of course your running full IPv6 internally. I have the sonic grabbing the /62, then using a /128 itself (see below). Then I "should" be able to map IPv6 port incoming on the WAN interface to any ipv4 port on the LAN (6:4 routing). Unfortunately i'm seeing exactly what you are... either the Hughes routers are not disabling firewall for ipv6, or they are filtering somewhere else.
@Liz Thank you for the update and we appreciate the effort to resolve this. If there's anything I can do to help, let me know.
@tracerrx The "proper" way to implement IPv6 in this case is to indeed attach that /62 to your LAN and hand out public addresses to your LAN devices directly. Your devices will then run dual stack and requests to IPv6 enabled hosts will use one network stack, IPv4 another. Then add firewall rules to your router so that services on your LAN are not exposed to the Internet except as desired. However, if the LAN devices you want to be publicly accessible do not support IPv6 natively, then yes, you'll need to do as you describe and 6to4 at the Sonicwall.
It looks to me like everything is good to go in the Hughes network itself and the problem lies in the HT2000W- when I run traceroutes to the IPv6 address of a device behind the HT2000W, I see the 600ms latency jump at the last hop before the traces die. That tells me the packets are making their way all the way to my CPE and dying there. Hopefully the engineers working on this will get it sorted and release a new firmware soon. And hopefully that firmware will allow the firewall to be completely disabled instead of needing to add individual rules for each service allowed through.
Hey! It looks like it's working now! Last night I noticed that my IPv6 DHCP allocation changed (maybe the modem rebooted, I haven't checked yet). Now I can ping my downstream router's IPv6 address and access its HTTP interface from the Internet via IPv6!
Thank you for getting this in front of the right people, @Liz, and please relay my thanks to the engineers who got this resolved quickly. Impressive to have a firmware fix rolled out and functional in about a week.
This is somewhat light testing so far, but I'll continue to verify everything is working.
Everything was working well. I had my security cameras set up for IPv6 access from the Internet and I was able to view them from my smartphone via cellular, etc...
Then I got the bright idea to log in to the HT2000W and see if anything had changed in the IPv6 firewall settings options. I had the firewall enabled and a single IPv6 rule added to allow remote admin access to my downstream router. I decided to try disabling the firewall and removing that rule. Well, that made all the IPv6 inbound stop working. So I reverted my changes, and guess what- doesn't work now. Same symptoms as when I started.
After some additional experimenting, here's what I think needs to be done, and I can reproduce, to get inbound IPv6 working:
-Enable the firewall with the "firewall features" checkbox in advanced setup
-Add an IPv6 firewall rule. It doesn't matter what the rule does, but one must be present. Mine allows TCP port 1 to a null address (::)
-Reboot the rotuer and don't maky any further firewall changes. This is important--inbound stops working if you make any further firewall changes after the reboot.
So, my conclusion is that there's a bug that is worked around with the above process. Last night's change must have been something unrelated done by Hughes that caused a modem reboot which triggered the last step of the above workaround.
Good detective work.
Now that I think of it, I think I had a Cisco router that had a "feature" like that in it's firmware, but for IPv4 port forwarding. Ineresting.