Bug #6116


pfBlockerNG doesn't automatically update after firmware upgrade, meaning that unbound doesn't start and users don't have internet connection

Added by Andrew - almost 6 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:


If you're using DNS blocking on PfBlockerNG and update the system firmware, the pfb_dnsbl.conf doesn't exist when the system reboots, meaning that the unbound include statement fails:

server:include: /var/unbound/pfb_dnsbl.conf

This means unbound doesn't start and there's no DNS resolver running, which makes it appear there's no internet connection at all.

This is easily fixed by running an update in pfBlockerNG (which re-creates the conf file) and then doing a filter reload, but it takes a bit of digging to appreciate this is the problem. Users upgrading will be stuck with no internet connection until they work it out.


Actions #1

Updated by BBcan177 . almost 6 years ago

Unfortunately, if you create a backup with pfBlockerNG DNSBL installed and enabled, the backup config will contain the "server:include: /var/unbound/pfb_dnsbl.conf" line. If you restore this backup with pfBlockerNG not installed, then it will crash Unbound due to the missing include file. There is no way around this as pfBlockerNG is a package and not part of the base pfSense installation.

Actions #2

Updated by Andrew - almost 6 years ago

Thanks. Just to clarify, this happens when pfBlockerNG is installed. So, pfBlockerNG is installed, you upgrade the pfSense core, then there's no Internet access when it reboots as unbound doesn't start. So, I'm not talking about the situation where a backup is being restored.

Actions #3

Updated by BBcan177 . almost 6 years ago

Is this on a ramdisk or nano? I haven't heard any other issues so far? Have you seen this on any other 2.3 Snapshot?

Actions #4

Updated by Andrew - almost 6 years ago

It's a full CD/ISO install.

Yes, it did it on earlier snapshots but I wasn't sure whether it was because of upgrading the pfSense core or upgrading the pfBlockerNG package (it just so happened previously that there were upgrades available for the core and for pfBlockerNG at the same time, so I upgraded both together).

When 2.3 was released today, my pfBlockerNG was already up to date so I just upgraded the pfSense core to the release version. The issue still exhibited itself then (i.e. unbound failed to start after the upgrade to 2.3 Release, until I went into pfBlockerNG and did a manual update to recreate the pfb_dnsbl.conf file.

Actions #5

Updated by BBcan177 . almost 6 years ago

Can you check your pfblockerng.log? and send me those particular lines about Unbound at the time of your last update?

Actions #6

Updated by Andrew - almost 6 years ago

There's not a great deal to see.

The upgrade to 2.3 release was done around 20:30 yesterday.

You can see the unbound service failing to start in the DNS Resolver log:

Apr 12 20:33:59 unbound 47469:0 info: start of service (unbound 1.5.5).
Apr 12 20:33:59 unbound 47469:0 notice: init module 1: iterator
Apr 12 20:33:59 unbound 47469:0 notice: init module 0: validator
Apr 12 20:32:13 filterdns unable to open configuration file
Apr 12 20:31:59 filterdns unable to open configuration file

I then kick off a manual rules update in pfBlockerNG to recreate the conf file, and it then restarts unbound successfully after the update. From the pfBlockerNG log:

New DNSBL Cert Created.
Restarting Service DNSBL...

**Saving configuration [ 04/12/16 20:32:31 ] ...

Saving new DNSBL web server configuration to port [ 8081 & 8443 ]
Saving pfSense config...
VIP address configured. Widget Packet statistics reset.
Restarting Service DNSBL...

Archiving Aliastable folder
UPDATE PROCESS START [ 04/12/16 20:33:45 ]

===[ DNSBL Process ]================================================
Missing DNSBL stats and/or Unbound DNSBL conf file - Rebuilding

[ EasyList ] Downloading update .. 200 OK.
Original Unique # Dups Alexa Final
905 879 0 - 879
IP count=8


Assembling database... completed
Validating database... completed
Starting Unbound Service... completed
DNSBL update [ 921 ]... completed [ 04/12/16 20:34:04 ]

It looks like the /var/unbound/pfb_dnsbl.conf file is being removed during the firmware update process, and an pfBlockerNG update isn't kicked off automatically on reboot.

It will only affect users that are using DNSBL and so have the include cross reference in the unbound config. That might be why others haven't reported it.

Actions #7

Updated by BBcan177 . almost 6 years ago

When you see this message "New DNSBL Cert Created", something is deleting the DNSBL cert in the /var/unbound folder (and most likely the pfb_dnsbl.conf file also) and its being re-created on a "Force" command from pfBlockerNG.

You said your on a Full Install, but are you using Ramdisks in System / Advanced / Miscellaneous ? Its the only thing that i can see that would cause these files to be deleted as the /var folder in Ramdisks is volatile.

Actions #8

Updated by Andrew - almost 6 years ago

Yes, sorry, I see what you mean. I'm indeed using RAM disks for /tmp and /var. While it's a full install, it's running on an SSD so I enabled RAMdisks to prevent undue wear to the SSD.

I'll leave it to your discretion as to the way forward. If you want to close the bug (as it's expected behaviour) that's fine. Alternatively, it would in theory be possible to check for the condition that pfBlockerNG is installed, RAMdiscs are enabled, and execute an pfBlockerNG force update on reboot.

Thanks for your help.

Actions #9

Updated by BBcan177 . almost 6 years ago

ok Glad that we found the issue :) I can't close the ticket, thats up to the Devs to decide :)

Even if I try to make some workaround, it will be hard to control, since pfBlockerNG is a package and not part of the base install and will never be stable trying to work around this scenario, unfortunately.

Actions #10

Updated by Andrew - almost 6 years ago

... I was looking at the shellcmd package to see if I could add a start up command to force an update once the system had finished booting and the packages were loaded.

There's already a command shown, which I wasn't expecting.

/usr/local/pkg/pfblockerng/ aliastables earlyshellcmd pfBlockerNG default earlyshellcmd. DO NOT EDIT/DELETE!

Is this supposed to cause an update?

If not, is there anything I can add to cause one?

Actions #11

Updated by Jim Thompson almost 6 years ago

  • Assignee set to Chris Buechler


Actions #12

Updated by Andrew - almost 6 years ago

... I've posted a forum query re trying to get pfBlockerNG to update on reboot so I can continue to use RAM disks.


Actions #13

Updated by BBcan177 . over 5 years ago


Do you have any concerns with restoring the DNSBL database in the /var/unbound folder on reboot (For RamDisk and Nano installs only)?
The only issue is that I need to create the folder, chown and chgrp for it to work...

Its already been tested by Andrew and I also don't want to collide with

/var/db/aliastables/pfB_*.txt are already being backed up and restored.
Would like to add the /var/unbound/pfb_dnsbl.conf file to the existing archiving command:

exec("/usr/bin/tar -jcvf {$pfb['aliasarchive']} {$files_to_backup} >/dev/null 2>&1");

Using the earlyshellcmd feature: shell function to restore IP aliasables and DNSBL database from archive on reboot. ( NanoBSD and Ramdisk installations only )

aliastables() {
if [ "${PLATFORM}" != 'pfSense' ] || [ ${USE_MFS_TMPVAR} -gt 0 ] || [ "${DISK_TYPE}" = 'md' ]; then
if [ ! -d '/var/unbound' ]; then
mkdir '/var/unbound'
chown -f unbound:unbound /var/unbound
chgrp -f unbound /var/unbound
[ -f "${aliasarchive}" ] && cd / && /usr/bin/tar -Pxvf "${aliasarchive}"
Actions #15

Updated by Chris Buechler over 5 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF