Different ports for DOH and HTTPS web admin interface

[280blocker]

If DoH is enabled, admin interface and DoH can be accessed by same port. I want to publish DoH open and restrict access to admin interface by the port number.

Is it possible to use different ports for DoH and admin interface?

[ameshkov]

@280blocker thank you!

I've marked this issue as a feature request. This is doable of course, but not as easy as we'd like to.

Meanwhile, the temporary solution would be to use a simple nginx proxy on a different port.

[ibksturm]

hi @280blocker

lock at https://github.com/AdguardTeam/AdGuardHome/issues/662

and on my gitrepo https://github.com/ibksturm/dnscrypt-switzerland

[Onepamopa]

This should be high priority ...

[ameshkov]

Merging https://github.com/AdguardTeam/AdGuardHome/issues/2548 to this task as they seem to be alike.

So what should be done:

1. Separate configuration for the web admin interface and for DOH/DOT
2. Allow them to run on different network interfaces/ports
3. Allow them to run on the same interface/port, but to have different domain names
4. Allow configuring different HTTPS configuration for both of them

[timkgh]

At least for the admin UI, it should not error on self signed certificates. E.g. I use the excellent mkcert to have a "home" CA that I import in my browsers, but AGH does not like it:

Certificate chain is invalid
Your certificate does not verify: x509: certificate signed by unknown authority

[ameshkov]

@timkgh I don't think this is a suitable issue for discussing this. However, there's an easy way to solve that issue, make sure your self-signed cert is added to trusted certs on the server.

[timkgh]

+1 to being able to limit the admin UI to a specific VLAN/interface.

[Habetdin]

Quoting #3692 here just to keep additional information in place:

Expected Behavior

DNS over HTTPS to listen the same IPs as the regular DNS, DNS over TLS and DNS over QUIC, etc

Actual Behavior

DNS over HTTPS listens only on the Web interface IP address

Additional Information

AdGuardHome.yaml contains next configuration (I've replaced the real IPs with <stubs>:

bind_host: <first.ip.address>
bind_port: 80
dns:
  bind_hosts:
  - <second.ip.address>
  - <third.ip.address>
tls:
  force_https: false
  port_https: 443
  port_dns_over_tls: 853
  port_dns_over_quic: 784

The ss shows the next network interfaces state:

# HTTP Web interface
tcp    LISTEN  0       65535    <first.ip.address>:80

# HTTPS Web interface and/or DoH
tcp    LISTEN  0       65535    <first.ip.address>:443

# Regular DNS
tcp    LISTEN  0       65535   <second.ip.address>:53
udp    UNCONN  0       0       <second.ip.address>:53
tcp    LISTEN  0       65535    <third.ip.address>:53
udp    UNCONN  0       0        <third.ip.address>:53

# DoT
tcp    LISTEN  0       65535   <second.ip.address>:853
tcp    LISTEN  0       65535    <third.ip.address>:853

# DoQ
udp    UNCONN  0       0       <second.ip.address>:784
udp    UNCONN  0       0        <third.ip.address>:784

As seen in this output, regular DNS, DNS over TLS and DNS over QUIC all do listen on dns->bind_hosts IPs, while DNS over HTTPS is only available on the IP of Web interface.

I expect DNS over HTTPS to follow other DNS services' behavior and listen on <second.ip.address> and <third.ip.address>, but it does not.

I believe that web admin interface should have its parameters separated from the DoH so there wouldn't be such problems like explained in this & related issues.

[Habetdin]

@ameshkov is there any milestone assigned to this issue since 2019?