The article briefly talks about that. I’ll save you the hunt.

“ This unboxing and setup has been fun, but I’d like to block all the bad traffic on my network. I’ve been using a workhorse of a DNS-level adblocker called Pi-Hole on a… yes, Pi, but it would be nice if I can reclaim that wee bit of hardware for something else and use a comparable add-on module in pfSense. Let’s explore that now.”

So basically that was only doing DNS level blocking. This article is about traffic decryption and manipulation.

Pihole is still a wonderful application. I use it on my home network. One drawback that the pihole has vs pfSense is pihole cannot do anything about devices that have hard coded DNS ips (aka 1.1.1.1 or 8.8.8.8 etc).

The hardcoded issue is more of a consumer router limitation than a pihole issue. Any router that can redirect DNS request + dnsmasq can do what pf-blockerng does. You just don’t see it since pfsense does this in the background. All my ubiquiti stuff or Opnsense uses pihole fine with hardcoded DNS including chromecast (I use NextDNS instead of pihole but essentially the same thing).

Indeed, how it is described in section 3.2 of the article is how I also did it on my home router+pihole combo. Still have add that rule 1 though, dns over tls.

DNS is really easy to redirect (at the firewall level) since it goes over UDP. The growing problem is DNS over HTTPS, which uses certificates and tcp and is much harder to redirect (without setting up a MITM and distributing the CA to all devices). Fortunately just blocking the DoH domains at the DNS level works, but unlike the global udp port 53 redirect, it’s a cat-and-mouse game.