Basic Pihole Configuration

This is a REALLY quick how to for basic PiHole use with Turris and a separate raspberry pi.
I know there are other options and relative problems but for others like me coming to OpenWRT and Turris from an old working setup this is the fastest easiest way to get started.

The following assumes you have a RaspberryPi already setup with PiHole and that device already has a fixed IP.

  1. log into the router and use LuCI
  2. In the top bar select : Network > interfaces
  3. In the “LAN” section select Edit
  4. Scroll to the bottom in the “DHCP Server” section and Click on the “Advanced Settings” tab/link
  5. Find the DHCP options section
  6. Change the address from 6,192.168.1.1 to 6,(IP address of your pihole raspberry)
  7. Reboot the router (maybe? it’ll at least force a refresh for all your clients)

It is really just the last comment here:

This is super simple but some how it took me hours to find how to do this because I kept running into how to either configure DNS forwarding or how running a physical pihole is stupid you should do X,Y,Z instead. In retrospect this makes sense but I wasn’t really aware of how the DNS server address was being disseminated all the DHCP clients.

Sorry if this is the wrong place for this but I wanted to write this down someplace.

This step is the same if you run the pi-hole in the router itself (in a container), I believe – at least it’s one way to have the DNS chain… to just hand out the address of pi-hole directly via DHCP.

BTW, you might consider configuring the pi-hole to forward to the router’s DNS, which would get you DNSSEC validation, optionally TLS forwarding (and possibly other features, put perhaps you don’t care for any of these).

I did not know that, I never looked deep into the container setup as I (wrongly) assumed it wouldn’t relate. I like this idea, it seems the latest version of PiHole supports DNSSEC Validation? It isn’t on by default but in the PiHole Admin console:

Assuming the PiHole has already been setup to use cloud flair or some other DNSSEC supporting dns, there is a short note in the PiHole page near DNSSEC regarding this pre-req.

Settings > DNS > Use DNSSEC (check this box)

and it should have the same/similar effect yeah?

It’s possible, but I’m not a good judge of that. IIRC it’s based on dnsmasq and that claims to support validation for a couple years, I think.

It’s probably less “battle-tested” than for other resolvers (as dnsmasq users typically still don’t enable it, I expect), but for normal people it might not make a noticeable difference.

Where is this setting in TOS 6.x? Network > DHCS and DNS > Advanced Settings > ?

What is the syntax if I want to forward to pi-hole in a Docker container (8080 exposed)? 6,192.168.1.1:8080?

I believe the DHCP protocol does not allow specifying port for a DNS server. (and 8080 is traditional for http, BTW)

@vcunat - sorry to revive a zombie thread but I think this is the best venue vs. starting a new thread.

I have two piholes setup. Both running unbound in recursive mode with all the excellent DNSSEC features. It also acts as my local lan DNS provider. All is well for everything on my network.

I am dealing with two small issues right now:

  1. DNS coming over a Site to Site wireguard uses the local Turris knot resolver. This does not know how to talk to the pihole servers and fails to resolve some local DNS settings. By and large, this is OK as everything plumbed on the either side of the Site to Site knows to use the piholes.
  2. Any time I am shelled into the router, it can’t resolve any of my local addresses.

So my question: how can I get the Turris OS (e.g. /etc/resolv.conf) to (1) search my home.local domain and (2) use my two pihole servers w/o getting blown out by a reboot? I tried setting up forwarding via reForis → Network → DNS but that did not work. I’ve manually changed /etc/resolv.conf but it gets blown away by reboots.

Any help would be greatly appreciated.

  1. I think it’s wireguard’s config which IPs to use as DNS for connected clients.
  2. I don’t know how /etc/resolv.conf is controlled in Turris OS / OpenWRT, but that would probably be the way.

.local provably doesn’t exist in DNS, so DNSSEC validation must refuse such names. Alternatively you could set up forwarding with DNSSEC disabled; I expect that would work. But I still don’t recommend .local in DNS, as it’s reserved for a similar but different protocol (mDNS/avahi). For similar reasons I don’t recommend exposing DNS on port 5353 in LAN.

1 Like

I’ll take advantage of the necro and insert a related question (well, two, really.)

  1. Isn’t the proper way to do this through reForis, as my understanding is that Luci on Turris doesn’t use some of the typical daemon (i.e. dnsmasq), so some settings would simply be ineffective?; and
  2. Going through DNS forwarding on reForis, is there a way to have a backup? I have pihole running in a docker on a local server, but I’m going to roll up my sleeves this weekend, install a small ssd in my Omnia and put a second pihole docker directly on the router. Is there a way with reForis to point to the router pihole first, and server pihole second? It doesn’t appear possible from the interface.

Forwarding on Turris (in the underlying Knot Resolver) does not have a “backup” concept. You can enter multiple targets, but you can’t prioritize. They’re balanced based on their performance (latency and also correctness in some sense).

Are you saying that in the DNS section, if you create a custom forwarder, that the Omnia will nonetheless use all of the forwarders, despite the fact that the custom one has the radio button selected? If that’s the case, how would one make sure that the Omnia only uses one specific (pihole) one?

No. I’m saying that there typically are multiple addresses. And you can choose multiple IP addresses in your custom one.

Ah! That’s cool. So for the custom one, I’d simply separate addresses by a comma? (i.e. 192.168.0.15, 192.168.0.20)

No, you click buttons to add more:

Oh… Durh. For some reason I thought “Add IPv4 address” was just equivalent to hitting return on the first one. Thanks!

If you want to run pihole in docker container in turris omnia best solution is to use macvlan network for that container.
In that case container would get unique ip so you should not bother about changing or exposing ports or disabling services in omnia.

opkg install kmod-macvlan

/etc/config/network

config interface ‘pi_vlan’
option proto ‘static’
option ipaddr ‘192.168.3.1’
option netmask ‘255.255.255.0’
option device ‘br-lan.3’

config device
option type ‘macvlan’
option ifname ‘br-lan’
option mode ‘bridge’
option name ‘br-lan.3’
option acceptlocal ‘1’

docker-compose

services:
  pihole:
    image: pihole/pihole:2022.12.1
    container_name: pihole
    hostname: pihole
    restart: unless-stopped
    environment:
      TZ: 'Europe/Bratislava'
    volumes:
      - pihole_data:/etc/pihole/
      - pihole_dnsmasq.d_data:/etc/dnsmasq.d/
      - /etc/localtime:/etc/localtime:ro 
    cap_add:
      - NET_ADMIN
    networks:
      pi_lan:
        ipv4_address: 192.168.3.3

volumes:
  pihole_data:
  pihole_dnsmasq.d_data:

networks:
  pi_lan:
    name: pi_lan
    driver: macvlan
    driver_opts:
      parent: br-lan.3
    ipam:
      config:
        - subnet: 192.168.3.0/24
          gateway: 192.168.3.1

Adjust zone and fw rules
You can for example edit LAN zone and add your new vlan to covered networks or create new zone.

And after that you can add 6,192.168.3.3 into DHCP settings :slight_smile:

This was actually exactly what I was looking for, but I’m not sure I’m doing it correctly. If my default gateway (router) ip address is 192.168.0.1, would I change the options you listed from 192.168.3.1 to 192.168.0.1, or does the macvlan need a different subnet (i.e. keep 192.168.3?)

If you dont want new VLAN (new subnet) in my case 192.168.3.1, then I guess you just need to configure device, you have to skip interface configuration (as you already have it configured as br-lan)

but be aware as I guess you have DHCP in your default LAN, and I am not really sure if your DHCP will known about your container, that means maybe DHCP can randomly assign same IP adress to somebody else on your lan as your container will have, so I recommend using static leases or/and pick something out of ordinary for your container if they are in same lan with dhcp.

So, if I’m understanding this correctly, I can go ahead and have my normal LAN at 192.168.0., and this macvlan at 192.168.3.? I tried setting up the macvlan using your config, but I see in Luci that for my PI_VLAN, I get Error: Unknown error (DEVICE_CLAIM_FAILED)

Yes,

please post your whole /etc/config/network file. I will take a look.