Open ipv6 firewall for allowed services

[ipv6ftw]

Hi All,
Thanks for the Asus-merlin firmware - I've found it really useful.

I've been using ipv6 to connect two locations together - both sides use an AC68U with the Asus-Merlin firmware. The one site is only reachable via ipv6, so I've been seeing how to make everything work that way. I've noticed that ipv6 doesn't seem to be considered by the UI when allowing services. Specifically, the option to "Allow SSH access from WAN" doesn't open the ipv6 firewall for the selected port. Similarly, when starting the OpenVPN client, the port used is blocked by the default ipv6 firewall rules. So the outgoing packets work, but the rules prevent the packets coming back from being delivered.

I've added these commands to the "firewall-start" script:
ip6tables -I INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -I INPUT -p udp --sport 1194 -j ACCEPT

Which fixes my problem, kind of.

Would it be possible for the UI to make these rules automatically, as appropriate for the enabled services? It seems something is already happening to open the ports on the ipv4 firewall. It only makes sense to do the same for the ipv6 firewall.

 

[RMerlin]

This might not work anymore with the latest code, as Asus is now binding some services to specific IPs/interfaces, for security reasons. I didn't notice if they were supporting binding it to IPv6 or only to IPv4.

 

[ipv6ftw]

This might not work anymore with the latest code, as Asus is now binding some services to specific IPs/interfaces, for security reasons. I didn't notice if they were supporting binding it to IPv6 or only to IPv4.

Interesting - what firmware version brings those changes? I had to downgrade to 378.56_2 because 380.58 was not able to maintain a native ipv6 prefix assignment on the comcast side - it would get a ipv6 prefix assignment on boot, but then that would clear from the settings about 2 hours later. The side using webpass works fine with 380.58.

 

[RMerlin]

Interesting - what firmware version brings those changes? I had to downgrade to 378.56_2 because 380.58 was not able to maintain a native ipv6 prefix assignment on the comcast side - it would get a ipv6 prefix assignment on boot, but then that would clear from the settings about 2 hours later. The side using webpass works fine with 380.58.

380.59, or Asus's 380_2xxx (first 2xxx releases would block the port if the service was disabled, latest 26xx betas now properly bind to a specific IP instead).

 

[RMerlin]

I can confirm that starting with these versions, dropbear no longer binds to the IPv6 interfaces - only specifically to the router's IPv4 LAN IP.

Dropbear allows to specify an IPv6, however I fear it might open SSH to the whole WAN and not just to the LAN. Unfortunately, my tests are limited to IPv6 tunnels, so I don't want to take the chance of making the change.

For now, best workaround is to run a second instance of dropbear that specifically binds to your router's IPv6:

dropbear -p [router's IPv6]:22

The [] are what tells dropbear that you are specifying an IPv6. You could add this second instance in a wan-start script, for instance.

Note that if you actually enable WAN access to dropbear, it will revert back to its old behaviour of binding to ever available interfaces. In this case, all you might be needing is to open the firewall - something I can certainly implement in the firmware.

 

[ipv6ftw]

Yes I am interested in this from the "Allow SSH access from WAN" perspective. I expect users with ipv6 only LANs will be unlikely for some time to come, but having only a routable ipv6 WAN address will be increasingly common in the future.

So I would appreciate the ipv6 firewall opening up automatically when SSH is allowed from WAN.

 

[RMerlin]

Patch committed today.

 

[ipv6ftw]

Thanks!