Project

General

Profile

Actions

Bug #16756

open

Editing a Firewall Rule before Forcing pfBlockerNG Update Empties All Aliases

Added by Kris Phillips 25 days ago. Updated 18 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
pfBlockerNG
Target version:
Start date:
Due date:
% Done:

100%

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

Description

When editing a firewall rule and then forcing a pfBlockerNG Update command, all aliases will become empty until you run a force reload in pfBlockerNG.

Steps to reproduce:
1. Edit any firewall rule (doesn't need to be a pfBlockerNG rule)
2. Go to Firewall --> pfBlockerNG --> Update, select "Update" and run
3. Go to Firewall --> Rules and hover over any firewall rule with a pfBlockerNG alias. The alias will be empty.

To resolve, you must go to Firewall --> pfBlockerNG --> Update and run a "Reload" to fix the issue.


Files

EmptyRulesAfterUpdate.png (78.2 KB) EmptyRulesAfterUpdate.png Kris Phillips, 03/21/2026 08:31 PM
FixedRulesAfterForceReload.png (194 KB) FixedRulesAfterForceReload.png Kris Phillips, 03/21/2026 08:31 PM
Actions #1

Updated by Kris Phillips 25 days ago

Tested on pfBlockerNG 3.2.15_2. Going to Status --> Filter Reload and manually reloading there does not fix it.

Output of pfSsh.php playback pfanchordrill:

###################
  1. translation rules ###################
    nat-anchor "natearly/*" all {
    }
    nat-anchor "natrules/*" all {
    }
    rdr-anchor "tftp-proxy/*" all {
    } ##############
  2. filter rules ##############
    anchor "openvpn/*" all {
    }
    anchor "ipsec/*" all {
    }
    anchor "userrules/*" all {
    }
    anchor "tftp-proxy/*" all {
    }
Actions #2

Updated by Kris Phillips 25 days ago

Something of note: I have Alias Deny set for my GeoIP rules. Not Deny, Match, or Permit.

Actions #3

Updated by Steve Y 23 days ago

Forum thread: https://forum.netgate.com/topic/200372/pfblockerng_devel-on-25.11.1-instability/

Per your note, the routers on which I replicated it use Alias Native or Deny for GeoIP.

Disabling a rule is sufficient to trigger this.

Actions #4

Updated by Marcos M 22 days ago

  • Status changed from New to In Progress
  • Assignee set to Marcos M
Actions #5

Updated by Marcos M 22 days ago

The issue is triggered when the pfBlockerNG update/reload detects a change to aliases and/or rules and the resulting ruleset file is the same as before the pfBlockerNG update/reload process.

For example:
  1. Set up LAN with a single allow-all rule (remove existing rules then create a new one).
  2. Apply any changes.
  3. Set the pfBlockerNG rule order to "Default format".
  4. Set up pfBlockerNG with an IP list set to "Deny Outbound".
  5. Run a forced pfBlockerNG update.
At this point things should be working correctly. Then:
  1. Move the auto-created rule from the top to the bottom (don't apply changes).
  2. Run a forced pfBlockerNG update.

At this point the pfBlockerNG alias referenced in the auto-created rule is empty. This happens because during the forced update pfBlockerNG sets the firewall config, kills all (pfB_*) pf tables with pfctl -t <table> -T kill, and then runs a filter reload. The firewall config has now essentially been rolled back to before the rule was manually moved in the above steps. Additionally since 1) changes were not previously applied (in step 1), and 2) the ruleset file doesn't contain the table contents itself, then the ruleset file remains unchanged and the pf ruleset reload is skipped. That ruleset reload is currently responsible for repopulating the killed pf tables.

The issue can be fixed by having pfBlockerNG kill its pf tables only if they are no longer referenced in a rule. This change would retain what seems to be the original intent of the code while also being more efficient (only the necessary tables are cleared and the ruleset is only reloaded when needed).

Potential fix: Show

Actions #6

Updated by Marcos M 22 days ago

  • Status changed from In Progress to Ready To Test
Actions #7

Updated by Steve Y 22 days ago

Seems OK in a couple of quick tests, per forum post.

Actions #8

Updated by net blues 22 days ago

As the initial poster of the issue, I can confirm that the patch fixes the issue

Actions #9

Updated by Marcos M 22 days ago

  • Status changed from Ready To Test to Resolved
  • Target version set to 2.9.0
  • % Done changed from 0 to 100
  • Plus Target Version set to 26.03
  • Affected Version set to 2.9.0

Applied in 0083e293bf9ef47bf8b7f88eb954f80c5fb9dd15.

Fix will be part of pfBlockerNG-devel for now and picked to non-devel later.

Actions #10

Updated by Kris Phillips 18 days ago

  • Status changed from Resolved to In Progress

Checked 26.03-RELEASE build repos and the pfBlockerNG devel and stable branches are both still the same version.

Marking as In Progress until the package is rebuilt and bumped in version.

Actions

Also available in: Atom PDF