Netgate SG-1000 microFirewall

Author Topic: firewalling MAC addresses  (Read 4000 times)

0 Members and 1 Guest are viewing this topic.

Offline garyd9

  • Full Member
  • ***
  • Posts: 140
  • Karma: +13/-11
    • View Profile
firewalling MAC addresses
« on: July 28, 2016, 08:07:51 pm »
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/ 
Quote
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.
« Last Edit: July 28, 2016, 08:24:42 pm by garyd9 »

Offline chris4916

  • Hero Member
  • *****
  • Posts: 1784
  • Karma: +87/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #1 on: July 29, 2016, 01:19:41 am »
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.

Offline Paint

  • Full Member
  • ***
  • Posts: 208
  • Karma: +32/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #2 on: July 29, 2016, 08:39:45 am »
Firewalls route over layer 3 (ip addresses), not necessarily MAC addresses (layer 2)  what are you trying to do exactly?
pfSense i7-4510U + 2x Intel 82574 + 2x Intel i350 Mini-ITX Build
940/880 mbit Fiber Internet from FiOS
Dell PowerConnect 2716 Gigabit Switch
Netgear R8000 AP (DD-WRT)
Asus RT-66U AP (DD-WRT)


Offline garyd9

  • Full Member
  • ***
  • Posts: 140
  • Karma: +13/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #3 on: July 29, 2016, 09:38:13 am »
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.)




Offline Paint

  • Full Member
  • ***
  • Posts: 208
  • Karma: +32/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #4 on: July 29, 2016, 09:59:40 am »
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)
pfSense i7-4510U + 2x Intel 82574 + 2x Intel i350 Mini-ITX Build
940/880 mbit Fiber Internet from FiOS
Dell PowerConnect 2716 Gigabit Switch
Netgear R8000 AP (DD-WRT)
Asus RT-66U AP (DD-WRT)


Offline garyd9

  • Full Member
  • ***
  • Posts: 140
  • Karma: +13/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #5 on: July 29, 2016, 11:03:54 am »
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.

Offline Paint

  • Full Member
  • ***
  • Posts: 208
  • Karma: +32/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #6 on: July 29, 2016, 11:19:17 am »
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.
pfSense i7-4510U + 2x Intel 82574 + 2x Intel i350 Mini-ITX Build
940/880 mbit Fiber Internet from FiOS
Dell PowerConnect 2716 Gigabit Switch
Netgear R8000 AP (DD-WRT)
Asus RT-66U AP (DD-WRT)


Offline garyd9

  • Full Member
  • ***
  • Posts: 140
  • Karma: +13/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #7 on: July 29, 2016, 01:27:21 pm »
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.]



« Last Edit: July 29, 2016, 01:31:15 pm by garyd9 »

Offline Paint

  • Full Member
  • ***
  • Posts: 208
  • Karma: +32/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #8 on: July 29, 2016, 01:29:37 pm »
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.0

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

https://forums.freebsd.org/threads/32841/
« Last Edit: July 29, 2016, 01:41:18 pm by Paint »
pfSense i7-4510U + 2x Intel 82574 + 2x Intel i350 Mini-ITX Build
940/880 mbit Fiber Internet from FiOS
Dell PowerConnect 2716 Gigabit Switch
Netgear R8000 AP (DD-WRT)
Asus RT-66U AP (DD-WRT)


Offline heper

  • Hero Member
  • *****
  • Posts: 2688
  • Karma: +253/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #9 on: July 29, 2016, 03:15:29 pm »
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. 

Offline dotdash

  • Hero Member
  • *****
  • Posts: 1915
  • Karma: +99/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #10 on: July 29, 2016, 05:26:17 pm »
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

Offline garyd9

  • Full Member
  • ***
  • Posts: 140
  • Karma: +13/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #11 on: July 29, 2016, 05:55:43 pm »
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?


Offline heper

  • Hero Member
  • *****
  • Posts: 2688
  • Karma: +253/-11
    • View Profile
Re: firewalling MAC addresses
« Reply #12 on: July 29, 2016, 07:07:22 pm »
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.



Offline Paint

  • Full Member
  • ***
  • Posts: 208
  • Karma: +32/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #13 on: July 29, 2016, 08:19:29 pm »
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?
pfSense i7-4510U + 2x Intel 82574 + 2x Intel i350 Mini-ITX Build
940/880 mbit Fiber Internet from FiOS
Dell PowerConnect 2716 Gigabit Switch
Netgear R8000 AP (DD-WRT)
Asus RT-66U AP (DD-WRT)


Offline Fabio72

  • Jr. Member
  • **
  • Posts: 75
  • Karma: +5/-2
    • View Profile
Re: firewalling MAC addresses
« Reply #14 on: August 02, 2016, 08:22:17 am »
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).