pfSense » pfSense Packages

The issue is reproducible on pfSense Plus 26.03 and appears isolated to scenarios where pfBlockerNG is enabled.
Observed behavior:
With pfBlockerNG disabled:
Firewall rules added or removed in the GUI are immediately reflected in the active ruleset and visible via pfctl -sr.
Alias changes made in the GUI correctly update the associated PF tables (pfctl -t <alias> -T show).
With pfBlockerNG enabled:
Firewall rule additions or deletions made in the GUI do not appear in pfctl -sr, and newly added rules do not function.
Alias edits made in the GUI do not update the corresponding PF tables (pfctl -t <alias> -T show remains unchanged).
Notably, alias changes remain pending and only take effect when pfBlockerNG is toggled (disabled and re‑enabled) or the firewall is rebooted.
Disabling pfBlockerNG restores normal behavior, and re‑enabling it forces both aliases and rules to synchronize.
Impact:
This behavior prevents new or modified firewall rules from being applied in real time and leaves the system in an inconsistent state unless pfBlockerNG is manually toggled or the firewall is rebooted, which is disruptive.
This suggests that when pfBlockerNG is enabled, it interferes with or overrides the normal filter reload process, and that alias and rule updates only fully apply when pfBlockerNG performs its own reload cycle.

Clarification:
- The pfSense Plus 26.03 system is on the latest package of pfBlockerNG 3.2.16
- "Force Reload" on "All" in pfBlockerNG > Update completes, but does not help at all
The GUI saves changes correctly.
- Apply completes without error.
- However, the running PF ruleset is not updated.

Verification:
- `pfctl sr` shows no changes after apply.
`pfctl -t <alias> -T show` remains unchanged.

Isolation:
- Toggling pfBlockerNG from Enabled to Disabled or vice-versa immediately updates the PF ruleset.
- Re-enabling pfBlockerNG causes subsequent rule/alias changes to stop applying.

This indicates a PF ruleset reload interaction issue rather than expected behavior.