Pi-hole Revisited
Published June 1, 2019
I recently wrote about adding a Pi-hole to my local network.
After upgrading to a new router I ended up tweaking a few things & ran into some problems that I doubt I’m alone in:
- The RPi
eth0
wasn’t getting a new IP address via DHCP automagically - I wanted to force all DNS (port 53) requests through the Pi-hole
I also ended up adding more domains to the blocklist, more on that later.
DHCP Difficulties
The new router uses the LAN subnet 192.168.88.0/24
by default instead of 192.168.1.0/24
. When attempting to migrate the RPi to a static IP in the new subnet I was having trouble with it actually picking up the address from DHCP upon a fresh boot.
I was able to manually run the following command & have it pick up the address but it wasn’t working as it should.
dhclient eth0 -v
I finally stumbled across the /etc/dhcpcd.conf
file which includes DHCP configuration. Within this, I found several entries regarding which were causing my issues:
interface wlan0
static ip_address=192.168.1.252/24
static routers=192.168.1.1
static domain_name_servers=127.0.0.1
interface eth0
static ip_address=192.168.1.2/24
static routers=192.168.1.1
static domain_name_servers=127.0.0.1
interface eth0
static ip_address=192.168.88.2/24
static routers=192.168.88.1
static domain_name_servers=127.0.0.1
interface eth0
static ip_address=192.168.88.10/24
static routers=192.168.88.1
static domain_name_servers=127.0.0.1
After removing these, rebooting, and running pihole -r
I was able to get back up and running.
NAT Firewall
I was noticing ads occasionally on my Android phone & realized that 8.8.8.8
was hardcoded in as a secondary DNS server. Some Googling led me to the following solution within my MikroTik router (/ip firewall nat print
):
;;; Redirect :53 to Pi-hole (UDP)
chain=dstnat action=dst-nat to-addresses=192.168.88.2 protocol=udp src-address=!192.168.88.2 dst-address=!192.168.88.2 dst-port=53
;;; Redirect :53 to Pi-hole (TCP)
chain=dstnat action=dst-nat to-addresses=192.168.88.2 protocol=tcp src-address=!192.168.88.2 dst-address=!192.168.88.2 dst-port=53
;;; Hairpin NAT for Pi-hole (UDP)
chain=srcnat action=masquerade protocol=udp src-address=192.168.88.0/24 dst-address=192.168.88.2 dst-port=53
;;; Hairpin NAT for Pi-hole (TCP)
chain=srcnat action=masquerade protocol=tcp src-address=192.168.88.0/24 dst-address=192.168.88.2 dst-port=53
The NAT firewall rules redirect all port 53 requests for TCP & UDP to the local Pi-hole. The hairpin/masquerade rules also seem necessary but I am not 100% of their exact purpose. With this addition, the Pi-hole dashboard shows requests as coming from the router’s IP as opposed to the device IP but I’m personally fine with that.
Changing Gravity
While doing all this research I stumbled across firebog.net which aggregates collections of blocklists. To keep it as simple as possible, I added the “ticked” lists—which should not require any action from myself in terms of whitelisting domains.
After this addition I went from a 100k to 700k ballpark of blocked domains. I haven’t had any issues with domains or requests being blocked that were causing issues for myself or anyone else on the network.
Last modified June 1, 2019 #networking