Bug #12330


pfBlockerNG devel creating invalid NAT rules on boot

Added by Sietse van Zanen almost 2 years ago. Updated 3 months ago.

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


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


There were error(s) loading the rules: /tmp/rules.debug:309: could not parse host specification - The line in question reads [309]: rdr pass on pppoe0 inet6 proto tcp from any to ::1010101 port 80 -> ::1 port 8081

::1010101 as derived from ipv4 address is not a valid ipv6 address. Besides the rule is created on the wan interface, which is not selected anywhere in the configuration, so should not be created at all. This does not pertain to ipv6 but to ipv4 as well, NAT rule is created where it shouldn't be. Selected interface for VIP is not the wan interface, but localhost, rdr rules should not be created at all.

Issue with ipv6 is cascading down into pfsense not fully finishing startup process, aliases are not expanded, not all rules paresdand, Pfr_update_stats: assertion failed. messges on the console. Also config.xml is regenerated twice on boot because of this.

The core of this issue is that vip/lighthttpd for block pages in pfblockerng dnsbl is not very well designed. One of the things I find severely lacking is that it is not possible to redirect traffic to an interal web server / proxy for handling block pages. It really needs an overhaul, I will look into it, but not promising anything. Project seems to be stalled as no work has been done on it for over 6 months.

There is however one serious flaw in and I will supply a PR for this:
pfb_global() does not set the the $pfb['dnsbl_iface'] variable
pfb_sync_package() first calls pfb_create_dnsbl() on boot with an empty dnsbl_iface variable
pfb_create_dnsbl() Then proceeds to evaluate no exisitng NAT rules exist and creates them because:
// Generate new DNSBL NAT per DNSBL listening ports except for 'localhost' interface setting.
$dnsbl_new_nat = array();
if ($pfb['dnsbl_iface'] != 'lo0') {

Since the wan interface is hardcoded ion as the default NAT interface the rules are created there.
I suspect a lot of people using pfblocker-ng-devel have these NAT rules. When ipv4 only is used, this will not cascade down into more issues, so probably goes unnoticed.

Solution is to simply set the interface in pfb_global(), instead of evaulating somwhere down the line in pfb_sync_package(), before the second call to pfb_create_dnsbl() under UNBOUND INTEGRATION.

Actions #1

Updated by Jim Pingle almost 2 years ago

  • Project changed from pfSense to pfSense Packages
  • Category changed from Rules / NAT to pfBlockerNG
  • Release Notes deleted (Default)
Actions #3

Updated by Renato Botelho over 1 year ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho

PR has been merged. Thanks!

Actions #4

Updated by Renato Botelho about 1 year ago

  • Assignee deleted (Renato Botelho)
Actions #5

Updated by Jordan Greene 6 months ago

similar behavior when restoring a backupconfig.xml that had pfBlockerNG-devel settings but the pfBlockerNG pkg doesn't install upon system starting initially post backup restore (or wasn't installed prior to restore) due to connectivity physical or otherwise.

Actions #6

Updated by Marcos M 3 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF