MAC address white list with masking

mcc_academy

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

Gertjan

@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 ;)

mcc_academy

@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"

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

Gertjan

@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 :

( 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.

mcc_academy

@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.

mcc_academy

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.