AdGuard web-interface :3000 gone / unresponsive ... fixed. ✅

[Andreas.Wien]

It happened with one of the recent updates, and I didn't check the problem with AdGuards web UI.
Its DNS functionality works still fine, but the web-interface doesnt respond anymore.

though the port is listening, with the right process:

Code: [Select]

root@OPNsense:~ # sockstat -l -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     AdGuardHom 82770 19 tcp46  *:3000                *:*

and the AdGuard .log looks fine too:

Code: [Select]

2023/01/03 03:54:39.034836 [info] AdGuard Home is available at the following addresses:
2023/01/03 03:54:39.035174 [info] Go to http://192.168.0.1:3000
anyone else with the same experience?
howto resolve this?
help's appreciated!

[Andreas.Wien]

hey community support! anyone (100+:) reading this?!

[cookiemonster]

Assuming you are using mimigmail's plugin for AdGuard, why not restart the service?
Please note that "web-interface doesn't respond anymore" is not descriptive enough and any forum would expect to get what diagnostics have been done.
 wget http://192.168.5.1:8080 for instance should give you a 200 Ok response, does it? Or use the web browser developer tool to see what happens.

[Andreas.Wien]

yes, it is the one:

Code: [Select]

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]

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]

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]

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?

[Koloa]

Just a thought, but...could it be that you're able to get to the OPNsense web service due to the anti-lockout firewall rules, but, whatever system you're trying to connect to AdGuard's admin interface from does not have an appropriate firewall rule to permit the traffic?

Since you're seeing the socket is open on the OPNsense box itself, presumably if you tried the wget/curl/telnet ON the OPNSense machine TO the OPNsense machine, it would work?

It wasn't clear from your earlier posts if you were trying the wget from the local OPNsense system or not.  The sockstat was clearly the OPNsense system.

Perhaps create a custom firewall rule that logs traffic to 192.168.0.1:3000 and try to trace things from there.

[Andreas.Wien]

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.

[Andreas.Wien]

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

Code: [Select]

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!

[Andreas.Wien]

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

Code: [Select]

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 ✅

[cookiemonster]

I run it too. I don't have any specific firewall rules for my AdGuard port UI on port 8080. The default "allow all to LAN" rule takes care of it. Maybe that rule was changed?
If it was working before when you didn't have this rule in place, the problem was/is somewhere else.

[Andreas.Wien]

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?