Expected Behaviour:
adding entries to white list stops them being blocked
I have added git.target-domain to dns as 192.168.3.1
my client is 192.168.3.21
ifconfig eno1
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.21 netmask 255.255.255.0 broadcast 192.168.3.255
inet6 fe80::aa51:d33f:95c7:44e0 prefixlen 64 scopeid 0x20<link>
ether 3c:52:82:51:f7:9a txqueuelen 1000 (Ethernet)
RX packets 97157 bytes 35209276 (35.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 98878 bytes 13660241 (13.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf0a00000-f0a20000
Actual Behaviour:
no matter what I do they remain blocked
$ curl http://git.target-domain:8080
<!doctype html>
<!-- Pi-hole: A black hole for Internet advertisements
* (c) 2017 Pi-hole, LLC (https://pi-hole.net)
Debug Token:
https://tricorder.pi-hole.net/IvUOFDhN/
I also tried disabling pi-hole but it is still blocking 
I have tried blocking facebook - when I dig it it comes up with null ip (this is with different server)
$ dig facebook.com
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39865
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com. IN A
;; ANSWER SECTION:
facebook.com. 2 IN A 0.0.0.0
;; Query time: 0 msec
;; SERVER: 192.168.3.21#53(192.168.3.21) (UDP)
;; WHEN: Thu Jun 23 11:31:11 BST 2022
;; MSG SIZE rcvd: 57
when I whitelist git.target-domain it IS returning correct ip
$ dig git.target-domain
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> git.target-domain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30347
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;git.target-domain. IN A
;; ANSWER SECTION:
git.target-domain. 0 IN A 192.168.3.21
;; Query time: 3 msec
;; SERVER: 192.168.3.21#53(192.168.3.21) (UDP)
;; WHEN: Thu Jun 23 11:33:19 BST 2022
;; MSG SIZE rcvd: 62
but the website is still blocked..
Your output does not demonstrate that Pi-hole would be blocking git.target-domain.
Rather, it would seem that the webserver is not recognizing the URL it is asked to access and redirects to its 404 handler. If Pi-hole's lighttpd is your webserver, that would be Pi-hole's blocking page.
However, I'd expect Pi-hole's webserver to run on your 192.168.3.21 only.
Is your 192.168.3.1 redirecting port 8080 to your Pi-hole host at 192.168.3.21:80?
Or are those IPs perhaps attached to the same host?
EDIT:
Your debug log shows that you are running a dockered Pi-hole, but your Pi-hole container is not configured for your host's private range IP yet.
You should set the respective FTLCONF_REPLY_ADDR4 recommended variable.
1 Like
ah slightly confusing that the 404 handler page claims it's blocked..
I don't think so - above is slightly garbled as I've tried this on 21 and 1
the "blocked" ie 404ed pages are only pi-hole
pi-hole will work fine at http://192.168.3.1:8080 but not at http://git.target-domain:8080 even though git.target-domain resolves to 192.168.3.1
so if I run another web server on port 8081 it works fine..
It seems like pihole doesn't like being accessed under that domain name but is ok at it's ip
tried that (I am on 21 now)
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
ports:
- "53:53/tcp"
- "53:53/udp"
#- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
- "80:80/tcp"
#network_mode: "host"
environment:
#TZ: 'America/Chicago'
WEBPASSWORD: 'xxxxxx'
FTLCONF_REPLY_ADDR4: 192.168.3.21
# Volumes store your data between container upgrades
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq.d:/etc/dnsmasq.d'
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN # Recommended but not required (DHCP needs NET_ADMIN)
restart: unless-stopped
$ dig git.target-domain
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> git.target-domain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29669
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;git.target-domain. IN A
;; ANSWER SECTION:
git.target-domain. 0 IN A 192.168.3.21
;; Query time: 0 msec
;; SERVER: 192.168.3.21#53(192.168.3.21) (UDP)
;; WHEN: Thu Jun 23 12:09:54 BST 2022
;; MSG SIZE rcvd: 62
curl 192.168.3.21 - gives me good page
curl git.target-domain gives me blocking (404) page
Yes, but that's how Pi-hole would have served the block page for a browser trying to access resources from a blocked domain that would instead have been asking Pi-hole's lighttpd to serve that URL, back in the days when HTTPS was not yet the predominant protocol.
The corresponding outdated IP blocking modes may be retired with one of Pi-hole's next releases.
1 Like
FTLCONF_REPLY_ADDR4 was just some additional finding from your debug log.
The top domain will always be handled that way with PI-hole's webserver, but you should be able to access additional content from more specific URLs from its dedicated subfolder.
I'm reasonably confident that the following curl will return a 200:
curl -I -sSL http://git.target-domain/admin:8080
1 Like
yes that returns a 200 (I'm on port 80 now)
$ curl -I -sSL http://git.target-domain/admin/
HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=b0b0s7lig5qt9shqv32la6tk2e; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-type: text/html; charset=UTF-8
X-Pi-hole: The Pi-hole Web interface is working!
X-Frame-Options: DENY
Date: Thu, 23 Jun 2022 11:33:01 GMT
Server: lighttpd/1.4.59
browsing to http://pi.hole works (even though that's not configured in dns) - but it redirects to pi.hole/admin
browsing to http://git.target-domain gives the 404 page
browsing to http://git.target-domain works
browsing to http://192.168.3.21 woks with no redirect
I wonder why http://pi.hole redirects but http://git.target-domain doesn't.. "The top domain will always be handled that way with PI-hole's webserver" - anyhow all good now! Thanks so much!!!
