Project

General

Profile

Actions

Bug #12330

closed

pfBlockerNG devel creating invalid NAT rules on boot

Added by Sietse van Zanen over 2 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
pfBlockerNG
Target version:
-
Start date:
Due date:
% Done:

0%

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

Description

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.

Actions #1

Updated by Jim Pingle over 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 2 years 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 almost 2 years ago

  • Assignee deleted (Renato Botelho)
Actions #5

Updated by Jordan G over 1 year 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 about 1 year ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF