Firewalling MAC addresses
-
Look, it's simple: pfsense uses 'pf' to firewall.
'Pf' doesn't support mac filtering.So the only way to implement it, is to ask the developers of 'pf' to include it.
-
pfSense also uses ipfw for the captive portal, which is why you can pass machines through the cp by mac address. One might be able to hack a script together that would call ipfw and block the offending macs and launch the script via shellcmd. This is unsupported and might not work, just something for the interested reader to investigate. See https://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html
-
Trying to summarize what I'm reading here…
-
pfSense already "violates" the L2/L3 boundary in several different ways.
-
The freeBSD port of openBSD's "pf" can't touch L2, but freeBSD's native "ipfw" can (and ipfw is already available in PF via the captive portal functionality.)
-
pfSense already makes at least some use of "ipfw" for some captive portal functionality.
So.. what is the reason for any opposition to adding MAC address filtering to the web UI?
-
-
opposition? i don't think you should look at it that way.
it looks like a lot of work & it'll be a mess to combine both pf & ipfw (it already is with CP). Getting it work reliably across versions will increase the required testing.so a lot of work & limited use case for the majority of the users means that its unlikily to be first in line to get adressed.
when an issue or feature is deemed to be low priority, it could take years or decades before someone looks at it, because there are always more urgent matters to attend. -
Trying to summarize what I'm reading here…
-
pfSense already "violates" the L2/L3 boundary in several different ways.
-
The freeBSD port of openBSD's "pf" can't touch L2, but freeBSD's native "ipfw" can (and ipfw is already available in PF via the captive portal functionality.)
-
pfSense already makes at least some use of "ipfw" for some captive portal functionality.
So.. what is the reason for any opposition to adding MAC address filtering to the web UI?
Pfsense is community driven and on github. You can request that the feature is added or add the functionality yourself and make a pull request.
We are trying to help and be realistic here with your requests….. Why is it necessary to be confrontational?
-
-
I just discovered that pfsense cannot do L2 filtering.
I'm new to the BSD universe but I'm used to iptables, so I was wrongly assuming that MAC filtering was easyI confirm that IPV6 is a mess: I have a linux server that refuses to disable privacy extensions and route advertising, so actually it's using 8 different ipv6 addresses!
Android is not compatible with dhcp6 and has privacy extensions enabled.I have several semipro security camera with embedded linux and ipv6 support. I don't want they can call home so I blocked their ipv4 address but I'm not sure how many ipv6 addresses they can use (the gui shows only the mac-calculated address).
-
I just discovered that pfsense cannot do L2 filtering.
I'm new to the BSD universe but I'm used to iptables, so I was wrongly assuming that MAC filtering was easyI confirm that IPV6 is a mess: I have a linux server that refuses to disable privacy extensions and route advertising, so actually it's using 8 different ipv6 addresses!
Android is not compatible with dhcp6 and has privacy extensions enabled.I have several semipro security camera with embedded linux and ipv6 support. I don't want they can call home so I blocked their ipv4 address but I'm not sure how many ipv6 addresses they can use (the gui shows only the mac-calculated address).
Your only hope is to just completely disable all routing of ipv6 on the LAN segment those cameras are on. You could also block traffic going to wherever the cameras are trying to talk, but I've found that trying to block like that is a never ending battle of changing IP addresses and DNS pools.
-
This post may be of interest to the OP and others:
https://forum.pfsense.org/index.php?topic=116291.msg644789#msg644789
Javier is doing some cool stuff, but most of it seems to happen on the Spanish board. I'm glad he shared this with us. -
What would be interesting, at least to me, is to understand why you would want to implement FW rules based on MAC address. This is something I don't understand yet
To ensure a device cannot get out, no matter what it's IP address. Filtering on incoming MACs would be pretty much useless though, as you'll only see the MAC for the ISPs router.
-
Routers only route between Layer 3 (IP addresses).
pfSense is also a firewall and can filter on layer 4 (TCP & UDP ports etc.) as well as 3. Other firewalls have no problem filtering on MAC addresses. For example, for many years I used the firewall in openSUSE. It could filter on MACs, as can at least some models of Cisco routers. A firewall does more than just route (there are also firewalls that do not route). They examine the various characteristics of the packets, be they layer 2, 3, or 4 and make decisions based on those characteristics. As for IPv6, many devices have random number based addresses that cannot be (easily) disabled. In this case, filtering on IP address is not an option, but filtering on MAC should be.
-
After reading a few threads on firewall rules based on MAC addresses, I figure I would post my use case here on why I would want such a feature.
I have a virtual lab on one of my machines that I am creating and destroying Vms all the time. While I want a set of Vms to have access to my local physical network services such as NAS, I want silently block those VM's from autoupdating from the Inter-webs. I do use snapshots and restore liberally but I would have to fastidiously monitor for any change to the OS or other apps to be sure my
tests are not tainted.Insuring my VMs use a range of MAC addresses and firewalling them at the LAN allows me to consume internal services and watch for
DNS resolves or direct IP attempts for updates on those VMs.Thoughts ?
- Joe
-
My use case: denying IPv6 entirely to certain Android devices (post).
Currently using a separate WAP+interface to create an IPv4-only subnet. -
…so a lot of work & limited use case for the majority of the users...
I know this is a relatively old thread, but I think this comment misses the point entirely.
MAC address filtering is only of limited use case for the majority of users today, because the majority of users are still using IPv4 and MAC based filtering gives them nothing they need..
As users transition to IPv6, it will become the major use-case. Because, for practical purposes, with IPv6 a rules-based system that uses IP addresses does not work.
This means pfSense will increasingly become ineffective as a network security device and people will stop using it. I'm sure none of us want that!
Cheers,
Keith
-
Continuing the discussion on implementation challenges…
If pf does not support MAC based filtering then this, indeed, does present issues. However, I will point out that MAC based filtering, at the low-level, isn't necessarily required.
What is required, to support IPv6, is "MAC-specified" filtering. That is to say, the ability to specify the device or devices to be filtered by MAC address. This could then be dynamically translated into an equivalent IPv6 (e.g. using information from the NDP) before being pushed into pf. This would obviously require regular updates (perhaps driven from NDP updates). It would be roughly analogous to specifying hosts by URL or DNS name.
Of course, this would not be trivial, but it sounds a lot less problematic than trying to mix ipfw and pf rules.
Cheers,
Keith
-
I was quite surprised when I learned that the BSD iptables equivalent, pf, does not support L2 filtering. Until now I assumed this was possible the same way it is with iptables. However, I agree that there are some situations in which L2 filtering is helpful even though regular firewalls are supposed to work on L3. I've used MAC filters in the past with other firewalls and it worked as expected. In this thread it's the same as in others, people try to reason away the need for L2 filters on firewalls alltogether, but that does not solve the problem. People try to accomplish the same things with pfsense they have been doing with iptables for years, and that's completely legitimate.
I suggest to consider L2 MAC filtering a feature request for future releases of pfSense. To keep things easy, I would not mix L3/L2 in the firewall roules but rather suggest to implement a separate chain for MAC filters independent of the pf rules.
-
Hello,
I'm following up this thread.
Did someone find a way to block a MAC address (without IP reservation that will be easy to bypass ) ?Thanks
-
"(without IP reservation that will be easy to bypass ) ?"
So you think changing a mac address is difficult? Takes .2 seconds to set a different mac address.
-
"(without IP reservation that will be easy to bypass ) ?"
So you think changing a mac address is difficult? Takes .2 seconds to set a different mac address.
In fact, it's easier than changing the IP address, as you don't need to access pfSense, just the computer.
-
if your really worried you could always enable static arp.. Now someone trying to change and IP to get around a block would not be able to talk to pfsense from that different IP.
-
"(without IP reservation that will be easy to bypass ) ?"
So you think changing a mac address is difficult? Takes .2 seconds to set a different mac address.
I'm just saying that this is more easy for a basic user (99.9% of my customers) to change his IP than change his MAC address.
But I didn't want to debate on this because each situation and each need is different.Just wanted to know if someone finds a way to do that with pfSense.
