Bug #10691


Issue with rules (firewall and NAT) being reloaded after changes made

Added by John Weithman almost 4 years ago. Updated almost 4 years ago.

Not a Bug
Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


I have a web admin page for an email server that I've historically managed after VPN'ing into my network. I wanted to create a NAT rule (and corresponding firewall rule) that I can turn on/off as needed opposed to launching OpenVPN.

Using Chrome and if the NAT is created and enabled I can get to my login page for the service on port 7071. If I delete or disable the NAT and corresponding rules for 7071 and hit save on pfSense I can still log into the service at 7071. If I open Firefox and the NAT isn't there it works as I expect - can't get to it.

It seems like Chrome is somehow able to maintain the 7071 connection and log in even though the NAT has been disabled. It's like something isn't being flushed properly after making changes to NAT/FW rules. Haven't tried with FF or another browser.

Actions #1

Updated by John Weithman almost 4 years ago

Running 2.4.5-RELEASE-p1 (amd64)

Actions #2

Updated by Jim Pingle almost 4 years ago

  • Category set to Rules / NAT
  • Status changed from New to Not a Bug
  • Priority changed from Very High to Normal

Existing states are not cleared, and your browser is holding open a connection. You would need to close/reopen the browser or kill the states for a proper test.

Actions #3

Updated by John Weithman almost 4 years ago

A SSH connection is also held open after the NAT rule is disabled.

So if there is an unknown breach/connection active due to poor management or some other reason a firewall change will still keep their session open.

Actions #4

Updated by Jim Pingle almost 4 years ago

Yes, that's all covered by my previous note.

Kill the firewall states after making a change like that if disconnecting things is a hard requirement. It is very disruptive to do so, and won't be done automatically. The ability of `pfctl` to kill individual states is not fine-grained enough to kill just things which would be affected by a rule change.


Also available in: Atom PDF