Table of Contents
The ad-free internet can exists!
For a while now I have pfSense firewall running at home. I really love the performance, stability and security pfSense provides. It is just rock-solid! But let me tell you why I moved from pfBlockerNG to Pi-Hole. What I also love in pfSense is the ability to install packages and add even more useful features to the platform. So I went ahead and installed the pfBlockerNG-devel package. At the time of writing this blog post the latest version of pfBlockerNG-devel is 2.2.5_29. Note the “devel” in the name because this is the branche of pfBlockerNG which is actively being developed.
Ads on themselves can be OK I think. It all depends on how ads are being used and in the end you need to find funding. After all this site is also using ads. Adding pfBlockerNG allows you not to only block ads but also block web tracking and ransomware. That there is added security and privacy you get when using pfBlockerNG. It will do this for your whole network using something called DNSBL (short for Domain Name System-based Blackhole List). Every device in your network will benefit from this and be protected. But pfBlockerNG does so much more like also giving you the ability to block internet traffic coming from certain IP addresses. These IP addresses translate to specific countries and regions so it can be very handy in protecting your network from all those hackers trying to get in your network.
I went ahead and set up both and for some time everything was working well. I enjoyed ad-free and tracking-free internet on all the devices in my LAN. But then something happened…
The internet broke down (well a little bit)
I have several iOT devices at home including Ikea Tradfri smart lights. Suddenly these lights because unreachable in the Apple Homekit App on my iPhone. The rest of my Homekit enabled iOT devices were doing fine. The first time this happened I thought it is probably a bug so let’s power cycle the Ikea Tradfri gateway. This was a success and the Ikea smart lights were available again. Nice!
Not so nice when I discovered an hour or so later that the Ikea Tradfri smart light were unreachable again. So now I’m thinking that maybe pfBlockerNG is blocking some hostname (the DNSBL feature). This is possible because maybe one of the DNSBL feeds I am using has got an update and some hostname which Ikea Tradfri gateway uses is bow blacklisted. Luckily pfBlockerNG gives you the ability to whitelist hostnames.
I went into the management interface of my pfSense firewall and selected the Reports tab in pfBlockerNG settings. The Reports tab shows a very nice list of hostnames which have been blocked by pfBlockerNG. There is a nice filtering option as well. See the screenshot below.
My Ikea Tradfri gateway has 192.168.100.51 as IP address. This is static setup in the DHCP server on my pfSense. So I enter this IP address in the Alert filter to see if pfBlockerNG is blocking DNS requests from my Ikea Tradfri gateway. The result was 0 so according to pfBlockerNG nothing from my Ikea Tradfri gateway was blocked. See screenshot below.
But still I had the same behavior. When I power cycle the Ikea Tradfri gateway all is well for a short time and then is just becomes unavailable. I continued my investigation and decided to replace the USB power adapter of the Tradfri gateway. That didn’t help. By now I was thinking that I have tried everything but to replace the unit. I went to Ikea and got a new Tradfri gateway. I set it up and went trough the painful experience of connecting all my Tradfri lights and switches to the new gateway. I was just wrapping up when I saw that all my Ikea lights were unreachable again! Imagine my frustration.
Bring on Pi-Hole!
OK now I was furious. Even after replacing the Ikea Tradfri gateway I had the same problem. I was getting more convinced that is has to be something in my network. First step for me now was that I wanted to know all the DNS queries the Ikea Tradfri gateway was making. I tried debugging that in Unbound resolver on my pfSense but there were so many DNS requests flying by that it made troubleshooting nearly impossible.
I needed another DNS server, one specifically for my Ikea Tradfri gateway. And I needed it quick. Since I had a Raspberry Pi lying around I went the Pi-Hole route. Just download the correct image from the Pi-Hole website, extract to the SD-card and startup your new DNS server. Within a couple of minutes I was up and running with Pi-Hole. I loaded the exact same DNSBL lists I was using on pfBlockNG on the Pi-Hole. Using DHCP reservation I managed to set -Pi-Hole as the DNS server on the Tradfri gateway.
Pi-Hole showed me all the DNS queries the Tradfri gateway was doing, which ones were allowed and which ones blocked. I was specifically interested in DNS queries being blocked. I saw immediately that a lot of DNS queries were being blocked to webhook.logentries.com. That DNS query did not came up when I was troubleshooting on pfBlockerNG to find out the blocked queries. I added webhook.logentries.com to the Pi-Hole’s whitelist and waiting a couple of hours. Ikea smart lights were working fine now. Even after 24 hours all my Tradfri lights were now working fine.
Now let’s remove webhook.logentries.com from the Pi-Hole’s whitelist I thought and see what happens. Within the hour my Tradfri lights were offline again. Root cause found :).
Why I made the switch to Pi-Hole
I began to investigate why pfBlockerNG was not showing the blocked DNS queries. I discovered that when I did a DNS lookup on pfSense with pfBlockerNG enabled the request for webhook.logentries.com was being “sink holed” to pfBlockerNG, but it was not showing up in the Reports tab as blocked (or allowed). Check the screenshots below what happens on pfSense.
As you can see above the DNS request is blocked by pfBlockerNG because it is “sink-holed” to the DNSBL VIP pfBlockerNG is using (10.10.10.1). But when I check the Reports tab in pfBlockerNG, I don’t see the blocked DNS request.
Now when I do the same DNS lookup against the Pi-Hole I can see the DNS lookup immediately in the Query Log tab:
The gui on the Pi-Hole makes it really easy to troubleshoot as it shows immediately which client is doing what DNS queries and which ones are being blocked. The gui is also very easy in filtering options.
And you can find very easy in which DNSBL feed a certain hostname is so you know what feed is blocking your internet traffic. It even tells you if the dns name is whitelisted. Makes management so much more easy.
This gui compared to pfBlockerNG was refreshing to me. Amazing how much time I spend troubleshooting on pfBlockerNG while the Pi-Hole showed me within minutes what was happening and where the problem was! Great tech :).
In the end
I moved from pfBlockerNG to Pi-Hole. Don’t get me wrong, I still love and use pfBlockerNG. But I now only use it to block IP addresses from certain countries and regions. It is still very useful for that.
But I don’t use the DNSBL option anymore because I have no faith in it’s reporting capabilities. And that starts to count very heavy when you are troubleshooting why something is not working in your network. Since I started using Pi-Hole I did find some other dns hostnames which were also blocked and were not reported by pfBlockerNG. One of them was to the download server of Ubiquiti for firmwares. Pretty important to know that sort of stuff.
I just can’t be bothered to make tcp dumps of my network traffic on pfSense and then use some kind of tool to analyze and try to find the needle in the haystack. So I recommend you use Pi-Hole for the DNSBL part as it is amazing at that. From the pragmatic perspective it is blazing fast and has great reporting options about what is happening in your network.
why not VLAN in an separate WiFi all your IoT items and in pfSense on that vlan DHCP options push down to the IoT devices the ISP DNS… ?
Its disappointing to read that pfbBlockerNG logging is not working properly.
Did you log this as an issue with the project, or check with the support forums?
Support Forum: https://forum.netgate.com/category/62/pfblockerng
Bug Report: https://redmine.pfsense.org/
Hi! Yes I have been in touch whith BBcan177, the developer of pfBlockerNG. He acknowledged this problem and aims to solve this in the upcoming releas(es) of pfBlockerNG. If you search online ou will find more people reporting the same behaviour like the following post:
– https://www.reddit.com/r/pfBlockerNG/comments/arzy12/live_view_of_dns_requests/
Also I hope we see CNAM inspection and blocking in the following releases. Pi-hole is going an excellent job there!
Hi,
Do you not think that pihole is becoming less useful now that more apps/browsers/IoT devices are implementing encrypted DNS (DoH particularly)?
I still use pihole for blocking where DoH is not implemented but I have found that I now have to use pfBlockerNG to block IP access to well known DoH servers to try and maintain a certain level of blocking.
Would love to have your opinion on this.
Hi! I also use pfblockerNG to block the IP’s of knows DOH servers but I would say with the latest version of pfblockerng and python mode I would retire my pihole.