pfBlockerNG Setup: DNS Ad-Blocking and Threat Intel on pfSense

pfBlockerNG is one of the most powerful packages available for pfSense — it combines DNS-based ad/tracker blocking (like Pi-hole) with IP reputation blocking (geo-blocking, threat intel feeds) in a single pane of glass. This guide covers setup from zero to a working multi-feed DNSBL configuration; once the DNS side is working, the pfBlockerNG GeoIP and IP-reputation guide ↗ covers the packet-layer half of the package.

A prerequisite that trips people up: DNSBL works by hooking the DNS Resolver (Unbound). If your network’s clients are using a third-party DNS server (hardcoded 8.8.8.8 on devices, DoH in browsers, or a router handing out a public resolver) instead of pfSense, pfBlockerNG never sees those queries and blocks nothing. Before you start, make sure pfSense is the DNS server clients actually use (Services → DNS Resolver enabled, DHCP handing out the pfSense IP as DNS), and plan to block or redirect outbound port 53/853 from clients so devices can’t bypass it. Without that, the rest of this is cosmetic.

Install pfBlockerNG

System → Package Manager → Available Packages → search pfBlockerNG-devel → Install.

Use the devel variant — it’s more actively maintained and required for DNSBL functionality.

After install: Firewall → pfBlockerNG. (Historically there were separate stable and -devel packages; install whichever the current pfSense package manager presents as the maintained DNSBL-capable one — there should only be one to choose on a current system.)

Run the setup wizard

On first load, pfBlockerNG offers a setup wizard. Accept the defaults for:

pfBlockerNG interface: WAN
Inbound firewall rules: ✓ (blocks inbound threats at the WAN)
DNSBL: ✓ (enables DNS sinkholing)
DNS resolver integration: ✓ (pfBlockerNG takes over unbound)

Configure DNSBL feeds

Navigate to DNSBL → DNSBL Feeds → Add:

Recommended free feeds

Feed name	Source	Category
Hagezi Threat Intelligence	`https://raw.githubusercontent.com/hagezi/dns-blocklists/main/wildcard/pro.plus.txt`	Ads + Malware
Steven Black Unified	`https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts`	Ads + Tracking
URLhaus	`https://urlhaus.abuse.ch/downloads/rpz/`	Malware URLs
EasyList	via pfBlockerNG built-in	Ads
OISD	`https://big.oisd.nl/`	Comprehensive

Add each feed:

State: ON
Action: Unbound
Update frequency: Daily is plenty for most lists; very frequent updates mostly add load without meaningful benefit for ad/tracker lists (threat-intel feeds are the exception if you care about fast propagation).
List action: choose the DNSBL action that sinkholes matches (returns a null/sinkhole address). For DNSBL feeds the relevant control is the DNSBL action, not a packet-filter direction — match the wording in your pfBlockerNG version.

Start with two or three well-maintained lists, not ten. Overlapping mega-lists massively inflate the blocked-domain count, slow updates, and dramatically increase false positives with little added protection. A lean, reputable set (one comprehensive ads/trackers list plus a malware list) blocks the vast majority of junk with far fewer support headaches. You can always add more later.

Configure IP reputation blocking (optional)

The GeoIP and IP-reputation feeds are covered in depth in the dedicated GeoIP / IP-reputation guide ↗; the quick version follows. Note that this packet-layer blocking is a different control from the payload inspection an IDS does — pairing pfBlockerNG with an IDS/IPS engine like Snort or Suricata ↗ covers both layers, and dropping known-bad IPs first lightens the inspection load.

DNSBL → IP Reputation → GeoIP:

Register for a free MaxMind GeoLite2 account (required since MaxMind requires an API key).
Enter your MaxMind license key in pfBlockerNG → General → MaxMind.
In IP → GeoIP Profiles, add a block rule for high-risk country groups if needed.

Reputation feeds:

Emerging Threats (ET) — free IP block lists for known bad actors
Spamhaus DROP — includes SBL, XBL (requires registration)

Update and force sync

After adding feeds:

Firewall → pfBlockerNG → Update → Run
Select: Update mode → Execute

Wait for the download to complete. Check the log for any failed feeds.

Verify it works

From a LAN device:

nslookup doubleclick.net 192.168.1.1
# Should return: 0.0.0.0 (sinkholed)

nslookup google.com 192.168.1.1
# Should return: real IP

Browse to a site heavy with ads — they should disappear.

Tuning false positives

If a legitimate site is being blocked:

Check DNSBL → DNSBL Alerts for recent blocks.
Go to Firewall → pfBlockerNG → DNSBL → Whitelist, add the domain.
Run an update to rebuild the blocklists.

Dashboard widgets

Diagnostics → pfBlockerNG → Dashboard shows blocked requests, top blocked domains, and feed health. Add the pfBlockerNG widget to the main pfSense Dashboard (Status → Dashboard → + → pfBlockerNG) for an at-a-glance block ratio. A healthy setup typically shows a meaningful percentage of DNS queries blocked; near-zero blocks almost always means clients are bypassing the resolver (see the prerequisite at the top).

Common gotchas

Browser DoH/DoT bypass. Modern browsers and OSes increasingly default to encrypted DNS to a third party, which sidesteps pfBlockerNG entirely. Disable DoH in managed browsers, and consider a firewall rule that blocks/redirects outbound DNS (and known DoH endpoints) so the only path is the pfSense resolver.
IoT devices with hardcoded DNS. Many smart-home/streaming devices ignore DHCP-provided DNS and hardcode 8.8.8.8. A NAT redirect rule that transparently rewrites outbound port 53 to the pfSense resolver forces them through DNSBL. This pairs naturally with isolating those devices on their own segment — see the pfSense VLAN configuration guide ↗ for per-VLAN DNS enforcement.
TLS-SNI vs DNS. DNSBL blocks at name resolution; it cannot block a domain reached directly by IP or fronted behind a shared CDN. For those, IP reputation/firewall rules are the right layer, not DNSBL.
Over-blocking breaking apps. Smart-TV and mobile apps sometimes fail silently when an analytics/telemetry domain is sinkholed. When triaging “this app stopped working,” check DNSBL Alerts first and whitelist surgically.
Update failures. If a feed URL changes or rate-limits, the whole update can abort. Check the Update log periodically; remove or replace dead feeds.

Verification and rollback

Verify with nslookup from a client against the pfSense IP: a known ad domain should return the sinkhole address (e.g., 0.0.0.0) while a normal domain resolves correctly. Browse an ad-heavy page and confirm visible ad reduction. If something legitimate breaks and you can’t immediately find the offending domain, the fast rollback is to disable the DNSBL action (or set the offending feed’s State to OFF) and re-run an Update — service is restored in one cycle without uninstalling the package.

When pfBlockerNG isn’t the right tool

If you only want simple network-wide ad-blocking and already run a dedicated Pi-hole/AdGuard box, layering pfBlockerNG on top adds duplicate maintenance for little gain — pick one DNS sink. If your environment makes enforcing pfSense-as-resolver impossible (heavy DoH use you can’t control, BYOD with no policy), DNS-based blocking will be porous and you should weigh whether the upkeep is worth a partial result. pfBlockerNG shines when pfSense is genuinely the network’s DNS chokepoint and you want ad/tracker/threat blocking integrated with the firewall rather than as a separate appliance.

Comparing pfSense vs OPNsense ↗ ad-blocking? OPNsense typically uses the AdGuard Home or Unbound-blocklist plugins; pfBlockerNG is more tightly integrated into pfSense. See firewallcompare.com ↗ for a side-by-side.