DNS Resolution Issue with Pi-hole and GL.iNet Firmware 4.x on Beryl AX

SourMilk · February 6, 2025, 1:37pm

This is a golden rule!

Don't buy things based on promises of features or fixes by the manufacture. Plus I'm not amused when I spend an afternoon trying to make the fix work between reboots to be told by staff that I need to do what I have been doing that didn't work. Given they couldn't be bothered to read my posts properly I doubt they will fix this for the Opal firmware.

It is such an easy fix from their point of view too. Build a new firmware with the fix applied and make it available. It wouldn't take them more than hour to fix this issue. Yet they couldn't be bothered to do it in several months. That tells me all I need to know. Unfortunately, because the hardware in the Opal is decent.

SourMilk · February 11, 2025, 3:11pm

The fix does not work when put in rc.local -- I tried that. I even shared steps on how to reproduce.

Now after reach reboot or startup you have to login over ssh and apply this fix and having DNS on the network. Which I would call a work around not a fix. Having customers login using ssh or making them add commands to the start up script to create a new network interface to fix the router form hijacking DNS traffic and play nice on the LAN side of things is kind of weird.

Why not implement a proper fix? I am no networking expert but I am pretty sure that the Opal should not intercept and change all DNS traffic it can see. And at the very least there should be a toggle to make it not do that. The suggested override dns for all clients toggle did not do anyways as I stated in my previous post.

If there are no plans to fix this issue please be honest and let us know.

bruce · February 14, 2025, 2:48am

Hello,

Truly sorry, the response is not timely, may causing misunderstandings.
Regarding the "WireGuard + built DNS service, the client within the VPN network cannot resolve custom private domain", I confirmed with R&D, the SFT1200 was integrated into this fix on v4.7.2.

Please try upgrading to v4.7.2 to check whether the resolve is normal.

SourMilk · February 14, 2025, 2:55am

Oh, thank you!

I will do that first thing tomorrow. Very happy this fix has been added!

hexx1746 · March 15, 2025, 2:15pm

Hi Bruce,
Is there a v4.7.2 for Slate AX? Looking for the same fix for it. Thanks.

bruce · March 18, 2025, 10:59am

Hello,

May I know what firmware version installed of the Slate AX?

Please try upgrading to the v4.7.0 beta firmware for Slate AX, to see if this issue improved
https://dl.gl-inet.com/router/axt1800/beta

VerZZX · March 18, 2025, 2:41pm

Hello, if I install -> GL.iNet download center (4.7.0), which architecture should I use for the package? aarch64_cortex-a53? Because when installing, there is an architecture conflict. In previous firmware versions, the architecture was arm_cortex-a7.

----- 4.6.8

----- 4.7.0

Thank you!

bruce · March 19, 2025, 2:43am

Hello,

Since the firmware of AXT1800 v4.7.0 is 64-bit, it is displayed as ARM v8.
If the firmware of AXT1800 in v4.6.8 and before is 32 bit, so it displayed as ARM v7 (v7l).

As the architecture changes, v4.7.0 is a brand-new firmware version, including upgrades to op23.05 and upgrades to kernel.

If you upgrade by GL GUI > System > Upgrade, there will be no reminder, and it is safe.
It is recommended to upgrade to v4.7.0, and it is not recommended to downgrade to v4.6.8 or below.

VerZZX · March 19, 2025, 6:22am

The problem is that I cannot install any third-party package; it causes an architecture conflict, including aarch64_cortex-a53. (4.7.0)

spork · March 20, 2025, 8:31pm

Try arm_cortex-a8? Might have a better clue if you type uname -a in an ssh session on the slate ax.

VerZZX · March 20, 2025, 9:58pm

I rolled back to 4.6.8 because on 4.7.0, I couldn't install anything due to architecture conflicts. Running the uname -a command showed ARMv8.

I tried installing from here ↓ (luci-compat)

https://archive.openwrt.org/releases/23.05.5/packages/aarch64_cortex-a53/luci/
https://archive.openwrt.org/releases/23.05.5/packages/aarch64_generic/luci/
https://archive.openwrt.org/releases/23.05.5/packages/arm_cortex-a8_vfpv3/luci/

I suppose there is something wrong with the firmware.

bruce · March 24, 2025, 9:30am

Please let me know what plugins you would like to install, provide the openwrt docs / plugin github link will be better.

We will try to compile the plugins for the v4.7.0 of AXT1800.

VerZZX · March 24, 2025, 9:58am

AX1800
Do you suggest that we contact you every time we need specific plugins?
Is it no longer possible to install them as before from Index of /releases/ ? This is a disaster!

Maybe something has already been compiled and is available ?!

luci 
luci-base
dnsmasq-full
bash
curl
ca-bundle
ipset
ip-full
ruby
ruby-yaml
unzip
iptables
kmod-ipt-nat
iptables-mod-tproxy
iptables-mod-extra
kmod-tun
luci-compat
ip6tables-mod-nat
kmod-inet-diag
kmod-nft-tproxy

Vampire_Duchess · March 24, 2025, 12:07pm

Im curious if the current beta fixes are going to the glinet mango v2 and slate ar750s since they have the same bug.

bruce · March 26, 2025, 10:56am

Received.
We will arrange to compile these plug-ins on AX1800 v4.7.0.

bruce · March 26, 2025, 10:57am

Please try upgrading to v4.3.25 on Mango, and test again to check

Vampire_Duchess · March 27, 2025, 6:32pm

Hello!

So I've tested the Beryl AX beta 4.7.4 and is working the DNS resolution from the WireGuard (VPN). I didn't have to go to luci then add the DHCP option 6, and force the dns to resolve while under VPN.

Also on the Network/DNS GUI you can see the ip of the VPN Server

Now, I did test the Mango V2 with 4.3.25 Beta and doesn't not resolve the DNS for VPN. Although the only way is to head to luci settings, then go to interfase lan, the head to the dhcp advanced and add option 6

it doesnt read the DNS from the VPN like Beryl 4.7.X Beta

So, unless we do manually with lucy settings, the dns from vpn is not resolving for Mango. I cannot test the AR750S but I'm assuming will be the same fix.

Let me know if you need me to post more info. Thank you.

mario2 · March 28, 2025, 2:26pm

Just stumbled over this thread. Thanks @Vampire_Duchess and @bruce for the good explanation. I have been trying to fix this for weeks with the DNS loop on the Pi-hole as soon as I turn on the VPN client. After updating to the latest RC 4.7.4, the problem was solved.

My device is also a Beryl AX.

Vampire_Duchess · March 28, 2025, 8:26pm

well it seems is working on Beryl AX, but we still need to check older devices because is the same issue and doesn't have to be pihole, could be any VPN DNS, becase may not properly resolve local network hostnames, which causes issues when you are trying to connect to your LAN (using VPN) is a dnsmasq thing that I hope they can add the fixes to older routers that can use firmware 4.x.x !

hansome · April 8, 2025, 1:41am

For firmware before 4.6,
Please try the following workaround:

uci set dhcp.@dnsmasq[0].local='/lan_chgd/'
uci commit dhcp
/etc/init.d/dnsmasq restart

The resulting configuration is like:

cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_localhost '1'
        option domain 'lan'               # distribute "search lan" for client's /etc/resolv.conf (it's dns suffix for windows interface)
        option local '/lan_chgd/'         # not allow .lan_chgd domain, but allow .lan domain
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option rebind_protection '0'