AdGuardHome listens only on IPv6 on an IPv4-only machine, causing the service to fail

[ChenYun10]

System Version:
Debian11
Processor architecture:
amd64
Software version:
0.107.53
Problem Description:
During use, AdGuardHome was found to only listen to IPv6 and not to IPv4 connections when the environment is normal. As a result, the configured DoH and DoT cannot connect to the server at all. I have IPv6 at home, but I want to use IPv4 in my home area network Unencrypted DNS (udp53) really can't work.
Please answer, thank you.

[MNLierman]

Same. Did you find a solution? I guess if I find one, I'll try to remember to comment back here. It's odd that you had this issue recently, I wonder if there was a code change in AdGuardHome that broke some setups. My setup is a Docker container and I've removed and redeployed the container for the last 2 hours trying to figure this damn crap out and I'm so fed up. Honestly, I might just try PiHole and call it a day. I have no F-ing clue why AdGuard is acting like this.

→ My Actual Solution

[ChenYun10]

I had to reload, and I had no other way

[ChenYun10]

And I've had this kind of issue with multiple versions I've used before

[MNLierman]

I actually found the better solution, I'm posting it now.

[ChenYun10]

OK, thank you
Actually, I use this because I'm in China, but some ISPs in China have too much DNS pollution and hijacking😂

[MNLierman]

MY SOLUTION AND ADVENTURE IN PORT BINDING
(Proudly written without the help of AI – yes, I said without.)

I figured out what was happening for mine. Just for anyone who finds this issue.

This happened on my office network, at the end I talk about extra info I did for my home network not specifically related to this AdGuardHome (AGH) issue.

Problem: AdGuardHome Docker container was not binding to IPv4 address and instead only binding to IPv6. Essentially, without giving any error, it was not binding to 0.0.0.0 and netstat -tulpn | grep 53 on AdGuardHome shows only :::53 and that was it.

Discovery: I had the docker container for adguard on a network with other containers so that I could manage things in that regard. While I wasn't initially seeing an error message about being unable to bind, since IPv4 was missing, I assumed it was happening, just with a silent continue. I believe that AGH is programmed with a silent continue function. If it cannot bind to a certain adapter or address, and you have selected “Bind All” then it will not complain.

Solution: From that assumption that AGH is silently unable to bind and continuing without error. Using netstat -tulpn | grep 53 (or other port / app name you want or search for), I started looking at each container on the same network as AGH, and found a container that was set to scan and attempt to bind to everything within access, an aggressive feature I didn't need in my circumstance, as I only needed that particular app to bind locally on lo 127.0.0.1.

Next, that lead me to check the host computer, and on the host computer I found the same thing. Now I don't have my notes in front of me at the moment, but I believe it was dnsmasq on the host computer, which was set to also bind to everything possible, which includes the local bridge adapter for the AGH container. I changed dnsmasq settings to only bind to lo and 127.0.0.1. After that, I changed the config file for AGH to explicitly bind to 0.0.0.0, 127.0.0.1, and 172.x.x.x (the bridge adapter).

Finally, I found this last piece was important too, I found that if containers on a specific network moved around they would change IPs. I thought that Docker would set/prefer static IPs and try to keep containers on the same IP. Apparently not. So I explicitly set, using portainer, the IP address field for both ipv4 and IPv6 to use the specific IP that I wanted so that it containers moved around, Docker was restarted, or containers were turned off and on, that the IPs didn't jump around. This resolved my issue completely.

Conclusion, I believe redeploying AGH may fix other people's problems only if it's competitively binding. Ie, it's first to bind to an adapter or IP, and if the host is restarted, it may lose in that binding competition. The proper way is check for other things that are binding unnecessarily, since AGH is set to automatically continue on error. Use netstat -tulpn | grep 53(or other port you want to check for). I found other containers/apps that were unnecessarily binding to things I didn't need them to bind. You can also create a special network just for AGH to use. I called mine app_net_agh1 since I am now prepping a second AGH container. Then, you can specify in the Docker run command, Docker file, or in Portainer the IP you want AGH to have. Finally I also edited the AGH config yaml file and explicitly specified the addresses to attempt to bind to.

HOME NETWORK
Extra Info: On my home network, I decided I wanted to create a macvlan for AGH, so I did that, but found the host cannot contact that AGH IP, never found why, I think it's a Docker bug (even checked IPTables). The easy fix there is to tell the host to use the IP of the bridge adapter (second network) that you also attach to AGH. You can have multiple networks attached to containers. So while the 10.5.5.x IP on my home network that AGH picked up was unable to be pinged by the host, it's local bridge IP can be pinged so I set that IP in the hosts /etc/resolve.conf.

Now it's also important to know that many installations of Ubuntu and Debian now move that resolv.conf responsibility to /etc/systemd/network.conf (I think that's the one). On there you can specify a main DNS and a fallbackdns=. I put fallback to something else like NextDNS so if the host couldn't contact the AGH container, it would fallback its DNS to NextDNS and not lose internet connectivity, that way it could still resolve the internet world and I could still access it remotely if I had to.

[ChenYun10]

Thank you