Network Mode: Access Point: Web server via IPv6?

After playing with the mode ‘Cable WAN’, I changed my GL.iNet White (GL-AR150 with firmware 3.201-release) into the mode ‘Cable LAN’ via the Web interface → More → Network Mode: Access Point. Then, the access point is accessible via IPv4 only. IPv6 would be handy if the used network is IPv6-only or if the DHCP server broke down. That is not uncommon in hotels. In any way, I want to access my access point via IPv6 as well. The following steps have to be done only once in an IPv4-enabled network.

First step: Connect via SSH. With vi /etc/sysctl.conf add

net.ipv6.conf.br-lan.forwarding = 0
net.ipv6.conf.br-lan.accept_ra = 1

exit the text editor vi via the usual esc button and then :wq sequence. With that, your access point accepts IPv6 Router Advertisements and creates a global IPv6 address†. Because your LAN client is going to use the same prefix, you are able to calculate the host ID from the MAC and then the IPv6 from the host ID and the prefix, for example with this Web page …

Next step: The SSH interface works via IPv4 and IPv6. However, the Web interface listens to IPv4 only.
With vi /etc/lighttpd/lighttpd.conf add, after the existing line server.port = 80:

$SERVER["socket"] == "[::]:80" {  }

With vi /etc/lighttpd/conf.d/30-openssl.conf add, at the very end:

$SERVER["socket"] == "[::]:443" {
        ssl.engine                 = "enable"
        ssl.pemfile                = "/etc/lighttpd/server.pem"
}

as the official lighttpd documentation describes.

Final step: Reboot!
Now, the Web interface of your access point is available not only via IPv4 but also via IPv6.

@GL.iNet, please, consider adding IPv6 access in future releases.

† There is one pitfall: If the upstream router does not support SLAAC but stateful DHCPv6 only, this trick does not work. However, until today, I never saw DHCPv6-only in public networks. In private home networks, no SLAAC is rare, too, because you need a static IPv6 prefix for stateful DHCPv6, normally. Anyway, report if you need support for stateful DHCPv6. Then I look into adding that as well.

‡ Not directly related but IPv6 makes it worse: When the network mode is router, my GL.iNet still offers itself to be a DNS proxy. This can be seen by a port scan or simply by going for netstat -tulpen on the device itself. Therefore, in untrusted networks, I manually go for a service dnsmasq stop.

◊ There are voices on the Internet who claim ‘the’ OpenWrt approach would be

config interface 'lan6'
        option ifname '@lan'
        option proto 'dhcpv6'

in /etc/configs/network plus some other magic options. However, everything I tried so far behaved wrong. If you found a working parameter combination, please, report.

1 Like

We’ll support access web server via IPv6 in 4.0.

1 Like

Great to hear. Does this include general IPv6 connectivity in Access Point mode? Or just IPv6 access to the Web interface in Router mode?

All except extender mode.

1 Like

Great. IPv6 in mode Access Point is quite complicated in OpenWrt because I am not aware of anyone having done that before. Even CZ.NIC’s Turris OS failed so far. It is not only SLAAC but also DHCPv6, depending on the M/O/A bits in the IPv6 Router Advertisements. And then extracting the DNS servers (from DHCPv4, IPv6 Router Advertisement, and/or DHCPv6). Looking forward to see your approach then.

I meant, when the mode is ‘access point’. That issue was tackled in this thread …

Found some time to look into that:

uci delete network.globals
uci set network.lan.ipv6='1'
uci commit network

The first command deletes the ula_prefix. This deletion is required if your upstream router advertises itself as DNS server via an ULA. Otherwise DNSv6 does not work. The second command enables IPv6 for sure because the default value auto resulted into ‘odhcp6c[…]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)’ in the system log visible in LuCI.

Then, edit the file /etc/config/network to add

config interface 'lan6'
    option proto 'dhcpv6'
    option ifname '@lan'
    option reqprefix 'no'

The last option does the trick as explained in the OpenWrt Wiki for a LAN client. With all this, the first step – the modification of the file /etc/sysctl.conf shown – in the first post here in this thread is not needed anymore.

However, however, this ‘lan6’ is just a hack as well. On that interface the DHCPv6 client odhcp6c is started. That beast has a lot of issues as

  • it does not honor the flags in IPv6 Router Advertisements,
  • if there is no DHCPv6 server, odhcp6c continues to broadcast DHCPv6 packets, and
  • when the upstream router invalides a prefix, odhcp6c does not remove immediately. Instead it waits until the original lifetime expired.

@GL.iNet, please, partner up with CZ.NIC and their Turris OS because they face the same issues as you. Perhaps you both are able to fund bug fixes and/or find another DHCPv6 client like the WIDE-DHCPv6 client, which perhaps better suites the network mode ‘access point’. The current OpenWrt maintained DHCPv6 client odhcp6c is nice for the network mode ‘router’ but not for ‘access point’ yet.