last info before going to sleep.
disconnected the phone (the one that cannot reach pihole via chrome browser) from the wifi, connected to the OpenVPN server on the router (192.168.2.x subnet) and now can access the web interface 
actually i can access it from outside 192.168.1.x
As I suspected, you have ROS configuration issues… It was suspicious to me from beginning when mentioned that you needed to retry pulling image many times to install container, maybe not related to admin access issue and it was bad internet connection, still you need to check ROS configuration regarding this…
Hi,
I never excluded 100% the possibility to have something wrong in the ROS configuration, but have to admit that can’t really imagine how a specific config can make pihole v6 inaccessible on the same veth where a pihole v5 works (some days ago I tested 2 pihole v5 containers and the one on veth2 was reachable). Not to mention the fact that I would have understood if it was unreachable from the VPNs, but not the opposite.
Anyway, apart from attaching the config file (I should have removed any sensible information), just want to explain the basic structure of my network.
I have a RB5009 acting as arouter (192.168.1.0/24) and a CRS309 + cAPax as 10gbit switch and access point.
The RB5009 has a usb nvme disk with a working Pihole v5 container (on veth1) and a non working web interface Pihole v6 container (on veth2).
The RB5009 has an OpenVPN server ((192.168.2.0/24)) and used wireguard to set a site-to-site VPN with a hAPax LTE in another house (192.168.9.0/24). In this house there’s a raspberry with installed Pihole v6 (smoothly working).
Because each device from the 3 subnets is visible to each other, I’ve assigned to all of them the 2 DNS (the container v5 and the raspberry v6) so that if one network crash or one dns crash, there’s always a backup.
What’s happening is that no devices from the 192.168.1.0/24 subnet can reach the webserver (port 80 or 443) of the pihole on veth2, but can use its DNS service on port 53.
Devices from the subnets 192.168.2.0/24 and 192.168.9.0/24 can reach the webserver of the pihole on veth2
config.rsc (16.1 KB)
PS: the issues I had pulling the container images were due to a list of blocked addresses I have in the firewall (empirically collected during the years observing what tryied to connect to the Ovpn server).
Becuse some IPs’ families are more abused than others, I sometimes block entire subnet (such as 3.0.0.0/8)…rude, but working…and sometimes too much. I disabled all that rules to be able to pull the images smootly and anyway I’m keeping them disable for now to troubleshoting the issue I have…so I also removed them from the config file to keep it slim
I will try to review config when I find time, you mentioned other network devices (CRS309 + cAPax) there is possibility that connection cannot be established because of them (also because some ROS config), while OpenVPN server is running on same device where container is running and therefore connection is not established through other devices which potentially can cause issue. Make sure that other devices config doesn’t cause this issue, eg. if you have some firewall filter rules check if some rule is dropping packets and packet count is rising on it when trying to establish connection, same thing check on main router to pinpoint rule which is causing issue. You can exclude other devices or if is due router config related to them if you connect computer directly over wire to router and check how is working then.
CRS and AP are pratically dummy switches, empty pages for firewall or nat rules.
I tested 3 devices, each of them connected to one of the 3 network devices.
Already checked packets number of drop rules not growing.
I’m totally in the dark 
I’ll wait patiently your review 
thanks
I edited above post with - did you check when you are directly connected to router over wire?
my last test was to use a PC connected directly to the router (while my main one goes trough the CRS). still no luck
edit: don’t know if this can help
curl -i --verbose http://192.168.1.55/admin/
GET /admin/ HTTP/1.1
Host: 192.168.1.55
User-Agent: curl/8.13.0
Accept: /
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
Request completely sent off
< Location: /admin/login
Location: /admin/login
< Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
< Expires: 0
Expires: 0
< Pragma: no-cache
Pragma: no-cache
< X-DNS-Prefetch-Control: off
X-DNS-Prefetch-Control: off
< Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
< X-Frame-Options: DENY
X-Frame-Options: DENY
< X-XSS-Protection: 0
X-XSS-Protection: 0
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: strict-origin-when-cross-origin
< Access-Control-Allow-Headers: *
Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: *
Access-Control-Allow-Methods: *
< Content-Length: 0
Content-Length: 0
< Date: Thu, 18 Dec 2025 19:14:23 GMT
Date: Thu, 18 Dec 2025 19:14:23 GMT
< Connection: keep-alive
Connection: keep-alive
<
Connection #0 to host 192.168.1.55 left intact
One more check 
Do you have some (application) firewall on OS where browser is running which can block connection? For eg. I’m using LuLu on Mac to filter outgoing connections from OS which can cause such issue if is not properly configured.
Edit: never mind, your connection is not blocked by router , at least not for curl, which means issue is due to OS or browser if request using curl is performed on same device. Assuming it is, curl output have redirect HTTP response (302) to login page, Pi-hole redirects to it when there is no valid login session. Why your browser is not redirecting to correct location (/admin/login) could be due to browser config/extension, check if actually connection is established from browser in Developer tools under Network tab, there should request record where you can see its request/response payload, also in Console tab there can be JS errors if something is blocking/filtering JS, etc… Try to access admin login page with http://192.168.1.55/admin/login to see if works.
zero firewall or antivirus (shouldn’t say this on the internet, ah ah!).
On Chrome the network tab shows, as the curl does, the redirect (302) to login (or nothing if pointing directly to http://192.168.1.55/admin/login) and after minutes, ERR_CONNECTION_RESET.
Console tab completely empty.
booted, from a PC connected to the CRS309, an Ubuntu 25.10 Live and the web gui worked on the preinstalled firefox v.143.
trying firefox v.146 on windows on the same pc doesn’t work
that’s funny
It does, http response header → Location: /admin/login, redirect location is relative path here…
What happens if you directly access Pi-hole login page with url http://192.168.1.55/admin/login? What network tab shows in Chrome for it? Also try it in curl.
network tab shows nothing (just “login pending”, then it goes in timeout and shows ERR_CONNECTION_RESET)
curl -i --verbose http://192.168.1.55/admin/login
GET /admin/login HTTP/1.1
Host: 192.168.1.55
User-Agent: curl/8.13.0
Accept: /
Curl HTTP response status (200 OK) seem to be valid, check also if full HTML body is returned from login page (if is not truncated). If body response using curl is ok, something is blocking request from browser, browser itself by config or extension (ERR_CONNECTION_RESET should not be CORS blocking) or OS (most likely if other browsers have same issue) by some application firewall or AV. Don’t have idea what else it can be, it doesn’t seems to be network issue or Pi-hole config if curl returns all ok.
shouldn’t HTML come out from curl? what I pasted is everything coming out from curl. no HTML.
maybe I’m missing something
clearly same thing from the browser, not a bit.
Double checked, no antivirus or firewall on PCs and Phones. All the devices where I can’t load the web interface seems to have in common chrome and the subnet
When fetching login page /admin/login yes, but /admin no because it is redirect response. Does request to /admin/login returns only headers but not HTML body or both? This is how request to login page is returned on my side with curl -i http://<pihole_ip>/admin/login > curl_ph_out.txt :
curl_ph_out.txt (11.3 KB)
Should be same to you.
curl -i http://192.168.1.55/login/admin > curl.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:02:00 --:--:-- 0
curl: (56) Recv failure: Connection was reset
The file contains: “HTTP/1.1 404 Not Found“
PS: next week I’ll go to the house where there’s the 192.168.9.x subnet (where the raspberry can open the web interface) and see if the devices that can’t open it would change their behaviour
Check URL, /login/admin instead /admin/login…
oh boy…right!
the txt now contains “HTTP/1.1 200 OK” nothing else
This could indicate MTU issue, haevn’t yet found time to review your ROS config, but such issues are usually related to MTU/L2MTU settings on interfaces - use default values provided by ROS unless there is actual need to change them and when changed they need to be properly calculated to avoid truncation.
You said something interesting.
I have some ports ofs the CRS309 with a MTU set to 9000 to take advantages in transferring big files from the nas. All the other of all the 3 network devices have MTU set to 1480. This value was set after testing for fragmentation. I checked again 2mins ago and “ping google.com -f -l 1452” is the optimal value (to which summing 28 comes out 1480).
BUT VPNs and VETH set it automatically with no possibility to change it. VETHs get 1500 while VPN get 1420.
And this doesn’t explain to me why Pihole5 has no issue with that
well. The MTU subject was correct. Shortly, I solved the issue.
What I had to do is a bit obscure (clearly I don’t manage networks as much as I want), I just changed the L2MTU to the max value showed for every interface (did a bit of research for this) and it seems this was just enoguh. Suddenly the web interface appeared.
I did this for all the interfaces of the 3 network devices. anything has MTU=1480, except the two wireguard server (1420, they like it, I won’t touch it) and the two VETHs (1500, still don’t touch).
I don’t understand the two wifi interfaces on the cAPax that are not configurable, they are set to 1500 and 1560 and the values ar not editable (the L"2MTU is changeable but it restores automatically 1560. defenetely I won’t touch this too!)
@optio THANK YOU A LOT! In my opinion it was very difficult to hit the point…you did!
Of course thank a lot to all the other partecipants.
PS: also rebooted the 3 devices to be sure not having a false positive eheheh