Alias edits causing firewall rule black holes

Dakpan

I'm facing an alias bug in the PF firewall, very frustrating.

Setup simplified:
I have no floating rules and 3 rules in the firewall on my WAN interface:

Rule A: Block some abusive subnets and log this rule

SRC: Alias "Abuse_IPs_Net":* -> DST *:* -> Block

Rule B: Allow inbound smtp on public IP and log this rule

SRC *:* -> DST <NAT IP>:25 -> Allow

Rule C: Explicitly log all blocked packets, not using the default block rule

SRC *:* -> DST *:* -> Block

The alias Abuse_IPs_Net contains about 20 subnets of various sizes. When a package/mail comes from one of those subnets, the package is blocked and logged by rule A, any other mailsource is allowed and logged by rule B.

The problem
When I remove a subnet from my Abuse_IPs_Net alias and a former abuse IP tries to send us a mail, the firewall starts messing up because:

No block action is logged in rule A (Correct, it's removed from the alias)
No allowed action is logged in rule B (Wrong, should be logged here now...)
No block action is logged in rule C (And the any:any:any block doesn't log anything either)
No data from ex-abuse IP is received on the mailserver.

Does anybody have an idea why these packages are black holed now? It seems as if there is never a connection try, while there is... Moreover, a reboot of the PF box fixes the issue.
When I check out the tables in diagnostics, the removed subnet is nowhere to be found. I have no specific range defined in my NAT rule either.

Might there be a workaround? Am I just doing something wrong?

SteveITS

@Dakpan I assume you're applying after the alias change.

Check:
Diagnostics > Tables of the alias (before and after removing the IP?)
Diagnostics > Filter Reload for errors

patient0

@Dakpan what pfSense version are you using? No floating rules in play this time ;)?

Btw, referring to another thread from you back in July: floating rules are evaluated before interface rules pfSense documentation: Rules Processing Order

Dakpan

@patient0 I remember very well, thats why I started the Setup simplified with "I have no floating rules" ;)
The box having the issue is a 2.7.2 Release

Dakpan

@SteveITS you might be on to something here. The filter reload states no errors, but it stops at:
Pre-caching BLOCK ANY

While when I reload the filter on any other PF box, it ends with:
Running plugins
Done

I'll try to find out what there is about this rule first and keep you posted.
And to be complete: The tables act as expected before and after removal.

Dakpan

@SteveITS lets post the first addon right away:

The Filter Reload page stopped on a rule with this value in the description:
BLOCK ANY | No internet via this device

Apparently the refresh script crashed on the pipe character, I renamed the description to:
BLOCK ANY - No internet via this device and the Filter Reload page reached the end line Done

For now it is to soon to tell if this character messed up the filter or just the Filter Reload output.

To be continued...

SteveITS

@Dakpan is the IP in the table, though?

Dakpan

@SteveITS yes when I add a subnet to the alias it appears in the table, when I remove the subnet from the alias it disappears in the table. So that works as expected.

Dakpan

said in Alias edits causing firewall rule black holes:

@SteveITS lets post the first addon right away:

The Filter Reload page stopped on a rule with this value in the description:
BLOCK ANY | No internet via this device

Apparently the refresh script crashed on the pipe character, I renamed the description to:
BLOCK ANY - No internet via this device and the Filter Reload page reached the end line Done

For now it is to soon to tell if this character messed up the filter or just the Filter Reload output.

To be continued...

No difference, client still unable to mail. I'll start by setting up a test lab in front of the PF so I can impersonate his public IP...

Gertjan

@Dakpan said in Alias edits causing firewall rule black holes:

but it stops at:
Pre-caching BLOCK ANY

I see a lot of these Pre-caching

If your reload stops (breaks ?) at the first then changes are great that the firewall get only partially reloaded ... and that would explain strange filter results (is think I would call this a critical salutation I guess).

That said, I 'Filter reload' yesterday and didn't saw any "Pre-caching ...".

My thoughts : you have firewall rule that 'breaks' things ?

Btw : while I could find :

in my /etc/inc/filter.inc (I'm using 25.07.1)

If you have an issue, it happens around that place.

The same file on github :
pfsense/src/etc/inc/filter.inc

is way different ?!?!! (a lot of work in progress)

The github == the source, has ... a lot of recent modifications in it ...

Dakpan

@Gertjan if I run this little bit of php:

$file = 'test.txt';
file_put_contents($file, "BLOCK ANY | No internet via this device". PHP_EOL, FILE_APPEND);

The piped text is appended just fine to my testfile, so I think the script crash is more related to the code printing the contents of the filter_reload_status file.