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

    Correct Rule To Allow LANs -> WAN, but block LAN -> LAN

    Scheduled Pinned Locked Moved Firewalling
    12 Posts 4 Posters 4.8k 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.
    • K
      kathampy
      last edited by

      What is the correct rule to allow traffic from LAN1 and LAN2 to the Internet through WAN, but not allow LAN1 and LAN2 to communicate? Is simply forcing the rules' gateways to WAN sufficient or will this cause some kind of inefficiency when LAN1 to LAN2 communication is attempted?

      
      Interface: LAN1
      Source: LAN1 Subnet
      Destination: *
      Gateway: WAN
      Action: Allow
      
      Interface: LAN2
      Source: LAN2 Subnet
      Destination: *
      Gateway: WAN
      Action: Allow
      

      Will this block LAN1 to LAN2 communication at pfSense itself since the gateway is forced to WAN and pfSense thinks it is the only router between LAN1 & LAN2, or will it forward all LAN destined packets to the WAN gateway (it is a separate router and not on pfSense itself) and flood it?

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        You should NOT set any gateways on LAN.

        Interface: LAN1
        Source: LAN1 Subnet
        Destination: ! LAN2 Subnet
        Action: Allow

        and vice versa.

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

          I want to avoid explicit deny rules. If I add a new interface in the future, such a rule will allow traffic to it unless I remember to deny it as well. Since pfSense blocks by default, I just want a rule that allows only LAN1/2 to WAN. I set a gateway WAN specifically because I have multi-WAN.

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            There is no explicit deny rule. You allow LAN1 to everything but LAN2 subnet and the other way round. Setting GW for LAN is outright broken. Other than that, not really willing to work with perpetually moving targets, such as your edited first post stating that pfSense is not really a WAN router any more, or that your have a multiWAN out of the blue now, sorry. Without network diagram there's nothing to work with in the first place after you've totally redesigned your setup.

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

              @doktornotor:

              There is no explicit deny rule. You allow LAN1 to everything but LAN2 subnet and the other way round. Setting GW for LAN is outright broken. Other than that, not really willing to work with perpetually moving targets, such as your edited first post stating that pfSense is not really a WAN router any more, or that your have a multiWAN out of the blue now, sorry. Without network diagram there's nothing to work with in the first place after you've totally redesigned your setup.

              Please… It was edited 3 hours before you even replied.

              I don't wan't to keep adding !LAN1 and !LAN2 etc. to each Internet access rule as I may add more LANs later.

              Setting a gateway is broken? How do you suppose people route LAN1 through WAN1 and LAN2 through WAN2?
              WAN is not even my default gateway on pfSense so it has to be set explicitly to route LANs to the Internet.

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                So make use of aliases instead. (And no, they will NOT grow automagically either with new interfaces added.)

                Other than that, as said, without a networking diagram there's no point in debating your unknown setup.

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

                  Explicit denies like !LANx or !Alias are not acceptable and are a security hole waiting to happen. There's a reason firewalls block unmatched rules by default.

                  The minimal information provided in the first post is sufficient to answer the question, which you are unable to do. LAN1 & LAN2 -> WAN without LAN1 <-> LAN2 is the only requirement. Nothing else is relevant. No beginner's rules like !LAN1 and !LAN2.

                  1 Reply Last reply Reply Quote 0
                  • D
                    doktornotor Banned
                    last edited by

                    OK, bye, Mr. Expert… enough time wasted here.

                    1 Reply Last reply Reply Quote 0
                    • L
                      lsf
                      last edited by

                      The rule you are looking for is: allow from lan1-subnet destination ! Lan2-subnet. And another one like it from lan2–> lan1

                      -lsf

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

                        @lsf:

                        The rule you are looking for is: allow from lan1-subnet destination ! Lan2-subnet. And another one like it from lan2–> lan1

                        Yes, but if another interface is ever plugged in, then traffic from LANs will automatically be allowed to it until I explicitly block it! Isn't that dangerous?

                        1 Reply Last reply Reply Quote 0
                        • GruensFroeschliG
                          GruensFroeschli
                          last edited by

                          @KurianOfBorg:

                          Explicit denies like !LANx or !Alias are not acceptable and are a security hole waiting to happen. There's a reason firewalls block unmatched rules by default.

                          The minimal information provided in the first post is sufficient to answer the question, which you are unable to do. LAN1 & LAN2 -> WAN without LAN1 <-> LAN2 is the only requirement. Nothing else is relevant. No beginner's rules like !LAN1 and !LAN2.

                          The trick is to not use explicit denies, but to use explicit allows.
                          Since there is a default block rule after all your own rules, traffic not explicitly allowed will always be blocked.
                          Create an alias containing all the local subnets. An RFC1918 alias containing all the private subnets is usually a pretty safe approach.
                          See the attached screenshot how such a rule would look like.
                          With this you explicitly allow everything not private.

                          Btw: i wouldn't call the approach of using inverse aliases "not acceptable and a security hole waiting to happen"….
                          It all comes down to how you design your rules.

                          allow_rule.png
                          allow_rule.png_thumb

                          We do what we must, because we can.

                          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

                            @GruensFroeschli:

                            Create an alias containing all the local subnets. An RFC1918 alias containing all the private subnets is usually a pretty safe approach.

                            Thanks, this is great. !RFC1918 is definitely safer than !LAN1 or !LAN2 because there's no risk if an additional interface is added later since its subnet will already be covered.

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