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

    Allow traffic between subnets

    General pfSense Questions
    3
    11
    4.2k
    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.
    • D
      daq
      last edited by

      I have 2 interfaces (LAN and OPT1.) LAN is 192.168.1.0/24. OPT1 is 192.168.2.0.24. In firewall rules I allowed traffic from both subnets on both interfaces. Firewall logs show traffic is allowed, but communications still fail. How do I set up routing to allow, for example, 192.168.1.10 to talk to 192.168.2.10?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        There is no special requirement, you only need the correct firewall rules in place. The default LAN to any rule should allow access to opt1 from LAN without changing anything.
        How are you testing? What rules do you have in place?

        Steve

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

          I run the same setup with the same address space and there is nothing you need to do other than allow in firewall

          What are you rules on your opt1 interface.  You do have devices on the opt1 network pointing to the pfsense opt1 IP as their gateway, these would be really the only requirements.

          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.7.2, 24.11

          1 Reply Last reply Reply Quote 0
          • D
            daq
            last edited by

            OPT1 interface is a separate VLAN. Could that make a difference?

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

              If you creating vlans then yes could be causing you your problems

              Why do you need a vlan if your interface is on different segment, do you need to tag it for some reason..  Is it connected to a switch port in trunk mode?

              What exactly are you wanting to accomplish?  You have 2 network segments - why do you need vlan?

              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.7.2, 24.11

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                Is your LAN interface also a VLAN?

                Steve

                1 Reply Last reply Reply Quote 0
                • D
                  daq
                  last edited by

                  OPT1 is connected to an access point that tags traffic based on SSID. One SSID is guest network that only needs access to WAN (VLAN 50.) The other is should really be a bridge to LAN, but my understanding is that bridge with LAN is out of the question because of VLAN so I figured pfSense can just route between subnets if I set it up as a completely different interface.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    You should be able to bridge LAN to another interface no problems even if that interface is the parent of another vlan.
                    So you have 3 NICs in your pfSense box?
                    Maybe time for some screenshots of your setup.

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • D
                      daq
                      last edited by

                      Here's the layout:
                      WAN (BGE0) - Public IP
                      LAN (BGE1) -192.168.1.0/24
                      WiFI (BCE0) - 192.168.2.0/24
                      WiFi Guest (BCE0/VLAN50) - 192.168.3.0/24

                      I didn't want to mix tagged and untagged traffic, but I can't figure out a better way to do this without a managed switch and that won't arrive for some time.

                      I attached screenshot of firewall rules for LAN and WiFi interfaces.

                      ![WiFi Rules.PNG](/public/imported_attachments/1/WiFi Rules.PNG)
                      ![WiFi Rules.PNG_thumb](/public/imported_attachments/1/WiFi Rules.PNG_thumb)
                      ![LAN Rules.PNG](/public/imported_attachments/1/LAN Rules.PNG)
                      ![LAN Rules.PNG_thumb](/public/imported_attachments/1/LAN Rules.PNG_thumb)

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Well that all looks ok. How are you testing this?
                        Are your wireless clients correctly receiving IP info from pfSense via dhcp?

                        You can probably put both ssids on a vlan so you aren't mixing tagged and untagged traffic but I'd wait to get this working first.

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • D
                          daq
                          last edited by

                          I wasn't testing correctly. Communication does work. Thanks to everyone for help.

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