# Is it possible to use MAC tables with IPFW?



## ORTO-DOX (May 7, 2013)

Good day!

At work I use MAC filtering, and since I have 100+ PCs, I just use a scheme like this:

Every new PC adds to an internal database (PC description, MAC address of it interfaces)
Also every PC is tagged with existing groups (departments in the office)
When there are changes in that database, a script dynamically creates ipfw rules for every MAC-address
That task is automated, but I think it is not perfect by design because it has too much identical ipfw rules like:

```
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:55 in recv ${LAN}
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:66 in recv ${LAN}
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:77 in recv ${LAN}
```
I think, it will be good to have ability organize MAC filtering in FreeBSD similar in such way:

```
ipfw mac-table 1 flush
ipfw mac-table 1 add 001122334455
ipfw mac-table 1 add aabbcc #which means all mac-address aa:bb:cc:*:*:*
ipfw add 1 deny all from ${LAN} to mac-table(1)
```
Isn't this is good idea?


----------



## SirDice (May 7, 2013)

You do realize it's fairly trivial to change one's MAC address? Why do you want to go to all this administrative trouble?


----------



## ShelLuser (May 7, 2013)

In addition to @SirDice I think I also spot another possible issue with your firewall strategy; from the small bit of information you shared here it would seem that you use an "allow all, deny xxx" strategy which can come with several caveats of its own.

Why not go for a "block all, allow xxx" based strategy? It would most likely reduce quite a bit of overhead in your firewall rules (please note that these are only assumptions on my part, based on what you shared so far).

Finally I have to agree with @SirDice on this one, it seems you're adding a lot of overhead which could most likely be avoided without any negative consequences.

Still, I do agree that its likely that more people would know how to change their IP address compared to the amounts who know how to change their MAC.


----------



## ORTO-DOX (May 7, 2013)

SirDice said:
			
		

> You do realize it's fairly trivial to change ones MAC address? Why do you want to go to all this administrative trouble?



Of course I realize that, and change of MAC address is not more difficult than a change of IP address, but when users are unprivilege*d* - changing of MAC or IP addresses is not so easy. So I think MAC tables are not less needed than IP tables.



			
				ShelLuser said:
			
		

> In addition to SirDice I think I also spot another possible issue with your firewall strategy]
> 
> No, the examples in my post are just examples, not copy/paste from real ipfw rules. In fact I'm use MAC filtering:
> 
> ...


----------



## Anonymous (May 7, 2013)

Some years ago, Gleb Kurtsou extended lookup tables in ipfw to support several layer2 addresses for a single layer3 address/mask. See here. This resulted from Project #16 of the FreeBSD Summer Of Code 2008. It seems, that this would provide pretty much what you are looking for. Patches are provided at GitHub. However, I didn't come to check this out, though. So, I cannot tell, whether these patches do still work with the latest ipfw.


----------



## pboehmer (May 7, 2013)

I may be way off, but since you stated that the MACs are added to an internal database and you have a script that adds them to a ipfw table, why don't you just put some check code into either (or both) of the scripts?  Something like:


```
cat mac_list | sort | uniq > new_mac_list
```

Flush the table and inject the new_mac_list.


----------



## ORTO-DOX (May 7, 2013)

pboehmer said:
			
		

> I may be way off, but since you stated that the MACs are added to an internal database and you have a script that adds them to a ipfw table, why don't you just put some check code into either (or both) of the scripts?  Something like:
> 
> 
> ```
> ...


Sorry @pboehmer, but I don't understand your proposition 

For me all works with my own current scripts, but I think it will be useful to implement feature which are provided by project l2filter proposed few posts before. From examples of l2filter, it exactly what I mean in first post plus some more features.



> I had an opportunity to spend some extra time improving layer2 filtering.
> I've extended lookup tables in ipfw to support several layer2 addresses for a
> single layer3 address/mask. It means that it's possible to assign mac addresses
> to network (in case ip's are dynamically distributed by dhcp or whatever).
> ...



Unfortunately at this moment as author of project said his patches not applied to -CURRENT and -STABLE  (since ipfw3 was imported in FreeBSD). 

I'm writing a letter to the author, but in his blog he said that the l2filter project is moved to Github for community supports it.

So maybe somebody will be interested in returning the project to life?
https://github.com/glk/l2filter/


----------



## pboehmer (May 8, 2013)

ORTO-DOX said:
			
		

> Sorry @pboehmer, but I don't understand your proposition




Please disregard my post.  I misread your post as you were having issues with duplicate MACs.  Not enough coffee I guess :r


----------



## j4ck (May 8, 2013)

rolfheinrich said:
			
		

> Some years ago, Gleb Kurtsou extended lookup tables in ipfw to support several layer2 addresses for a single layer3 address/mask. See here. This resulted from Project #16 of the FreeBSD Summer Of Code 2008. It seems, that this would provide pretty much what you are looking for. Patches are provided at GitHub. However, I didn't come to check this out, though. So, I cannot tell, whether these patches do still work with the latest ipfw.



Is it possible to use these patches for pf?


----------

