Unable to use client Ids with "allowed clients"

[alex13lopez]

Hi,

I know I'm probably not understanding well how client ids are supposed to work, but I create a client id let's say "cli1234" and put it in "allowed clients" along with my LAN ip range 192.168.1.0/24.

I then configure the private DNS on my mobile phone like this: cli1234.mysubdomain.duckdns.org but my mobile phone says that it cannot connect to dns.

However if I remove everything from the allowed clients' list I can connect just fine both over TLS and HTTPS.

I have both tried adding the client id to persisted clients and without persisted clients to no avail.

Any ideas what might be happening?

[Charlie284]

Your allowlist entries are the right shape: 192.168.1.0/24 and the bare ID cli1234. They are alternatives, not cumulative requirements. In current code, allowlist mode rejects a request only when both its IP and ClientID checks fail (source). A persistent client entry isn't required for the Allowed clients match; add one only if you also want a friendly name or per-client settings.

For Android Private DNS over TLS, these four parts must line up:

1. In Encryption settings, set Server name to the base hostname mysubdomain.duckdns.org. It must not be blank or set to cli1234.mysubdomain.duckdns.org. AdGuard Home extracts the immediate label before the configured server name as the ClientID (source).
2. cli1234.mysubdomain.duckdns.org must resolve to the AdGuard Home server.
3. The certificate must be valid for both mysubdomain.duckdns.org and *.mysubdomain.duckdns.org, as described in the ClientID guide.
4. Allowed clients contains cli1234, while Android's Private DNS provider hostname contains cli1234.mysubdomain.duckdns.org.

The corresponding YAML should look like this, alongside your existing certificate and key fields:

dns:
  allowed_clients:
    - 192.168.1.0/24
    - cli1234
tls:
  enabled: true
  server_name: mysubdomain.duckdns.org
  port_dns_over_tls: 853

You can check the DNS record with:

dig +short cli1234.mysubdomain.duckdns.org

And inspect the certificate served for that hostname with:

openssl s_client \
  -connect mysubdomain.duckdns.org:853 \
  -servername cli1234.mysubdomain.duckdns.org \
  </dev/null 2>/dev/null |
openssl x509 -noout -ext subjectAltName

The SAN output should cover both the base hostname and its wildcard.

The most likely cause here is an empty or incorrect Server name setting. In that case AdGuard Home sees no ClientID (source). With an empty allowlist the request still works, but after enabling the allowlist the phone's public IP doesn't match 192.168.1.0/24 and the missing ID is refused.

For DoH, use either https://mysubdomain.duckdns.org/dns-query/cli1234 or, with the wildcard certificate, https://cli1234.mysubdomain.duckdns.org/dns-query.

Also check the AdGuard Home version. Current stable is v0.107.78; versions before v0.107.48 had an encrypted-protocol access-control regression (#6890). If everything above already matches, please share the version plus redacted values for dns.allowed_clients, tls.server_name, and the certificate SANs. Don't share the private key.

[alex13lopez]

Hmm then I think I've found out the issue: I have dns.mysubdomain.duckdns.org as server name. I've tried setting mysubdomain.duckdns.org but down im the certificates says it's not valid as my certificate it's with wildcard so it's expecting to have something in front of mysubdomain.

Should I ignore this validation on the UI or regenerate the SSL certificate trying to have both with and without wildcard?

Thank you for your time and your response.

[Charlie284]

I would not ignore the validation. Reissue the certificate with both names in its Subject Alternative Names:

DNS:mysubdomain.duckdns.org
DNS:*.mysubdomain.duckdns.org

A wildcard only covers one label at that position. Therefore *.mysubdomain.duckdns.org covers dns.mysubdomain.duckdns.org and cli1234.mysubdomain.duckdns.org, but it does not cover the bare mysubdomain.duckdns.org.

With the two SANs above, use:

AdGuard Home Server name:       mysubdomain.duckdns.org
Android Private DNS hostname:   cli1234.mysubdomain.duckdns.org
Allowed clients entry:          cli1234

That is the layout described by AdGuard Home's ClientID documentation: the certificate needs to cover both the configured server name and its wildcard.

If you instead keep dns.mysubdomain.duckdns.org as the configured server name, the ClientID hostname becomes cli1234.dns.mysubdomain.duckdns.org, and your existing *.mysubdomain.duckdns.org certificate does not cover that two-label name. You would need a different wildcard, *.dns.mysubdomain.duckdns.org, which is unnecessarily awkward here.

After installing the reissued full chain and key, restart AdGuard Home and rerun the openssl s_client check. Its SAN output should show both entries above. Wildcard issuance normally requires the ACME DNS-01 challenge, so use the DuckDNS DNS challenge support in whichever ACME client you already use.

[alex13lopez]

Okay I was just looking on how to reissue the certificate with both names and I've found out how I'll try again after reissuing and mark as resolved in case it works. Thank you so much for your help.

[alex13lopez]

It does work now. It was the server name issue, thank you so much!

[alex13lopez]

It does work now. It was the server name issue, thank you so much!