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
eth0wasn’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.
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.
I was noticing ads occasionally on my Android phone & realized that
18.104.22.168 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.
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