Messages

I was under the impression that port 853 would serve for adguard>unbound DNS requests. But firstly unbound did bind to :53 anyway (thereby blocking adguard from starting) and then :853 is actually DoT not DNS - and one needs both.

Restricting unbound to localhost solved the issue.

IMHO that's a pretty standard configuration of AdGuard, so I hoped it would work more out of the box. But maybe it's up to AdGuard to improve the documentation and setup experience?

So the reason for my post was just documentation.

the issue here was to configure unbound to bind to localhost:53 only.
can this be done via GUI, or /usr/local/etc/unbound.opnsense.d/10-localbind.conf only?

yes, initially the problem that prevented AdGuard from start was that it and unbound would like to bind to 192.168.0.1:53 which is, as you've rightly put it, impossible.

however; when AdGuard binds to 192.168.0.1:53 and unbound binds to 127.0.0.1:53 these are two distinct interfaces, so the same port is usable for 2 services.
and localhost/127.0.0.1 is sufficient for a cascaded unbound that is only invoked from the local AdGuard. Whereas the LAN/192.168.0.1:53 is visible for all LAN clients.

your solution with nonstandard yet distict portnumbers certainly works, but it's actually not necessary, as unbound @ 127.0.0.1:53 (insteadof 65353) wouldnt collide with AdGuards LAN:53.

FeatureRequest; I wish all these services (unbound in particular) had an option to specify interface AND port bindings.

[AdGuard]

I experienced the issue of AdGuard being unable to startup, as unbound already bound to Port 53 (LAN)
The motivation is that AdGuard serves all local DNS-requests, including for .localdomain, but those are forwarded to unbound.

So this is my cfg for the AdGuard Settings > DNS Settings > Upstream DNS servers

Code Select Expand

https://dns.quad9.net/dns-query
https://dns.google/dns-query
https://dns.cloudflare.com/dns-query
[/localdomain/]127.0.0.1:53
The necessary interface:port-binding that works4me is this:

Code Select Expand

root@OPNsense:~ # sockstat -4 -l | grep :53
root     AdGuardHom 69756 76  udp4   192.168.0.1:53        *:*
unbound  unbound     3107 10  tcp4   127.0.0.1:53          *:*
[...]
root@OPNsense:~ # sockstat -4 -l | grep :853
unbound  unbound     3107 5   tcp4   127.0.0.1:853         *:*
unbound  unbound     3107 7   tcp4   192.168.0.1:853       *:*
[...]
however; in order to achieve this, there is no way in the GUI to specify these port-binding requirements.
I had to override it like this:

Code Select Expand

root@OPNsense:/usr/local/etc/unbound.opnsense.d # cat 10-localbind.conf
server:
    interface-automatic: no
    interface: 127.0.0.1@53
    interface: 127.0.0.1@853
The only sideeffect is: a GUI Banner for unbound:

Code Select Expand

The configuration contains manual overwrites, these may interfere with the settings configured here.
Furthermore it was necessary to start unbound like this:

Code Select Expand

root@OPNsense:/usr/local/etc/rc.syshook.d/start # cat 50-unbound
#!/bin/sh
# Delay + Start Unbound DNS service if not already running
sleep 3
if ! service unbound onestatus >/dev/null 2>&1; then
  logger -t unbound "Starting Unbound (delayed boot fix)..."
  service unbound start
fi
I wonder ... did I miss something, or is this AdGuard integration so unusual that it's not readily supported in OPNsense's GUI?
Is there a 'clean' way to achieve the above?

System Gateways Gateway.edit no-change .save .apply ... worked 4 me ✅
tnx!

seems like the same issue as in https://forum.opnsense.org/index.php?topic=32350
I just had to redo the +x, as it seems to be broken with every FW-update.

is this a known issue?
can it be fixed?

in /usr/local/etc/rc.d opnarp was the only one with flags -rw-r--r--
changed it to chmod 755 opnarp -rwxr-xr-x
probably this fixed it.

of course alot to see in the console upon boot ;) but nothing specific abt opnarp catched my eye.

maybe connected to this issue: in the GUI at "System: Diagnostics: Services" the "opnarp daemon" is stopped and cannot be started.

After reboot the OPN-Arp service doesnt autostart, though Enabled[X].
I have to manually start it every time after reboot.

Is there a way to fix the functionality of "enable", or a shell way to make it autostart after reboot?

maybe similar to this issue: https://forum.opnsense.org/index.php?topic=31697

just to make sure;
is "allow all to LAN" an auto-generated rule from an option in some menu?
or a default configuration rule I aparently deleted?

[works]

Oh cr..! now this port forwarding rule works:

Code Select Expand

Source Destination NAT
Interface Proto Address Ports Address Ports IP Ports Description
LAN TCP * * This Firewall 3000 (HBCI) 127.0.0.1 3000 (HBCI) access AdGuard web-UI

can't believe I'm the only one with this problem / configuration!
would be worthy ofa tiny mention in the releasenotes!

.works4me ✅

[NAT.Port-Forward]

With NAT.Port-Forward it gets even more interesting:

Code Select Expand


Interface Proto Address Ports Address Ports IP Ports Description
WAN TCP * * WAN address 3000 (HBCI) 192.168.0.1 3000 (HBCI) allow access 2 ADguard    
LAN TCP * * LAN address 3000 (HBCI) 192.168.0.1 3000 (HBCI) allow access 2 ADguard

the 1st one works: I see the ADguard-login from outside.
the 2nd one doesnt work: LAN-devices still see nothing!

[ON]

thank you for the hints! there are new findings:

• the from-LAN-access to OPNsense:3000 is shown as PASSed in the FW.log.live
• the wget ON OPNsense ... GETs a RESPONSE!

Now I thought abt the antilockout rule too (which is a generated one).
Though I cannot create an own LAN-rule for dst-port 3000 ... port-fields are not editable "🛇",
a general LAN-rule "from:LAN-net to:This-Firewall" with "Gateway:default" or alternatively "127.0.0.1" has seemingly no effect.

[soo ... where to dig next?]

yes, it is the one:

Code Select Expand

Version Size Repository Comment
os-adguardhome-maxit (installed) 1.8 34.7MiB mimugmail AdGuardHome

unresponsive is meant in the sense that it doesnt respond, not with http 200 or otherwise:

Code Select Expand

wget http://192.168.0.1:3000
--2023-01-06 23:19:26--  http://192.168.0.1:3000/
Connecting to 192.168.0.1:3000... failed: Connection timed out.
Retrying.

whereas the OPNsense webservice responds fine:

Code Select Expand

wget --no-check-certificate https://192.168.0.1
--2023-01-06 23:29:34--  https://192.168.0.1/
Connecting to 192.168.0.1:443... connected.
WARNING: The certificate of '192.168.0.1' is not trusted.
WARNING: The certificate of '192.168.0.1' doesn't have a known issuer.
The certificate's owner does not match hostname '192.168.0.1'
HTTP request sent, awaiting response... 200 OK
Length: 2646 (2.6K) [text/html]


just to make sure, the DNService of ADguard works:

Code Select Expand

dig 8.8.8.8

; <<>> DiG 9.16.33-Debian <<>> 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37620
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;8.8.8.8.                       IN      A

;; AUTHORITY SECTION:
.                       3600    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2023010601 1800 900 604800 86400

;; Query time: 28 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Jan 06 23:34:10 CET 2023
;; MSG SIZE  rcvd: 111


soo ... where to dig next?