pfSense » pfSense Packages

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.

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.

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?

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.

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

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.

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.

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.

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.

... 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/pfblockerng.sh 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?

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

https://forum.pfsense.org/index.php?topic=110791.0

Thanks.

Devs:

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 https://github.com/pfsense/pfsense/pull/2902

/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:
pfblockerng.sh 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
        fi
        [ -f "${aliasarchive}" ] && cd / && /usr/bin/tar -Pxvf "${aliasarchive}" 
    fi
}

Resolved with https://github.com/pfsense/FreeBSD-ports/pull/140