Quick Hits: Three Smaller AdGuard Findings

Not every finding from standing up internal DNS needed a full investigation. These three are each a single clean cause, worth keeping on record even though none of them took long to resolve.

The setup wizard rejects its own just-set password

Set an admin username and password through AdGuard Home's first-run wizard at :3000, then immediately got "incorrect password" on the very next login attempt — despite confirming the credentials were typed correctly. Before assuming user error, checked whether this was a known behavior rather than guessing at a cause: multiple independent, unrelated reports describe the exact same symptom, including at least one confirmed via a password manager's autofill on both the setup and the failed login, ruling out a typo. A second login attempt with the identical credentials succeeded immediately. This appears to be a genuine timing quirk in AdGuard Home's first-login flow, not anything wrong with the install. Worth knowing before assuming a fresh install is broken: try the same credentials again before touching the config.

Two more UFW timeouts, same shape as before

The web UI (port 3000) and the actual DNS service (port 53, both TCP and UDP) both timed out from every host except the DNS server itself — the same "works locally, times out remotely" signature already diagnosed for the K3s VXLAN and DVWA NodePort bugs earlier in this build. Confirmed the service was genuinely listening and correctly bound in both cases (curl -sI http://localhost:3000, dig @127.0.0.1 <hostname>) before checking UFW — both times, the rule genuinely didn't exist yet, since nothing in the AdGuard install itself touches the firewall. Fixed by adding both ports to the host's ufw_allowed_ports list and re-running the play.

Worth naming directly: this is now the third distinct service in this build to hit this exact failure shape. A missing UFW rule on a fresh host isn't a fluke at this point — it's the default state, and checking for it should be step one whenever a brand-new service is unreachable from anywhere but itself.

Testing the wrong protocol entirely

Tried to verify port 53 was actually reachable from another host using chronyc -h <dns-ip> tracking — and got "cannot talk to daemon." That error wasn't a sign anything was broken; it was the wrong tool for the question. chronyc -h tests chrony's separate management protocol (port 323, disabled for remote hosts by default, for good reason), not the actual NTP service (port 123) the fix was meant to verify. Opening remote management access wasn't the fix, either — it would have been a real, unnecessary security exposure just to make a test pass. Switched to ntpdate -q <ip>, which speaks the real protocol, and got a clean, correct answer. Worth remembering: a tool returning an error doesn't always mean the thing under test is broken — sometimes it means the tool itself was never asking the right question.