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:

  1. The RPi eth0 wasn’t getting a new IP address via DHCP automagically
  2. 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 


← Newer post  •  Older post →