AdGuard Home's DNS-over-QUIC server functionality fails to make itself available on LAN IPs #3465
Comments
|
@DandelionSprout just in case, are you on the latest nightly of AG for Android? AGH has a newer QUIC version, higher than the current stable version of AG supports. |
|
From what I can tell, yes: v4.0 nightly 22. |
|
Hm, that's strange then. Could you please enable debug log in AG for Android/Win and see if it starts printing additional info on the error? |
|
AdGuard for Android debug log (Looks similar to the non-debug log in my eyes): adguard.log AdGuard for Windows 7.7 nightly 13 verbose service-log (Also looks similar to me, sadly; also includes info on an unrelated but severe SSL certificate installation error): |
|
Tbh, I think the only viable way to troubleshoot this now is to use Wireshark on your Windows PC AND tcpdump on the AGH server and take a look at actual UDP packets on both sides. |
|
I'm on the case. Full Wireshark dump (Remove the .txt suffix before loading it; also note that it's 25 MB): Wireshark dump for AdGuard QUIC problems.pcapng.txt |
|
The issue is that your particular routing situation interferes with QUIC's address validation mechanism. Probably, what's happening is that the first packet from your client to AGH server goes through NAT and arrives at AGH server as if it came from the router. After that, your router starts redirecting packets to AGH server transparently, so AGH server sees packets as if they are coming from the client directly, not the router. This breaks QUIC's address validation mechanism:
It would be interesting to see a Wireshark capture from your AGH machine as well, to better understand what's going on. |
|
Fedora claims to have an aarch64 version of Wireshark ready for download, so I'll see if I can try to install and run it sometime tonight. |
|
You could also try |
|
Yogadns Dnscrypt is simple. |
|
Okay, I've now run Wireshark on my server. The output doesn't make all that much more sense to me (192.168.1.130 is my Android phone): Full log: Wireshark Raspberry Pi AGH server capture.zip (31 MB when it's unpacked) I do however notice one aspect: There are no captured queries at all from my Windows PC (192.168.1.188). |
|
This seems to confirm the above hypothesis: the first initial packet comes from To me this looks like some seriously broken router configuration :) I've tried to reproduce this on my equipment, and my router correctly forwards the packets from the internal interface to the external one, then does masquerading, and then finally DNAT. For example this is what my AGH server sees when someone from the internal network tries accessing it via Here are some of the possible solutions:
|
|
My router is an ASUS RT-AC68U. It's becoming pretty old (2013 model), although it has almost all of the functions of more recent ASUS routers. I've telnet-ed into it on one previous occasion, but it's difficult to maneuver in. As for the two suggestions, it should be decently possible for me to look into those various re-routing methods within 48 hours, possibly also including the Linux server's /etc/hosts file. |
|
After 1½ hours, I've found out the underlying reason for this problem, which in turn lacks a solution: The AdGuard Home alpha version (v0.107.0-a.136+550b1798) is lying about listening to port 48582 on LAN: This can be confirmed when I telnet that port, which gives a connection error. |
|
@DandelionSprout QUIC works over UDP and telnet tries to connect using TCP.
|
|
Ah, okay. Now I see it. So now I'm in a bit of a problem. I genuinely can't figure out what the problem is, after trying some 60 different things, and I've had a fever for 4 days now on top of that. |
|
What about just resolving your domain to a private address from the private network? That would solve your routing issues.
|
|
Trying steps 3 and 4 while skipping steps 1 and 2, through I guess I'll have to try to follow steps 1 and 2 as well. Update 19:37 UTC: Turns out that my ASUS router is unable to use a LAN AGH server as both of its IPv4 DNS servers, as it'll for some reason cut the internet connection. Additionally, trying to use two |
|
I was at least finally able to find the router's netstat table, as was requested: |
|
Regarding
, if your AGH server is configured to use a non-plain upstream, and it gets it's DNS settings from DHCP, too, this would lead to an infinite loop as AGH would try to bootstrap it's upstream using itself :) Just configure your AGH to use any public DNS of your choosing instead of those from DHCP. |
ameshkov
added
question
and removed
waiting for data
|
Closing this since this is not a bug |
Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.
Prerequisites
Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.
Issue Details
Expected Behavior
AGH's DNS-over-QUIC server can be accessed from LAN home devices.
Actual Behavior
Okay, so I had for some weeks thought that my connection problems to
quic:https://dandelionsprout.asuscomm.com:48582were the result of failing to scan IPv4 addresses on IPv6-able connections. That may or may not have been the case, but now the problem has either changed in nature, or I was incorrect to begin with; since further testing tonight, led me to the conclusion that it's a problem with LAN connections instead:(Easiest to reproduce with AdGuard for Android, as steps 5-7 hinge on a phone connection.)
Screenshots
Screenshot:
N/A at the time of writing.
Additional Information
Successor to AdguardTeam/AdguardForAndroid#3927 and AdguardTeam/AdguardForWindows#3878
AdGuard for Android log: adguard.log — Highlight sequence:
AdGuard for Windows log: service_18-08-2021-20_36_13.647-2021-08-18.log — Highlight sequence:
Notably, the errors shown in those logs, differ from those that were in the predecessor issue reports.
The text was updated successfully, but these errors were encountered: