Firewalling MAC addresses
-
Firewalls route over layer 3 (ip addresses), not necessarily MAC addresses (layer 2) what are you trying to do exactly?
-
Basically, I'm trying to create firewall and/or routing rules that refer to specific known interfaces (machines) on the network. The LAN is dual stack IPv4 and IPv6. Because of the IPv6 element, I can't depend on knowing IP numbers in advance. (See original post concerning the uselessness of DHCPv6.)
Some things that might be useful:
Block machine A from WAN access for a span of time (via a scheduled rule)
Block machine A from any particular route/path/etc.
Pass traffic from machine B (only) to a IPv6 uPnP daemon on the pfSense box (instead of the rule allowing the entire LAN to access it)
…Pretty much any other rule that needs to refer to a single machine on the LAN and might encounter both ipv4 and ipv6 traffic.
Some of these things can be "solved" using other methods. For example, I could (in theory) add vlans to prevent traffic between machines. However, does it really make sense to create a new vlan for each and every rule? What if the machine's interface is untagged and already belongs to a vlan? Also, vlans would create new problems (such as blocking desirable broadcast traffic.)
-
Basically, I'm trying to create firewall and/or routing rules that refer to specific known interfaces (machines) on the network. The LAN is dual stack IPv4 and IPv6. Because of the IPv6 element, I can't depend on knowing IP numbers in advance. (See original post concerning the uselessness of DHCPv6.)
Some things that might be useful:
Block machine A from WAN access for a span of time (via a scheduled rule)
Block machine A from any particular route/path/etc.
Pass traffic from machine B (only) to a IPv6 uPnP daemon on the pfSense box (instead of the rule allowing the entire LAN to access it)
…Pretty much any other rule that needs to refer to a single machine on the LAN and might encounter both ipv4 and ipv6 traffic.
Some of these things can be "solved" using other methods. For example, I could (in theory) add vlans to prevent traffic between machines. However, does it really make sense to create a new vlan for each and every rule? What if the machine's interface is untagged and already belongs to a vlan? Also, vlans would create new problems (such as blocking desirable broadcast traffic.)
The best idea I have for you is to setup a static IPv4 and IPv6 address for a specific MAC address and client ID respectively, and then block those addresses.
Firewalls do not route based on MAC Address…. only IP (layer 3)
-
The best idea I have for you is to setup a static IPv4 and IPv6 address for a specific MAC address and client ID respectively, and then block those addresses.
Using a static IP worked for IPv4. It doesn't work for IPv6 where clients generate new IPv6's dynamically for internet traffic (so called "privacy extensions") Some OS's also block the ability to create static IPv6 addresses. (They shouldn't be needed with SLAAC.)
I also find it hard to believe that a network router/firewall would require modifications to specific client systems in order to be effective. It's the router/firewall that should handle the rules, not the workstations.
I REALLY, REALLY hope that the authors of pfSense aren't stuck in this "it's not supported now so no one should ever need it" mentality. There was a time when man didn't know how to create fire. If we refused to learn how to, we'd probably be extinct by now.
-
The best idea I have for you is to setup a static IPv4 and IPv6 address for a specific MAC address and client ID respectively, and then block those addresses.
Using a static IP worked for IPv4. It doesn't work for IPv6 where clients generate new IPv6's dynamically for internet traffic (so called "privacy extensions") Some OS's also block the ability to create static IPv6 addresses. (They shouldn't be needed with SLAAC.)
I also find it hard to believe that a network router/firewall would require modifications to specific client systems in order to be effective. It's the router/firewall that should handle the rules, not the workstations.
I REALLY, REALLY hope that the authors of pfSense aren't stuck in this "it's not supported now so no one should ever need it" mentality. There was a time when man didn't know how to create fire. If we refused to learn how to, we'd probably be extinct by now.
Garyd9, this is a OSI Ethernet (layer 1 to 7) issue: https://en.wikipedia.org/wiki/OSI_model
You are asking to block based on Layer 2 (MAC Address), which is handled by switches. Routers only route between Layer 3 (IP addresses). There is no such thing as routing over MAC addresses (layer 2)
The compounding issue is that Windows has IPv6 privacy extensions enabled, which creates random Client IDs. This is why you cannot assign a static IP to these clients.
If you want to block those machines, turn off privacy extensions on those clients.
Another alternative is to block all hosts, ipv6 or ipv4, and only allow specific IPv4/IPv6 addresses. You can then staticly assign IPv4 and IPv6 addresses to the MAC/Client IDs that you would like to pass through the router.
-
Here we go…
You are asking to block based on Layer 2 (MAC Address), which is handled by switches. Routers only route between Layer 3 (IP addresses). There is no such thing as routing over MAC addresses (layer 2)
First, your ignoring that pfSense is advertised as a router AND A FIREWALL. Second, you're also ignoring that pfSense already has several L2 mechanisms already, including vlan tagging, LAGG, bridging, etc.
Using your logic, pfSense should remove any explicit vlan and bride support and just tell users to use their switch for that. Personally, I think that's a bad idea, just as I think that pfSense not including any L2 filtering support is a bad idea. The "because it's a L3 device" argument is old, tired, and irrelevant. Software frequently crosses OSI layers to accomplish tasks…
BTW, my L2 managed switch doesn't have any firewall type functionality. It's a switch, not a firewall. On the other hand, it does include some very basic (and barely functional) L3 VLAN routing (for IPv4 only.)
The compounding issue is that Windows has IPv6 privacy extensions enabled, which creates random Client IDs. This is why you cannot assign a static IP to these clients.
If you want to block those machines, turn off privacy extensions on those clients.
Oh.. and also the Mac clients? What about Android devices that ignore DHCPv6 completely and have no provision for configuring a static IPv6? Is it your expectation that a network admin should have to manually reconfigure every single device connected to a network and ban all devices that can't be manually reconfigured because of a limitation on a single firewall?
Doesn't this seem backwards to anyone other than me? Isn't one of the reasons for a gateway, DHCP, etc so that we don't have to screw around with every possible client device manually?
Another alternative is to block all hosts, ipv6 or ipv4, and only allow specific IPv4/IPv6 addresses. You can then staticly assign IPv4 and IPv6 addresses to the MAC/Client IDs that you would like to pass through the router.
Are you really suggesting this as a solution? When the nose on your face itches, do you shove a thermonuclear device up your nose and explode it to stop the itching?
I'm 100% willing to listen and learn of ways to USE THE ROUTER/FIREWALL to solve the problems listed above if they are reasonable and/or better than the proposed solution of MAC filtering. So far, however, people are only suggesting things that would require massive amounts of work, or are huge downgrades to the network.
Telling people that if they want decent security they have to manually configure every single device by hand and/or block entire categories of devices is neither reasonable nor better.
I'm trying to make a suggestion to IMPROVE pfSense. Apparently, a large part of that will just be getting people to get past the "this is the way it's always worked" mentality.
A bit about myself: I'm a professional software engineer…. I have over 25 years of experience, and have worked on embedded systems as well as desktop systems. Currently, my language of choice is C/C++. Why does that matter? Because in my line of work, when I find a problem that I can't reasonable solve in the language I'm using, I go to a LOWER level for the solution. With C, that means a bit of inline assembly (or entire modules written in assembly.) This can be applied to the problem of creating rules for interfaces: There seems to be no reasonable solution in layer 3. However, there's a very reasonable solution in layer 2.
Now, I will admit that I'm not familiar with freeBSD, so I had to do a bit of research to figure out WTF "pf" is. If "pfSense" is 100% based on the OpenBSD port of "pf" to freeBSD, then the answer here might be very simple (and unhappy): "pf" isn't capable of doing any layer 3 filtering. From what I can find on google, it's one of the main reasons that many people suggest using "ipfw" over "pf" in freeBSD. If this is all true (and I don't know that it is), then it might simply be that the engine driving the rules in pfSense isn't capable of L2. (Google results tend to be mixed on results of mixing pf with ipfw.)
I'd think that would be a major shortcoming in the product - especially with IPv6 gaining traction... it would be nearly impossible to have a reasonable IPv6 network and filter any traffic coming from specific internal devices.]
-
Here we go…
You are asking to block based on Layer 2 (MAC Address), which is handled by switches. Routers only route between Layer 3 (IP addresses). There is no such thing as routing over MAC addresses (layer 2)
First, your ignoring that pfSense is advertised as a router AND A FIREWALL. Second, you're also ignoring that pfSense already has several L2 mechanisms ready, including vlan tagging, LAGG, bridging, etc.
Using your logic, pfSense should remove any explicit vlan and bride support and just tell users to use their switch for that. Personally, I think that's a bad idea, just as I think that pfSense not including any L2 filtering support is a bad idea. The "because it's a L3 device" argument is old, tired, and irrelevant. Software frequently crosses OSI layers to accomplish tasks…
BTW, my L2 managed switch doesn't have any firewall type functionality. It's a switch, not a firewall.
The compounding issue is that Windows has IPv6 privacy extensions enabled, which creates random Client IDs. This is why you cannot assign a static IP to these clients.
If you want to block those machines, turn off privacy extensions on those clients.
Oh.. and also the Mac clients? What about Android devices that ignore DHCPv6 completely and have no provision for configuring a static IPv6? Is it your expectation that a network admin should have to manually reconfigure every single device connected to a network and ban all devices that can't be manually reconfigured because of a limitation on a single firewall?
Doesn't this seem backwards to anyone other than me? Isn't one of the reasons for a gateway, DHCP, etc so that we don't have to screw around with every possible client device manually?
Another alternative is to block all hosts, ipv6 or ipv4, and only allow specific IPv4/IPv6 addresses. You can then staticly assign IPv4 and IPv6 addresses to the MAC/Client IDs that you would like to pass through the router.
Are you really suggesting this as a solution? When the nose on your face itches, do you shove a thermonuclear device up your nose and explode it to stop the itching?
I'm 100% willing to listen and learn of ways to USE THE ROUTER/FIREWALL to solve the problems listed above if they are reasonable and/or better than the proposed solution of MAC filtering. So far, however, people are only suggesting things that would require massive amounts of work, or are huge downgrades to the network.
Telling people that if they want decent security they have to manually configure every single device by hand and/or block entire categories of devices is neither reasonable nor better.
I'm trying to make a suggestion to IMPROVE pfSense. Apparently, a large part of that will just be getting people to get past the "this is the way it's always worked" mentality.
A bit about myself: I'm a professional software engineer…. I have over 25 years of experience, and have worked on embedded systems as well as desktop systems. Currently, my language of choice is C/C++. Why does that matter? Because in my line of work, when I find a problem that I can't reasonable solve in the language I'm using, I go to a LOWER level for the solution. With C, that means a bit of inline assembly (or entire modules written in assembly.) This can be applied to the problem of creating rules for interfaces: There seems to be no reasonable solution in layer 3. However, there's a very reasonable solution in layer 2.
Now, I will admit that I'm not familiar with freeBSD, so I had to do a bit of research to figure out WTF "pf" is. If "pfSense" is 100% based on the OpenBSD port of "pf" to freeBSD, then the answer here might be very simple: "pf" isn't capable of doing any layer 3 filtering. From what I can find on google, it's one of the main reasons that many people suggest using "ipfw" over "pf" in freeBSD. If this is all true (and I don't know that it is), then it might simply be that the engine driving the rules in pfSense isn't capable of L2.
I'd think that would be a major shortcoming in the product - especially with IPv6 gaining traction... it would be nearly impossible to have a reasonable IPv6 network and filter any traffic coming from specific internal devices.]
I was only trying to help you brainstorm ways of solving your problems. I'll spare you my credentials as it doesn't matter. Good luck
You can try to setup a Captive Portal to filter by MAC address: https://www.pfsense.org/about-pfsense/features.html
https://forum.pfsense.org/index.php?topic=71198.0https://forum.pfsense.org/index.php?topic=79788.0
https://forums.freebsd.org/threads/32841/
-
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
