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

    Best practise for limiting inter LAN routing

    Scheduled Pinned Locked Moved Firewalling
    13 Posts 4 Posters 1.5k 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.
    • P
      pwnell
      last edited by

      Imagine a firewall with a WAN interface and LAN1, LAN2 and LAN3. I want:

      • LAN1, LAN2 and LAN3 can access internet
      • LAN1 can access LAN2, but not LAN3
      • LAN2 cannot access LAN1 or LAN3
      • LAN3 cannot access LAN2 or LAN1
      • A specific group if clients (Alias) on LAN1 can access LAN3

      What would be the best way to configure this? What should the inbound and outbound rules be on LAN1, 2 and 3?

      I am asking since I have configured it and it is working but I feel like I can simplify it as it is getting overly complex the more LANs I add.

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

        Firewall rules are applied to traffic that enters an interface (with some exceptions). You don't need outbound rules. You just need some rules on each LAN interface to control access to the others.

        Post a screen of all your LAN rules for each interface so we can see what's going on.

        1 Reply Last reply Reply Quote 0
        • P
          pwnell
          last edited by

          I currently have this kind of configuration on all LANs (this one maps to LAN2 in my example):

          LAN2

          Proto: IPv4+6
          Src: LAN2 net
          Port: *
          Dest: LAN1 net
          Port: *
          GW: *
          Action: Block

          Proto: IPv4+6
          Src: LAN2 net
          Port: *
          Dest: LAN3 net
          Port: *
          GW: *
          Action: Block

          Proto: IPv4+6
          Src: LAN2 net
          Port: *
          Dest: *
          Port: *
          GW: *
          Action: Allow

          I guess this is the wrong way round? By default no LAN can access any other LAN correct? Should I rather add an ALLOW on say LAN2 for src LAN1 and dest * (to allow LAN1 to access LAN2) and so on?

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

            Its much easier if you just post a picture..

            What are you rules above.. When you create another OPT network (lan2) for example - no rules will be on it.. So it wouldn't even be able to ask pfsense for dns, etc..

            Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.

            Lan1 would NEVER be a source into Lan2..

            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
            • KOMK
              KOM
              last edited by

              Yes, please post actual screenshots of your LAN1, LAN2, LAN3 rules. You can post images here directly via the Upload Image icon in the Edit toolbar.

              1 Reply Last reply Reply Quote 0
              • P
                pwnell
                last edited by

                I am confused. I understood from @KOM that I did not need outbound rules, hence the proposal of allowing src2 LAN1 on LAN2 and dest * but @johnpoz you say that will not work? What I am not understanding here? If LAN1 sends a packet destined for LAN2, what would be the source on the LAN2 interface if not LAN1?

                I had to anonymize it a bit but here you go. In this case my setup is:

                • LAN1, LAN2 and LAN3 can access internet
                • LAN1 can access LAN2, LAN3
                • LAN2 cannot access LAN1 or LAN3
                • LAN3 cannot access LAN2 or LAN1
                • A specific group if clients (Alias WaldoDevicesLAN3) on LAN3 can access LAN1

                How would this be better configured?

                LAN1

                LAN2

                LAN3

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

                  You're misunderstanding how to visualize the interfaces. Firewall rules only apply to traffic that enters an interface, which is considered inbound from the perspective of the interface. So when a LAN client sends a packet out of its local network, the pfSense LAN interface receives the packet and applies the rule to it. Once it passes the rule, it can go where its supposed to. Rules work on inbound traffic only (with some exceptions). pfSense LAN interface receives inbound traffic from LAN client. Rules process it. If allowed, the packet goes out the WAN to the Internet. Reply comes back inbound to WAN, stateful firewall automatically allows reply traffic, and the packet is forwarded out the LAN interface to the LAN client.

                  In your rules, your labels are wrong. All rules on every interface are considered inbound rules so you may as well either get rid of the banners or rename them to something that describes their function.

                  Also, unless you're actively using IPv6, I would disable it and avoid the extra rules.

                  Now for particulars...

                  In your LAN1 rules, that first rule for NTP is useless since the two rules below allow all traffic to pass anyway. Delete it.

                  For LAN2, again delete that first rule as it's unnecessary. Edit the last rule to change the protocol from TCP/UDP to Any.

                  For LAN3, again delete that NTP rule.

                  1 Reply Last reply Reply Quote 0
                  • P
                    pwnell
                    last edited by

                    Thanks for the response. I do understand the basics that the firewall acts on inbound traffic and understand the orientation of the interfaces - i.e. that the terminology in/out is from the perspective of the firewall.

                    The NTP rule is indeed unnecessary but it is a relic from other changes I made a while ago - not really important for this discussion.

                    So what should the label read? I have it "Catch all block LAN3 to LAN1" for instance on LAN3. Is "Block traffic destined for LAN1" better?

                    Is the basic approach of having a catch all whitelist rule at the bottom (for internet access) and blocking those destined for LANs not allowed before them correct though?

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

                      @pwnell said in Best practise for limiting inter LAN routing:

                      Is the basic approach of having a catch all whitelist rule at the bottom (for internet access) and blocking those destined for LANs not allowed before them correct though?

                      Yes.

                      Do yourself a favor and change them to reject rules though to clients trying to connect get immediate feedback instead of just hanging and timing out.

                      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
                      • P
                        pwnell
                        last edited by

                        One last question on this topic - how best to deal with scaling. If I have say 10 LAN interfaces, LAN1.. LAN10, and say LAN1 can have access to LAN2..LAN10, but LAN2..LAN10 cannot access each other or LAN1, there will be 10 rules per interface (one allow for internet, 9 reject for the other LAN interfaces) meaning there will be 100 rules in total across the 10 interfaces.

                        Would this better be implemented with floating rules? If so, how would that rule(s) look like?

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

                          While you might be able to cobble something together with floating rules, I find that rules on each interface are much easier to read and understand. While it's more work, it's easier to get it right.

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

                            In many cases you can just make an alias for RFC1918 addresses or all local subnets and block all traffic to that.

                            You'll have to pass traffic to things like local DNS servers.

                            As long as you pass anything on the firewall that they need to access first there is no harm in having a rule that blocks connections to the interface subnet because the firewall won't see that traffic anyway.

                            That said, maintaining a firewall with a lot of interfaces is sometimes work to get set up.

                            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
                            • P
                              pwnell
                              last edited by

                              Thanks for all the advice, much appreciated.

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