Yet Another Pi-Hole (v6) container issues topic

Hi all,

I came from another (wrong) topic where I just discussed my issues. I’ll try to resume them.

ROS 7.20.2 on a RB5009

Already have a perfectly working Pi-Hole (v5) container on an nvme usb huge disk

Was Trying to install the new v6 version and I did anything possible to set all the new parameter according to the documentation.

So I set 3 envs: TZ (as per the v5), DNSMASQ_USER (as per the v5) and the new pwd “FTLCONF_webserver_api_password”

the container runs on a new veth2 (veth1 is used by the v5 container) which is working because I tryied to add another v5 container on it and it’s reachable.

After adding the container, starting it nothing significant come out from the log, but pointing the ip into the browser it simply timeout and can’t even complete the initial configuration.

Is there something that is not specified anywhere that I should do?

Since I tested the new /app support, MikroTik uses the following for PiHole 6 in 7.21rc1:

FTLCONF_dns_listeningMode = all
FTLCONF_webserver_api_password = password

With FTLCONF_dns_listeningMode likely being important, as it defaults to LOCAL (and Pi-Hole docs suggest its ALL not all). See https://docs.pi-hole.net/ftldns/configfile/#listeningmode

IDK Pi-Hole, but my guess is LOCAL will cause DNS to get rejected unless traffic is NAT'ed, and since traffic may not be NAT'ed to Pi-Hole container... it gets rejected by this settings. Anyway it's worth a try since you have been struggling with this one.

Hi, tryied this too, but still with no success.

don’t know if it could be useful to know, but reading the toml file I red:

[webserver.paths]
# Server root on the host
#
# Allowed values are:
# A valid path
webroot = "/var/www/html"

so then I went to look for the www folder into var and there is just a log folder. maybe the issue is that there is no web interface deployed at all?

but how that can be possible? something goes bad during the extraction process while adding the container? (thing I did at least 10 times this week, so in the case it’s not something happening once…)

I don't use PiHole, so flying blind here. But like I said I do see Pi-Hole V6 working in /app. I doubt it a problem with the image, rather differences between V5 and V6 (potentially combined MikroTik containers oddities).

They show a NAT rule to the management port:
/ip firewall nat add action=dst-nat chain=dstnat comment="app pihole redirect to web" dst-address=<router LAN IP like 192.168.88.1> dst-port=8085 protocol=tcp to-addresses=<pihole-container-ip> to-ports=80

which the uses http://routerip:8085 to access pi-hole admin UI.

My thought is perhaps Pi-Hole V6 only allows connection to admin web from it’s LAN (like the dns_listeningMode = LOCAL)… So if NAT it, you’re LAN IP be from container’s subnet.

tryied it, anyway I have the veth on the same subnet as the router (didn’t used vlan), but the nat rule doesn’t change the result.

PS: I thought I could see the var folder from the SMB share, but I see it from the shell. doing a curl from the container shell to the admin page reply 302 (found), but can’t access from devices in the same lan

Please paste your veth and bridge configuration here. Have you created a bridge for each of the veth interfaces?

Isolated Containers example:

You can also try /ip/services/print to see if the Pi-Hole admin listen port shows up.

Does DNS work to Pi-Hole, so it's just web?

Hi,

as far as I know it’s not mandatory to create a bridge for each veth, nor to use vlans or different subnets.

a couple days ago I created 2 pihole v5 containers, using 2 veths set under the same bridge. it’s just pihole v6 having issues with the same exact configuration.

/interface veth
add address=192.168.1.54/24 comment=Pi-Hole5 dhcp=no gateway=192.168.1.1 mac-address=xxx name=veth1
add address=192.168.1.55/24 comment=Pi-Hole6 dhcp=no gateway=192.168.1.1 mac-address=yyy name=veth2

/interface bridge port
add bridge=bridge comment=Pi-Hole5-Mikrotik edge=yes interface=veth1
add bridge=bridge comment=Pi-Hole6-Mikrotik edge=yes interface=veth2

don’t know if it works, because I haven’t yet set it as a DNS into the network (it’s unconfigured and would cause many issues), I suspect it would work.

this is the services print:

NAME CONTAINER PORT PROTO CERTIFICATE VRF MAX-SESSIONS LOCAL REMOTE

28 D pihole-FTL Pi-Hole5 53 tcp
29 D pihole-FTL Pi-Hole5 53 udp
30 D lighttpd Pi-Hole5 80 tcp
31 D c lighttpd Pi-Hole5 80 tcp 192.168.1.54 192.168.1.6:50305
32 D c lighttpd Pi-Hole5 80 tcp 192.168.1.54 192.168.1.6:50314
33 D c lighttpd Pi-Hole5 80 tcp 192.168.1.54 192.168.1.6:50315
34 D Pi-Hole5 445 tcp
35 D pihole-FTL Pi-Hole5 4711 tcp
36 D pihole-FTL Pi-Hole6 53 tcp
37 D pihole-FTL Pi-Hole6 53 udp
38 D pihole-FTL Pi-Hole6 80 tcp
39 D pihole-FTL Pi-Hole6 443 tcp
40 D Pi-Hole6 445 tcp

edit: the dns is working anyway. an nslookup from the shell specifing the dns server address answer correctly

I have suspicious feeling that this could be related to browser protocol upgrading, try to open the admin page from your phone

don’t know if about protocols something could change between chrome for windows and chrome for android, but it doesn’t open neither on the phone.

By the way, is this something affecting only Pi-Hole version6 and not 5?

Do you have an admin-mac set on your bridge? Otherwise it's possible the bridge's auto-mac support is picking up the VETH as it's MAC and causing trouble.

Maybe post your configuration from :export file=config.rsc since it's hard to guess. I did see Pi-Hole 6 web UI on 7.21rc1 with CHR... why I think it's something config-related.

I can answer to the MAC question, no, they are differents. the bridge took one of the eth MAC, while the VETHs have manually specified MACs.

before posting the config, I think I can give an interesting information.

Because @Bodrie said to use another browser, I firstly tried Chrome on my android phone without success, but then realized I have a raspberry Pie with Chromium on it and the news is that I can reach the web interface from there (but from no other device I own).

So now I think we can concentrate the effort on the browser.

what do you think?

I agree signs are pointing to Pi-Hole being picky on browser. I used latest Safari on Mac when I tested the /app version.

FWIW, you can test using Pi-Hole 6 DNS on router using:

:put [:resolve server=192.168.1.55 www.google.com]

which be the final piece of evidence point to the browser pickiness....

yes, it works, I already did succesfully an nslookup from my pc the other day.

but now what can I do to resolve the issue? except installing another browser, thing I’d prefer to avoid.

I think you'd might want to be looking the Pi-Hole forums... this seems like should be another ENV variable to allow "older"/"insecure"/whatever browsers.

Maybe someone else here who run Pi-Hole 6 knows...

Maybe, try another port for the Pi-Hole management, so it does not overlap with RouterOS's port just to see but that's not how port listening works.

it seems something related to this article https://chromestatus.com/feature/5152728072060928

but I think too there’s something different in v6 respect to v5 that is still working.

It will remain a mistery to me how the pihole6 instance installed into that raspberry is visible.

I’m going to suspect that chrome is tagging as “local network” the subnet 192.168.1.x (the one I’m using) and not the subnet 192.168.9.x (the one where the raspberry is)

That is browser on different device where it works? If yes, did you check if resolving is working over Pi-hole DNS service from device where you can’t access admin, like with dig @192.168.1.55 www.google.com? Maybe connections are filtered or not routed correctly because of ROS config. Also check that from browser where it works and where is not that admin is accessed with same HTTP protocol (HTTP vs HTTPS) and same IP protocol version (IPv4 vs IPv6).

I can access Pi-hole 6 admin (HTTP and HTTPS over IPv4) from any installed browsers on any system I have: Mac (Safari, FF, Chrome, Vivaldi), Win (FF, Chrome, Vivaldi), iOS (Safari, FF, Chrome) and Android (FF, Chrome, Brave). If you are certain that is actually browser issue, then it can be because some added extension or is some non default browser configuration applied, like for eg. config which is allowing only HTTPS and you are trying to access admin over HTTP.

urls are resolved correctly from that pihole instance on the devices that can’t access the web interface

no differences in protocols, just http anywhere

the few extensions I use have the IP whitelisted and anyway on the phone there are no extensions.

same issue on edge (I never use it, no configurations, no extensions) but it’s on v.143 too

If what I red here and there is the same issue I have, it’s something related to a setting called “NetworkServiceSandbox” that was introduced in 142 on chromium based browser (on the raspberry is stuck at 126 and there it works).

still can’t find a solution to really disable it to understand if this is my issue

IDK, working for me with latest Chrome version…