Firewalling MAC addresses

garyd9

I did a search, and it seems that MANY before me have asked about pfSense having some kind of firewall rules based on MAC addresses (in addition to those based on IP addresses.) In all those cases, it was revealed that pfSense isn't capable of such a basic feature.

Usually, when someone asks if this could be implemented, it seems that the responses vary between people trying to be reasonable, and those who just attack. The reasonable ones suggest that pfSense isn't an L2 device, so shouldn't be messing with MAC addresses. They also sometimes try to help by suggesting that DHCP reservations should be made against the MAC addresses and firewall rules applied to the IP addresses. Some reference ipfw (which isn't supported in the pfSense UI.) I've even seen (oddly) people suggesting static ARP tables, making every potential client known, and with a DHCP reservation. I've never seen anyone actually gain any traction in trying to get MAC address rules supported, however.

I don't understand why not.

Consider that the purpose of DHCP is not to create a new reservation for every single client that might connect. A quick google of "purpose of DHCP" reveals a first hit from University of California, Davis that states (in part): DHCP's purpose is to enable individual computers on an IP network to extract their configurations from a server (the DHCP server) or servers, in particular, servers that have no exact information about the individual computers until they request the information.

That point aside, however, assigning an IP address with DHCP and using that for filtering is USELESS with modern devices on modern networks. Why? IPv6. When I go to "youtube.com", my machine is resolving the name to an ipv6 address and the traffic is flowing over the ipv6 "address family." I can block IPv4 addresses until I'm blue in the face, but it won't help unless I'm going to some website that's 5 years behind the times and hasn't started IPv6 migration. Either my device will use IPv6 by default, or will fall back to trying to use IPv6 when IPv4 fails to work out.

Oh, but what about DHCPv6 and static reservations there? Go ahead and boot up an android device and see if your android device uses the "reservation." Android completely ignores DHCPv6. Several OS's do. It's also useless for Windows: Windows devices will happily accept the assigned IPv6 address, and promptly use a different IP address for outgoing traffic. Mac does the same thing. (If you don't believe me, go ahead and test it out. On Windows/Mac, you'll see that the machine gets the assignment… but look at what IP address you're REALLY using for outgoing traffic...) (I'm haven't tested this, but I believe that linux does the same thing.)

In other words, firewall rules for outgoing traffic based on source IP is useless for 95% of the clients (to destination address that support ipv6.) The irony is that it takes ZERO effort to bypass the firewall like this, as the client OS is setting the conditions for it automatically. A user isn't TRYING to bypass the firewall. It just happens.

(Sarcasm for only those who might suggest that the answer to this is to disable IPv6 on our networks: should we also disallow any WAN traffic faster than old T1's and any LAN traffic faster than old token ring? Perhaps we should just go ahead and revert to arpanet days and limit ourselves to that level of technology while we're at it.)

A MAC address filter, because it works at L2, would help to resolve these issues.

So... I'll ask the same question that many before me have asked: Can pfSense be updated to support MAC address rules in the firewall?

Take care
Gary

Edit:

I just to quote something from here: https://www.pfsense.org/about-pfsense/

pfSense software is a free, open source customized distribution of FreeBSD specifically tailored for use as a firewall and router that is entirely managed via web interface. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution.

I'm hoping that the authors would be willing to work in whatever layer is required to be an EFFECTIVE firewall and router.

chris4916

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.

Paint

Firewalls route over layer 3 (ip addresses), not necessarily MAC addresses (layer 2) what are you trying to do exactly?

garyd9

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

Paint

@garyd9:

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)

garyd9

@Paint:

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.

Paint

@garyd9:

@Paint:

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.

garyd9

Here we go…

@Paint:

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

@Paint:

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?

@Paint:

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

Paint

@garyd9:

Here we go…

@Paint:

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.

@Paint:

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?

@Paint:

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

https://forum.pfsense.org/index.php?topic=79788.0

https://forums.freebsd.org/threads/32841/

heper

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.

dotdash

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

garyd9

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?

heper

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.

Paint

@garyd9:

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?

Fabio72

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 easy

I 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).

garyd9

@Fabio72:

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 easy

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

dotdash

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.

JKnott

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.

JKnott

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.

ne2z

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