That could suggest your original observation to be caused by your Hikvision (hardware address a0:<redacted> claims 192.168.1.200) holding a DHCP lease from your router, while your RPi 3 had a static IP assigned on device (as it was probing address 192.168.1.200/24).
If your Hikvision now has acquired its new DHCP lease through Pi-hole, your original issue should be solved.
Your debug log shows that now your Pi-hole is the only active DHCP server on the link that your RPi 3 is connected to:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Timeout: 10 seconds
* Received 301 bytes from eth0:192.168.1.200
Offered IP address: 192.168.1.221
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.1.200
dns-server: 192.168.1.200
domain-name: "pi-hole"
router: 192.168.1.1
--- end of options ---
That looks ok.
You have configured Pi-hole for wlan0, but your RPi currently only features an eth0 interface:
*** [ DIAGNOSING ]: Network interfaces and addresses
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.1.200/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 2a<redacted>c2/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86373sec preferred_lft 86373sec
inet6 fe80::<redacted>26/64 scope link
valid_lft forever preferred_lft forever
That won't hurt as long as you keep Pi-hole's Interface settings at Allow only local requests, but to avoid future issues, you want to run pihole -r with Reconfigure and switch to eth0.
Unrelated to your issue, your Pi-hole's group management seems overly complicated.
You have declared 15 groups (renaming the Default group in the process), but all your clients are assigned to either group 7 only (named Free) or the other 14 groups.
In addition, all your whitelist entries are assigned to group 0 only, which may cause unexpected behaviour, as it could leave whitelisted entries blocked for clients that do not have group 0 assigned.
Note that the purpose of groups is to allow client-specific filtering, not grouping adlists by content themes.
You could achieve the same filtering behaviour with a lot less configuration:
- put all adlists in the Default group (which they would be by -well- default)
- add a group Free and don't assign any blocklists to it
- add only those clients that are not to be filtered, assigning them to the Free group exclusively
In that configuration, all clients would be filtered by Pi-hole, unless you've explicitly put them in the Free group, and whitelisted entries would affect all filtering.
