Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved NAT
    6 Posts 6 Posters 989 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      GHvM
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator
          last edited by

          ^ 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..

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 0
          • H
            hda
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • K
              kpa
              last edited by

              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?

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

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

                ![Screen Shot 2016-12-14 at 5.14.32 PM.png](/public/imported_attachments/1/Screen Shot 2016-12-14 at 5.14.32 PM.png)
                ![Screen Shot 2016-12-14 at 5.14.32 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-12-14 at 5.14.32 PM.png_thumb)

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.