pfSense » pfSense Packages

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 10.10.10.1 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 pfblockerng.inc 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 filter.inc 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.