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

    MAC address white list with masking

    Captive Portal
    2
    6
    964
    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.
    • M
      mcc_academy
      last edited by

      Short version:
      I'm attempting to whitelist every vendor MAC for certain headless devices.

      I've perused the recent thread by AndrewDuey, but that didn't seem to have a resolution and didn't involve masking.

      • The MAC whitelist works if the MAC is exact.

      • ipfw table shows up and down for each set, ie:
        b8:27:eb:ff:ff:ff/24 any 2023 0 0 0
        any b8:27:eb:ff:ff:ff/24 2022 0 0 0
        dc:a6:32:00:00:00/24 any 2025 0 0 0
        any dc:a6:32:00:00:00/24 2024 0 0 0

      • Even if the MAC is exact, and any mask is added (tried /8,/16,/24), that whitelist entry stops working. Works up until the mask is added.

      version 21.05-RELEASE on an SG-5100

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG
        Gertjan @mcc_academy
        last edited by

        @mcc_academy said in MAC address white list with masking:

        Works up until the mask is added.

        I guess the pfSense GUI isn't "aware" of the fact that MAC addresses could be 'masked' using a slah / op a & see here. look for "{ MAC | mac } dst-mac src-mac"

        I didn't even know up until now that MAC's could be masked like this.

        I'm pretty sure the pfSense manual doesn't talk about it neither, so MAC block/pass rules are 'per device' and not per group (brand) of devices.

        Guess you're good for a feature request ;)

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        M 1 Reply Last reply Reply Quote 0
        • M
          mcc_academy @Gertjan
          last edited by

          @gertjan
          It says in the software, when clicking the "i" information bubble:
          "It is also possible to add a mask value (like /24), for example, to allow all phones of a certain manufacturer to bypass the portal"

          d21ce4ef-2c80-4043-8e5f-63a8112af9a7-image.png

          Maybe the cake is a lie and that bubble needs to be redacted, I'm just trying to do what it says.

          GertjanG 1 Reply Last reply Reply Quote 0
          • GertjanG
            Gertjan @mcc_academy
            last edited by

            @mcc_academy said in MAC address white list with masking:

            I'm just trying to do what it says.

            I saw the bubble. It never really looked at it.
            But your right.

            It's a no-go for me, or, very possible I still didn't get it.

            After a

            ipfw table all list
            
            --- table(cp_ifaces), set(0) ---
            em2 2100 31319479 19843270747 1624883017
            --- table(cpzone1_auth_up), set(0) ---
            192.168.2.6/32 a4:4b:d5:cc:fe:87 2016 24894 3364078 1624883016
            192.168.2.149/32 14:c2:13:c9:1e:77 2020 286 34499 1624883012
            192.168.2.188/32 fc:de:90:dc:3c:03 2018 35487 11577008 1624880716
            --- table(cpzone1_host_ips), set(0) ---
            192.168.2.1/32 0 7445354 245891508 1624883017
            --- table(cpzone1_pipe_mac), set(0) ---
             4c:3b:df:0d:ec:31 any 2001 0 0 0
             any 4c:3b:df:0d:ec:31 2000 0 0 0
             7c:76:35:f2:a9:0e any 2005 0 0 0
             any 7c:76:35:f2:a9:0e 2004 0 0 0
             4c:8d:79:91:ec:52 any 2003 0 0 0
             any 4c:8d:79:91:ec:52 2002 0 0 0
             14:c2:13:c9:1e:00/40 any 2007 0 0 0
             any 14:c2:13:c9:1e:00/40 2006 0 0 0
            --- table(cpzone1_auth_down), set(0) ---
            192.168.2.6/32 2017 42998 51584124 1624883006
            192.168.2.149/32 2021 260 249856 1624883012
            192.168.2.188/32 2019 58761 73936635 1624881078
            --- table(cpzone1_allowed_up), set(0) ---
            188.165.53.87/32 2014 0 0 0
            192.168.2.2/32 2008 2798 1373070 1624881882
            192.168.2.3/32 2010 843 193377 1624881789
            192.168.2.4/32 2012 786 84135 1624882044
            --- table(cpzone1_allowed_down), set(0) ---
            188.165.53.87/32 2015 0 0 0
            192.168.2.2/32 2009 1544 138930 1624881882
            192.168.2.3/32 2011 365 30815 1624881789
            192.168.2.4/32 2013 163 12356 1624882044
            

            The "14:c2:13:c9:1e:77" is the MAC of my Phone.

            I set up a :

            6e7004fe-53b3-4af2-a3ec-8d670dac234b-image.png

            ( See also the firewall rules above, the /40 was acpeted )
            but when connecting the the captive portal; I had to enter my credentials as before.
            Or, with a rules like

            14:c2:13:c9:1e:00/40 any 2007 0 0 0
            any 14:c2:13:c9:1e:00/40 2006 0 0 0
            

            I was thinking that "/40" is "40 significant bits" it should pass.

            Or should we use the & like explained here.

            Side note : most (portable) devices randomize their MAC address these days.

            No "help me" PM's please. Use the forum, the community will thank you.
            Edit : and where are the logs ??

            M 1 Reply Last reply Reply Quote 1
            • M
              mcc_academy @Gertjan
              last edited by

              @gertjan
              That seems to jive with what I've been testing as well.
              I'll experiment some with the "&" syntax in that link.

              Thank you for checking and confirming the results.

              Regarding the side note...
              In my specific case, these headless devices are used in student labs and projects. The MACs on these devices are static. At any given time there's ~50 of these floating around coming on and off network, and students burn through them routinely adding more volatility to a MAC-by-MAC exception.
              After this vendor, the latest greatest thing looks like it will be nvidia SBCs, which have another small-ish range of MACs.
              Allowing by vendor is an ideal solution for me.

              M 1 Reply Last reply Reply Quote 0
              • M
                mcc_academy @mcc_academy
                last edited by

                Experimented with & on an Intel box.

                ie:
                ipfw table CaptivePortalZoneName_pipe_mac add any,04:33:C2:64:65:E1/&ff:ff:ff:00:00:00 3002
                ipfw table CaptivePortalZoneName_pipe_mac add 04:33:C2:64:65:E1/&ff:ff:ff:00:00:00,any 3003

                Running these from cmd line within pfSense seemed to soft brick it, but runs from serial shell.

                It populates in the ipfw table with the /24 syntax, which tells ipfw has some idea of what's up but maybe something wrong with their hashing?

                --- table(CaptivePortalZoneName_pipe_mac), set(0) ---
                04:33:c2:00:00:00/24 any 3003 0 0 0
                any 04:33:c2:00:00:00/24 3002 0 0 0

                Restarting the Captive Portal service does not flush the ipfw table, but I don't have a foolproof way to prove the table is "loaded and active" vs this functionality not working as documented by freeBSD?
                Router reset flushes manual entries, and in the couple minutes of ctrl+f I couldn't find the path in captiveportal.inc for the SQL db.

                I'm open to any suggestions. Have several good restore points and comfortable in the serial terminal, so I don't mind temporarily bricking something for testing purposes.

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