Firewall rule deleted via API remains active in PF ruleset - version api v2.8.3

[joaquimrbjr]

A floating firewall rule deleted through the API was removed from /cf/conf/config.xml, but remained in /tmp/rules.debug and in the active PF ruleset.

Rule details:

Type: Floating
Action: Pass
Quick: Enabled
Protocol: TCP
Source: 172.22.19.98
Destination: sg_testesub3224_e941ab16
Port: 80
Tracker ID: 1784834938

After deletion:

grep 1784834938 /cf/conf/config.xml

returned no result, but:

grep 1784834938 /tmp/rules.debug

still returned:

pass in log quick inet proto tcp from 172.22.19.98 to $sg_testesub3224_e941ab16 port 80 ridentifier 1784834938 flags S/SA keep state label "USER_RULE: Ingress: 172.22.19.98/32 → SG sg_testesub3224_e..." label "id:1784834938"

New HTTP connections continued to match this rule, so the issue was not caused only by existing firewall states.

The problem was resolved by manually running:

/etc/rc.filter_configure

This suggests that the API updated config.xml, but did not regenerate and reload the PF ruleset after deleting the rule.

Expected behavior: deleting a firewall rule through the API should update the configuration and reload the active firewall rules.

[jaredhendrickson13]

This is actually the expected behavior. In pfSense, config changes like deletions and service reloads are usually handled separately. After the rule is deleted, you can reload the filter service by making a POST request to /api/v2/firewall/apply or you can include the apply common control parameter in your DELETE request to trigger the associated service reload immediately. It is the equivalent to the 'Apply changes' button that appears in the web UI after a rule is deleted.

[joaquimrbjr]

Thanks for the clarification.

That explains exactly what I was seeing.

I assumed the DELETE endpoint would automatically trigger the equivalent of "Apply Changes", but after your explanation I reviewed my implementation and realized I'm only sending the DELETE request itself.

My application currently does:

POST /firewall/rule
DELETE /firewall/rule
(optionally) POST /firewall/apply

but I'm not using the common apply control parameter on the create/delete requests.

I'll update my client to either:

include apply=true on create/update/delete operations, or
explicitly call POST /api/v2/firewall/apply after batching multiple changes.

That matches the behavior of the Web UI's Apply Changes button.

Thanks for the explanation!

One suggestion that might help other users would be to make this behavior more visible in the API documentation. I initially interpreted the DELETE operation as immediately applying the change, while it actually only updates the configuration until an explicit apply is performed.