Whitelisting not working

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 :frowning:

Screenshot from 2022-06-23 10-57-51

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!!!