pfSense English Support > Firewalling

firewalling MAC addresses

<< < (2/7) > >>

garyd9:

--- Quote from: Paint on July 29, 2016, 09:59:40 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.

--- End quote ---
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:

--- Quote from: garyd9 on July 29, 2016, 11:03:54 am ---
--- Quote from: Paint on July 29, 2016, 09:59:40 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.

--- End quote ---
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.

--- End quote ---

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


--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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)
--- End quote ---
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.)



--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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.
--- End quote ---
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?


--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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.

--- End quote ---
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:

--- Quote from: garyd9 on July 29, 2016, 01:27:21 pm ---Here we go...


--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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)
--- End quote ---
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.


--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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.
--- End quote ---
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?


--- Quote from: Paint on July 29, 2016, 11:19:17 am ---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.

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

--- End quote ---

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. 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version