New NAT rule includes by default an associated rule, why & can this be changed?

[GHvM]

When you create a new NAT rule, it is by default set to create an associated rule.
This is only desirable if you have a very basic firewall and want to allow access from everywhere.

Firewalls, though, are usually used to limit access from specific locations (or other specific attributes of the connection), not allow connections from everywhere.
Connections from everywhere are very limited in firewalls used for business production environments.

My question is why is it by default that an associated rule is selected (which is apparently rarely used) and how can this behavior be changed?
It is a setting we never (want to) use and the default is wrong, so it is often the case we do not change the setting when adding/editing rules (it is not part of the process and it should not be necessary).
Another problem with this setting is that whenever an existing rule is copied, this is reset to associated rule, even if the original rule that was copied had a different setting (like none, our default, if we could help it).
Especially the last thing is simply a bug and does not help the case of this setting having any right to exist.

If you want to configure firewalls correctly, you need to know what functionality is doing what exactly.
Even with advanced tools like pfSense that makes it easily accessible you should still know what you are doing.
By combining the NAT and filter rules like this, you enable incompetent administrators to do things they should not be doing.
It would not be the first time a client's administrator inadvertently opens one's network up to all kinds of internet-nastiness, because one does not really know what one is doing, but pfSense enables one to do it anyway.

[KOM]

My question is why is it by default that an associated rule is selected (which is apparently rarely used) and how can this behavior be changed?

What makes you think it's rarely used??  The associated filter rule is created by default because otherwise you would have a lot of people complaining that their NAT doesn't work because they didn't create the required firewall rule.  For the VAST majority of use cases, a basic allow rule on WAN is all that's needed , and that is why it's the default.  Your use case may vary, but that doesn't mean the defaults are wrong.  It might be nice to assume that everyone who uses pfSense is a networkng expoert, but after supporting these forums for a few years I can tell you that's definitely not the case.

If the default behaviour isn't for you, then change the Filter rule association to something else when you create your NAT.

[johnpoz]

^ exactly.. You can also just edit the rule if you want to limit the source IPs, etc..

KOM hit it right on the head here..  If that was not the default users would have no clue why their port forwards don't work..  Quite often they undo the default of the rule anyway, or they don't move the rule up in the wan interface and they have some other rule that blocks it anyway, etc..

There is a vast amount of users of pfsense that have just graduated from your typical off the shelf home wifi router..  If you don't want it to create your rule for you, its a simple click when your creating your port forward/nat for it not to do that..

[hda]

@GHvM:

It would not be the first time a client's administrator inadvertently….

Good default practice, for many an administrator, is working with ACL's.

[kpa]

Really, what good is a port forward RDR rule without a matching firewall rule? Why would you add such port forward if you're not going to use it for real?

[Derelict]

And if you don't want the filter rule generated turn it off here: