Root Cause:
In /usr/share/gl-ngx/oui-access.lua (lines 67–85), the allowed hosts table is hardcoded to only accept console.gl-inet.com, localhost, and interface IP
addresses:
local hosts = {
['console.gl-inet.com'] = true,
['localhost'] = true,
['127.0.0.1'] = true,
['::1'] = true
}
if lanip then
hosts[lanip] = true
end
add_ip_addr_hosts(hosts)
local invalid_host = not hosts[host]
local initialized = c:get("oui-httpd", "main", "inited") == "1"
if initialized and invalid_host then
return ngx.exit(403)
end
Any request with a Host header set to the router's system hostname (e.g., system.@system[0].hostname), DHCP domain, or router.gl-inet.com is flagged as
an invalid_host and rejected with 403.
After backing up your configuration, update to the latest v4.11.1 beta and repeat the same curl test with Host: router. If you prefer to remain on stable firmware, use the LAN IP or console.gl-inet.com until the fix reaches a stable release. Avoid permanently editing oui-access.lua; the change may be overwritten by an update, and the host validation is a security control.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I don't seem to have this problem as OP, I just gave it a dhcp domain in luci called gamepc.lan for my brume3.
But on the Flint 4, I use various domain names on different vlans.
I wonder what the need is of this restriction.
There is also another issue I found the dhcp settings on the newer 4.11.0 beta 3 is missing certain settings for dhcp in luci, like the option local '/lan/' but this option can clash if a downstream router also uses this, it gives dns probe errors.
The final implementation has not been decided yet. We are considering how to handle VLANs created through the GL.iNet web Admin Panel, as well as providing a way to explicitly add custom hostnames or domain names.
The Host restriction is part of our defense-in-depth against DNS rebinding and related browser-based request attacks, including CSRF-style attacks.
Thank you as well for reporting the missing DHCP options in LuCI on 4.11.0 beta 3 and the possible downstream /lan/ conflict. We will check these points with the team.
Regarding your report that the DHCP option local '/lan/' is missing on the BE14000 running v4.11.0 beta 3, could you share some more details or the exact steps needed to reproduce the issue?
We checked this locally, and the option appears to be present:
uci add dhcp domain
uci set dhcp.@domain[-1].name='seerr.lan'
uci set dhcp.@domain[-1].ip='point to a local web server'
uci commit dhcp
/etc/init.d/dnsmasq restart
On the Brume3 downstream:
you have the default settings, which include also the option local '/lan/'
On the Brume3 lan you use the pc and try visiting seerr.lan
This then clashes and results into a dns probe possible message, the reason is because this local option tells the router to be the authority of the lan domain, but there cannot be two (even when authoritative dhcp has been unchecked), OpenWrt still seem to be domain authoritative, perhaps this is a different thing.
So the solution is to delete the full line on the brume3.
uci del dhcp.@dnsmasq[0].local followed by uci commit dhcp and then a dhcp restart.
Now the clients behind Brume3 can access the domain without blocking it.
On vanilla OpenWrt this issue also exists I guess by intentional design, but that is a issue not easy to spot once you have it, luci can be sometimes very doable to options and meanings.
Edit:
To note about my previous message, it is purely missing from the luci ui, the dhcp options seem to be very stripped down vanilla and brume3 does have it, but not on the Flint 4.
Thank you for the detailed explanation and reproduction steps.
The conflict is expected when both the upstream and downstream routers treat the same domain as local. The local '/lan/' setting is part of the default OpenWrt configuration and follows dnsmasq's normal behavior: queries for that domain are handled locally rather than forwarded upstream. There is therefore no universal automatic fix, since the correct setting depends on which router should handle the domain. In your topology, removing or changing this setting on the downstream router is the appropriate solution.
We agree that this can be difficult to identify for users who are unfamiliar with dnsmasq. Enabling dnsmasq query logging is usually helpful because the logs show where the DNS queries are being received and handled.
Regarding the option not appearing in LuCI: as you know, the Flint 4 now uses the MediaTek SDK OP25. The LuCI pages and options available there depend on the components provided and integrated in the SDK, so they may differ from those on the Brume 3 MTK SDK OP21 even when the underlying configuration is present.
