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

Technical Support for Routers
1

Hello everyone,

I'm encountering a DNS issue and would appreciate some help from the community. Here's my setup:

Setup:

  1. I have three routers:

    • A router running vanilla OpenWRT 23.x
    • A GL.iNet Mango V2 running OpenWRT 19.x (GL.iNet firmware 3.x)
    • A Beryl AX (MT6000) running OpenWRT 22.x (GL.iNet firmware 4.x)

  2. At home, I have a Raspberry Pi running Pi-hole with Unbound, acting as both the DHCP server and DNS resolver. I also have a VPN set up (PiVPN) so I can connect remotely to my home network. The Pi-hole filters and resolves DNS for the VPN connection.

  3. I use several devices (smartphones, tablets, laptops) that connect via WireGuard, and when they connect directly to the VPN, DNS resolution works fine for internal services such as:

    • plex.domain.lan
    • promox.domain.lan
    • nas.synology.me
    • pi.hole

Problem Details:

When I use the router running vanilla OpenWRT 23.x, everything works as expected:

  • The router connects to my VPN and uses Pi-hole as the DNS resolver.
  • However, initially, the router doesn't resolve internal DNS names (though I can ping the servers).
  • To fix this, I go to the LAN interface in LuCI and add a custom DHCP option (option 6, with the IP of my Pi-hole). After restarting the router, all devices connected to the router resolve DNS correctly via Pi-hole.

The same fix works with my Mango V2 (GL.iNet firmware 3.x). I add DHCP option 6 (with the Pi-hole IP), restart, and everything works fine. No extra changes are needed on the Pi-hole or router side.

Issue with Beryl AX (Firmware 4.x):

When using the Beryl AX (GL.iNet firmware 4.x), even after adding DHCP option 6 with the Pi-hole IP, DNS resolution is still handled by the router instead of Pi-hole. It's as if the router is ignoring the DNS server specified in option 6.

This issue only happens on the Beryl AX with firmware 4.x. The same configuration works perfectly with the Mango V2 and other routers using GL.iNet firmware 3.x or vanilla OpenWRT.

Question:

Has anyone experienced this issue with firmware 4.x? Is there something new or different in the DNS handling that I need to adjust?

Any help or guidance would be greatly appreciated!

Thanks in advance.

I can add my config files:

DHCP

``config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
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'

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option force '1'
list dhcp_option '6, 10.80.198.1'
list ra_flags 'none'

config dhcp 'wan'
option interface 'wan'
option ignore '1'

config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'

config domain
option name 'console.gl-inet.com'
option ip '192.168.60.1'

config domain
option name 'console.gl-inet.com'
option ip '::ffff:192.168.60.1'

config dhcp 'guest'
option interface 'guest'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'disabled'
option ra 'disabled'

just in case here is my config of my wireguard peer, it works fine in a openwrt vanilla router, glinet mango and I tested another glinet GL-AR750S slate but those two were using firmware 3.x The issue is with the firmware 4.x

Wireguard Peer 
[Interface]
PrivateKey = redacted
Address = 10.x.198.11/24
DNS = 10.x.198.1 #pihole vpn dns (used pivpn)

[Peer]
PublicKey = redacted
PresharedKey = redacted
Endpoint = dns.apple.com:51820
AllowedIPs = 0.0.0.0/0

currently the beryl ax is using 4.6.2 stable.

Also I tried to check the resolv conf but even if I put the dns of my pihole dns manually is overwritten, so my guess something overwrites the dns or gives more priority. I don't have any issue with other glnet routers is just this one using 4.x

/tmp/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1

/tmp/resolv.conf.d/resolv.conf.auto
# Interface wan
nameserver 10.105.10.1
search lan
1 Like
2

Hi,

May try these to temporary command to configure the dnsmasq process:

# set dnsmasq
uci set dhcp.@dnsmasq[0].local='/lan_chgd/'
uci commit dhcp

# restart dnsmasq
/etc/init.d/dnsmasq restart

# set VPN dnsmasq
sed -i 's/local=\/lan/local=\/lan_chgd/' /etc/dnsmasq.conf.vpn

# restart vpn dnsmasq
. /usr/bin/route_policy
handle_dns

Refer from:

4

hello there!,

yes these commands fix the issue. I'm guessing something is different in the firmware +4.3.x?

I didn't have any issues with these although I just used the DHCP option 6 for a more general fix.

GL-MT300N-V2 using firmware 3.x
GL-AR750S using firmware 3.x and last firmware 4.3.17

and I couldn't make it work until know with my GL-MT3000 Beryl AX with firmware 4.x

thank you. Would be possible maybe add in the future something for the glinet gui?

5

Summary of the fix

provided by @bruce

Fix for DNS Resolution Issues Over WireGuard VPN on GL.iNet Routers (OpenWrt-Based Devices)

So to leave this in the future, just in case someone else has issues with resolving their dns in my case was with a pihole via wireguard vpn.

Issue:

When connected via WireGuard VPN, devices can be pinged by IP address, but DNS names (like local network hostnames) are not resolving properly. DNS Resolution with Pi-hole or other dns services and Gl.iNet Firmware +4.x on Beryl AX

Solution:

Follow these steps to fix the DNS resolution issue on GL.iNet routers or any OpenWrt-based device:

1. Change Local DNS Domain:

Update the dnsmasq configuration to use a custom local domain (/lan_chgd/) for devices on the local network instead of the default /lan/.

uci set dhcp.@dnsmasq[0].local='/lan_chgd/'
uci commit dhcp

2. Restart DNSMASQ DNS Service:

Apply the new DNS configuration by restarting the dnsmasq service.

/etc/init.d/dnsmasq restart

3. Update VPN DNS Config:

Modify the VPN's dnsmasq configuration to use the same custom local domain for VPN-connected devices.

sed -i 's/local=\/lan/local=\/lan_chgd/' /etc/dnsmasq.conf.vpn

4. Restart VPN DNS:

uci set dhcp.@dnsmasq[0].local='/lan_chgd/'
uci commit dhcp

What This Fix Does:

  • Changes the local DNS domain from /lan/ to a custom one (/lan_chgd/) for both regular LAN traffic and VPN traffic.
  • Ensures that devices connected via WireGuard VPN can resolve local hostnames (e.g., device.lan_chgd).

Why This Fix is Needed:

When using WireGuard VPN, the default DNS settings may not properly resolve local network hostnames, which can cause issues when trying to access devices within your LAN via their hostnames. This fix adjusts the DNS server's local domain handling and ensures that DNS resolution works for both regular LAN users and those connected via VPN.

3 Likes
6

Thanks for your summary.

Already in the develop plan, I think that GL will repair it in the near future firmware.

1 Like
8

Replying to my post since I couldn't edit the original.

This also affect other routers using Firmware 4.3.18
On GL-AR750S and MangoV2 using Firmware 4.3.18

If you follow the same code there is an issue that dnsmasq.conf.vpn doesn't exist, I'm assuming because at this point of the firmware it wasn't added but it works if you use the command "touch" and create the file, although the dnsmasq.conf.vpn is empty even if you use sed -i

# set dnsmasq
uci set dhcp.@dnsmasq[0].local='/lan_chgd/'
uci commit dhcp

# restart dnsmasq
/etc/init.d/dnsmasq restart

# set VPN dnsmasq
sed -i 's/local=\/lan/local=\/lan_chgd/' /etc/dnsmasq.conf.vpn

# restart vpn dnsmasq
. /usr/bin/route_policy
handle_dns

after this you can start using the dns resolving of your vpn with wireguard, could be pihole, adguardhome, unbound, etc

So please devs if the fix is already in the plan can you add this at least for devices that are stuck in firmware 4.3.18 like mangov2 and ar750s among others... please?

9

Codes updates are synchronized to all models firmware, the premise is that if the old models firmware have update plan. Surely the Beryl AX is in plan.

10

Ran into this issue too on my Opal hijacking all the dns traffic. The commands work but ideally there is a switch in the gui somewhere. I have tried the latest stable and beta but can't find any options pertaining to this. Does it exist yet?

I have another router + Pi-hole behind the Opal for testing/monitoring purposes and none of the pc's configured to use the Pi-hole were able to resolve anything. I am glad this is by design/default. Just wish the default wouldn't tamper with traffic in that way.

Thank you for sharing the solution though. I also saw how you helped fix captive portals when someone was on a cruise, thats a big +1 from me! Let's hope I just missed the option or that it will be added in the next beta for the Opal.

12

Hey, personally, I don't think they'll fix it. The Opal is an older device by the current standards, and while they may make promises, their focus seems to be on newer hardware. The Opal is essentially end-of-life this year or next, so it's probably best to either replace it or let it go. A better option would be to consider a router with a MediaTek chip, as these devices are more likely to be supported by OpenWRT, giving you the flexibility to switch if the device is eventually discontinued.

Additionally, the Opal doesn't support native OpenWRT because it uses an SDK provided by SiFlow, which makes it harder for the OpenWRT community to support it. You can read more about this in the OpenWRT forums just google OpenWRT support for GL.iNet devices.

My advice would be to look at newer devices, like the Beryl AX. The issue you're facing may eventually be fixed, but getting a device that's more likely to receive long-term support is a safer bet. Alternatively, you could opt for another router from a different company that supports vanilla OpenWRT, offering more flexibility for future updates.

they promise to fix on the Slate GL-AR750S and then is gone. They are working on new routers with wifi 7, so i don't think older hardware has priority now. The Mango v2 has the same issue and i don't think they will fix it.

1 Like
13

You make good points!

Too bad the next thing up in this form factor/feature set is twice the price. A travel router needs to be cheap enough to replace on a whim. The Opal is perfect in that regard. Just under 40 euro most of the time.

But you're right and a good rule is to never buy anything based on promised features or fixes. I'll continue my tests and see what other surprises I run into. I Was very confused when my dns suddenly broke lol.

If there are any other surprises I'll return it. Already a bit annoyed that I have to compensate for the dns thing whenever I end up reinstalling or mess up the settings. Hopefully it will be in a LuCi backup.

14

If you can get a second handed Slate GL-AR750S that can be re flashed with vanilla openwrt with the most modern updates, 23.x, hopefully can also be upgraded to the new 24.x that will be ready in the next few weeks.

or there are other company relative new that also make travel routers use google, or check third party that can support vanilla openwrt or just save and wait for a deal with beryl AX or check aliexpress, avoid CN version, just get the european/american version of the glinet Beyl AX. The bug will be there.

15

The fix doesn't seem to stick between reboots and adding the commands to rc.local also does not seem to work. Maybe I'm doing something wrong.

16

I can’t get this fix to last between reboots or applied st startup. Just going to take my losses and return this little router. Guess if I’m gonna have to pay more money for a small pocket router I’ll get a higher end brand with a pro firmware instead.

17

The Opal only hijacks the DNS traffic if the function is enabled. Did you try to disable the "Override DNS Settings for All Clients" function?

18

It wasn't enabled, tried to toggle it but doesn't fix anything. It is very weird that this happened.

Internet <-> Wireless AP <-> Opal <-> My router <-> Clients

My router receives an IP from the Opal and runs its own NAT/DHCP for my clients. It is odd that despite my clients receiving the Pi-hole IP as DNS and its set resolving is completely broken until I apply the fixes posted above. The DNS requests from clients somehow gets intercepted/changed/broken. As soon as I replace the Opal for another router in repeater mode everything works again.

I'm 100% that the Opal caused it. I will try another factory reset but I already tried at least 3 times on both stable and beta firmwares and once I setup the extender I can't resolve anything on clients until I apply the fix above. I did try those toggles and also the other related toggles on the DNS page.

Thank you for chiming in!

My steps:

  • Factory reset
  • Setup extender
  • Try opening a website on a client and it fails to resolve
  • Apply code posted above and resolving works again

No settings are touched and everything is default other than following the extender setup wizard.

19

Repeater mode will always create NAT, so yeah, Extender is the way to go to get a "real" AP.

20

Either way nothing I tried fixed the dns thing. I rather not run adguard on the router itself as my Pi-hole (RPi4) does more than just block ads and I need to keep those functions when on the go too.

Maybe I misunderstood this thread but seems a problem was identified and found to be there by others users and me. A fix was posted which works, but doesn't stay between reboots and we're waiting for this fix to be added to a firmware so it's fixed or gives us a toggle to enable the fix.

But I could be misunderstanding. Sorry.

21

If there is already a fix, you can integrate it into /etc/rc.local to make it persistent after reboot.

22

Guess you missed my post. I'm not going to try anything anymore and return it. Spend way too many hours on it already. Can't justify spending any more.

25

Remember, the fix is just a temporary workaround; there’s no concrete evidence that it will be patched officially. This issue seems to primarily affect a small group of users with specific setups, like using DNS filters such as AdGuard Home or Pi-hole alongside a VPN like WireGuard.

Unfortunately, it’s understandable that promises about future fixes aren’t guaranteed.

I’m really sorry to hear about your frustration, my friend. I totally get how exhausting it can be to spend so much time trying to troubleshoot without a lasting solution. Wishing you the best moving forward.

1 Like