Using AdGuard Home with OpenWrt, and DNS local loopback, suggested Wiki edit?

Talk about Documentation
1

Hi everyone. Trying to figure out who to ask and where to go for suggesting to edit the Wiki entry for setting up AdGuard Home on OpenWrt.

I accidentally discovered that following the setup instructions as per https://openwrt.org/docs/guide-user/services/dns/adguard-home from a fresh factory OpenWrt flash causes the local DNS loopback to fail, which in turn causes NTP, software upgrades and all connections from OpenWrt to fail.

As of now in the Wiki, they instruct us to only:

Set DNS server to listen on 192.168.1.1 at port 53.

What this means is by default, all IPv4 and IPv6 connections from the router fail. Clients are fine, but the device that OpenWrt is running alongside AdGuard Home fails.

Could I request for the Wiki to add a step right before the “Login AGH” section to copy and paste commands via ssh that will edit the /etc/adguardhome.yaml file to replace the dns bind_hosts with the loopback servers, and restart the adguardhome service?

Example (replace IPv6 with device’s actual one generated by OpenWrt):

dns:
  bind_hosts:
    - 127.0.0.1
    - ::1
    - 192.168.1.1
    - fa1a:c123:1234::1
  port: 53

If I didn’t accidentally discover my OpenWrt connections failing on the device and realised it was due to this issue, I would have been very lost. So the ability to add this to the Wiki guide may help others that will also experience this issue.

Thanks in advance.

2

based on the AGH wiki page, wouldn't it be easier to simply replace 192.168.1.1 with 0.0.0.0 at

  1. Set DNS server to listen on 192.168.1.1 at port 53.

?

3

I'm not sure if setting 0.0.0.0 only would work, as I can see in the AGH Query Log that OpenWrt uses ::1 and 127.0.0.1 as localhost specifically to connect to downloads.openwrt.org successfully.

I also believe that during the initial configuration wizard, AGH only provides a drop down menu with a limited selection of interfaces. I can't recall what the selection was, but from what I've read it was better to only select 192.168.1.1, as the other option was to listen to all IPs, including wan:

Thanks @mercygroundabyss, also pinging @AlanDias17 as they also picked up on the Wiki guide not including loopback entries and helps others with telling them to edit the yaml file to include them in this topic: [How-To-Updated 2021] Installing AdGuardHome on OpenWrt [Manual and opkg method]

Just adding this too as another user @Chatmandu has also figured it out from this topic: OpenWRT + AdGuard Home - OpenWRT itself cannot resolve DNS, clients can

If anyone has anything to add or clarify for my Wiki edit request, that would be appreciated. I'm not too experienced with this and just want to ensure others have a smooth setup experience with AGH and OpenWrt.

4

It does.

If 0.0.0.0 wasn't an option, it's obviously a no go.

Another option is obviously to tell the router not to use localhost for its own name resolution.

5

That's good to know, thanks for clarifying. Does that mean it will also cover when OpenWrt uses ::1 for IPv6 localhost as well?

If so, then it can mean we only need to either:

  1. Provide instructions to edit the adguardhome.yaml file to change the bind_hosts entry to 0.0.0.0 only, where all DNS activity is directed (both DHCP clients and the OpenWrt router itself), with an optional step to set up Logs and Statistics to ignore *.arpa and *.lan domains in AGH; or

  2. Provide instructions to edit the DNS server OpenWrt router uses via LuCI, as the other option you're suggesting, where we would need to keep in mind that there will be two seperate locations to monitor DNS success, one for OpenWrt/localhost and one for DHCP clients.

6

nope, but it doesn't seem to be an issue.

router trying ::1 is because it's been told to try both v4 and v6 localhost in resolv.conf.
would be interesting to see if 0.0.0.0 was an option in AGH though.

for 2nd option you could provide an upstream DNS, doesn't have to be on router.

7

I think I found that ipv6 DNS was failing without ::1, but it was a while ago.

8

of course, but it seems to work anyway.
but if we're changing the yaml file, we might just as well add two entries, instead of one.

9

I think that might be best, to add 0.0.0.0 and ::1 to the yaml. Is there any reason we aren't using 127.0.0.1 instead? Not too familiar in this area, so was just wondering.

10

0.0.0.0 covers all interfaces, you're replacing two lines with one.

1 Like
11

Ah! Makes perfect sense. Thank you.

I'm just rerunning the AGH install.html now to see what options were provided to me again, to answer your other thought:

1 Like
12

Got it, it's only providing interface options, so the dropdown options are:

  • All interfaces
  • br-lan - 192.168.1.1
  • eth1 - (here would be your public IPv4 WAN address)
  • lo - 127.0.0.1

Interestingly, All interfaces includes the IPv6 ::1 and the router address as well, eg fa1a:c123:1234::1. The full address list added would be:

  • 127.0.0.1
  • 192.168.1.1 (IPv4 router address)
  • x.x.x.x (IPv4 WAN address)
  • ::1
  • fxxx:x123:1234::1 (IPv6 router address)

Seeing the eth1 listed, this does explain why I kept reading in various sources not to leave it on All interfaces due to the IPv4 WAN address being included.

Other than eth1 IPv4 WAN address 'issue' though, leaving it on All interfaces would have meant everything would be working from the get go.

Perhaps it would be easier to instruct the user to leave it on All interfaces, then edit the yaml file to remove the IPv4 WAN address?

13

I agree.

ssh (dropbear) binds all interfaces too, and that's not an issue.

wiki updated.

1 Like
14

When I keep reading/watching others saying something along the lines of "we don't want our router exposed to the internet by opening port 53 up" by including the IPv4 WAN address in this list during AGH setup, it actually doesn't do so?

Thank you very much, really appreciate it. :slightly_smiling_face:

15

you got a firewall in front of the WAN interface for a reason ,)

if you open the port (in the fw) to the outside world it would be, but that would apply to all daemons binding to 0.0.0.0, like ssh.

1 Like
16

Perfect, I had a feeling that was the case!

Thank you for helping me resolve this part of the Wiki, and for helping me understand a little better on how this all works. This should help others in future setups not have to go through a similar journey when OpenWrt suddenly stops connecting to things if following the Setup guide in the Wiki.

17

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.