Token's lvl1 blog- edit -- Token's rantings

Generally speaking, PF should have no say in what pi-hole does and what it logs. Putting the pi-hole separately on a different IP and forcing the LAN hosts to use the host with the pi-hole and PF is out of the question.

All logs that can be collected here will be collected. And no special configuration on the PF side is needed.
All dns query traffic shouldn’t even brush up against a PF host.

Do you want to see something unusual in these logs? Pi-hole will only log dns queries and nothing else… Let PF log the rest of the situation in the network.

Above is a typical simple scheme of this solution.

My router has dhcp which tells hosts on lan your dns servers are and’s).
On the router I have completely blocked traffic for UDP 53 and I do not answer dns queries … that’s what dedicated dns servers (pihole) are for.

Hosts in the LAN have the settings that their dns servers are these specific piholes and they do not try to ask elsewhere, and even if they wanted to, I block them anyway 53.

My pi-holes use both Quad9 and Cloudflare for upstream DNS over HTTPS. As a result, all dns request traffic from LAN goes to updns encrypted. Of course still udp 53 locally.

In this model, pfsense or any other software has nothing to say. Router/Firewall never gets this traffic. All they know and see is DHCP broadcasting these specific dns(pi-hole) addresses and nothing else.
The actual traffic is between the hosts and the pi-hole machine.

However, as for the router itself and its local dns queries against the upstream. I also force my local pi-hole for the WAN interface. And in the pi-hole logs I can see the requests of the router itself, if there are any dns requests.

The end result is that whatever within my lan does a dns query, including the main router that has a WAN port to the world, I will see in the pi-hole logs that this particular IP has asked for this domain.

So in this configuration there should be no problem with log content in pi-hole. And pfsense itself and dhcp on it should absolutely not affect anything. :slight_smile:

I don’t see a problem here… I must have missed something. :slight_smile:

Sounds work intensive to not have DHCP.

I found a setting in pfSense in the interface DHCP to assign a DNS server so I plugged the pihole into that, TBD as I’m not going to blow up the leases just yet. Basically, there are 50 guides all with different means of making your diagram a reality as I bet there are a few different legit ways of going about it with my gear + guides being outdated as updates break things, GUIs change, features change etc. That aside, its kind of nuts how many different places you have to tell pfSense “no, no, Look at me. You are not the DNS, I am the DNS now”.

Pihole is working for the most part- its sinking adds. Its that the pihole logs list all queries from host “pfSense.localhost” because pfSense is acting like a proxy I guess, pihole is not aware the query is from the OnePlus6, or laptop, or chromecast etc. I’m just trying to shore that up without breaking stuff.

There are three types of techies I guess:

  • Power user types that don’t stop at a turn key Asus/netgate/nighthawk etc all-in-one router/wifi, but actually get into the GUI, add things like Pis with software like Pihole.
  • Those that then dabble into the more pre-sumer and homelab’y stuff, trip and fall a lot.
  • Essentially sysadmins or programmers and it comes really easy

I’m one foot in the first one, one foot into the second one. Making life painful. If I was rocking my old Asus and a pi3 with pihole, it would probably be pretty smooth sailing. But no, I gotta try and go prosumer/home lab/open source/bells and whistles and yeah, I get pretty tripped up.

1 Like

Yep going into the LAN’s DHCP GUI and putting pihole’s IP in the DNS setting there did the trick:


vs. the various “answers” found googling.

Next is like you changing the upstream DNS to something like cloudflare- looks to be a one click trick.

1 Like


Have a reference to where these additional lists can be had?

All the lists I use now are from: Developer Dan, The Block List Project, Dan Pollock, StevenBlack,,

Generally, every now and then I remove those from and add them again if there have been changes. I only use this list to reduce false positives.

You can use the same ones I use… But adapt it to your own needs.
1 Like

Find in PF, the WAN interface and its settings.

Change to static if it’s on dhcp. It’s about the addressing of the network you have from the ISP on the WAN port.
Look for the dns servers section there, and enter your dns ip there.

This way your router will query your pihole instead of your ISP dns.

Once we have the entire network forced to use your dns server (pihole) you can start changing the upstream dns for pihole.

In pihole gui, go to settings and dns, you can choose dns servers there. But it’s all unencrypted UDP 53.

If you want your pihole to have DOH, I recommend this guide Works 100%


I would still recommend in the future to use a separate machine for Pi-Hole and not to do it on the router, or at least a separate VM.
Because the tunnel has to work as a daemon in the background and I personally don’t like doing it on the PF machine. :wink:

1 Like

This behavior is usually seen for…

If PF works as a “DNS bridge”, it advertises its IP address as a dns server to hosts on the LAN. Then the hosts on the lan send their dns traffic to PF and PF forwards it/queries its up-dns.

If Pi-Hole is running on a PF machine without any VM separation, then all dns queries that PF generates/forwards will be visible in Pi-Hole as just local, which is what you probably observed.
Why is this happening… it’s because PF forwards this traffic from its local to still local where pi-hole is listening.

In this configuration, the pi-hole will probably never see the correct host lan because it receives requests not from host lan, but directly from PF locals, and that’s why it sees it.