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

    Blocking Inter VLAN Traffic

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 3 Posters 2.3k 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.
    • F Offline
      fips
      last edited by

      Hey Guys,

      I am currently configuring a new pfsense and have a small problem:
      I created 2 VLANs (105 and 110) with Networks 10.1.105.0 and 10.1.110.0.

      On the VLAN105 I created following rules:
                    Prot.      Source    Port  Dest.              Port GW
      1. Block  IPv4*  VLAN105net  *  ManagementLAN  *  *
      2. Allow  IPv4*  VLAN105net  *  VLAN105net        *  *
      3. Block  IPv4*  VLAN105net  *  10.1.0.0/16          *  *
      4. Allow  IPv4*  VLAN105net  *  *                        *  *

      On the VLAN110 is just a simple:
      Allow IPv4*  VLAN110net * * * *

      My question:
      Why a client (10.1.110.101) inside VLAN110 can ping a client (10.1.105.101) in VLAN105?
      Of course I could create a rule for interface VLAN110, but should the 3. rule not block the echo reply??

      Even when I add a "Block any any" rule and move it to the top, the ping from VLAN110 to VLAN105 is successfully.

      Can you give me a hint?

      Thanks
      Stefan

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

        your 2 rule is completely pointless btw.

        And NO rule 3 does not stop 105 from answering something on 110, since 110 is opening the state which was allowed.. Rule 3 would block 105 from creating connections, but it does not stop it from answering something that created a state.

        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 25.07.1 | Lab VMs 2.8.1, 25.07.1

        1 Reply Last reply Reply Quote 0
        • F Offline
          fips
          last edited by

          Thanks for your reply.

          Well without rule 2 my client (10.1.105.1) can't ping the his GW (10.1.105.1) in his Subnet.

          OK I understood about opening the state.
          Would there be a possibility to prevent this from the side of VLAN105??

          Of course I added now the same rules on VLAN110 and it can't reach VLAN105 anymore.
          I am just curious, thats why I asked.

          Best wishes

          1 Reply Last reply Reply Quote 0
          • C Offline
            CC
            last edited by

            Well you might be able to block it on 105 by building a specific ICMP / Echoreply but it's still not the point, if you want to isolate the vlans then you are best of building a VLAN alias group containing all your VLAN subnets (or just your /16) and then put a floating VLAN to VLAN alias block rule (with any allowed connections above), or put a VLAN drop rule in your 110 interface.
            Even if you block ping back you won't be blocking UDP etc.

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

              that might be the only rule allowing you access to pfsense IP on that network, but the rule is written wrong.. If you want to allow access to pfsense 105 address then do so.  Pfsense has no control if clients on the 105 talk to other clients on the 105 so that rule makes no sense..

              Why would you want to block it from the 105..  You block traffic at the interface it comes in on… If you don't want network x talking to something then you block it interface x where the traffic first enters the firewall..  Its kind of pointless to let the traffic into the firewall, and make the firewall do work on that traffic just to not let it out some interface it wants to go with an outbound rule via the floating tab.

              Its more efficient to just drop the packet where pfsense first sees it, which would be the interface it comes in on..

              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 25.07.1 | Lab VMs 2.8.1, 25.07.1

              1 Reply Last reply Reply Quote 0
              • C Offline
                CC
                last edited by

                To be fair to him there, rule 3 blocks the /16 that the firewall is on so he's right in that he needs that to be able to ping the firewall, a more secure way is to allow just echoreq to the VLAN interface direct (everything else on the VLAN will be reachable anyhow by being in the same broadcast domain).

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

                  No he doesn't need that… What he needs is the correct rule which would be to the firewalls interface address.  Not the network..

                  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 25.07.1 | Lab VMs 2.8.1, 25.07.1

                  1 Reply Last reply Reply Quote 0
                  • F Offline
                    fips
                    last edited by

                    @johnpoz:

                    No he doesn't need that… What he needs is the correct rule which would be to the firewalls interface address.  Not the network..

                    Of course you are completely right ;-)

                    I changed 3. rule destination to VLAN105address.

                    Thanks a lot

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