Filtering specific devices, using mac-based Policy Filtering
-
Once again, you don't see DUID on the wire, except with DHCPv6. This means you cannot filter on it and would require DHCPv6 to assign addresses. That brings us to the problem where (for some idiotic reason) Android devices can't use DHCPv6.
-
And pf can't filter based on MACs, so that's a dead end and not a possibility.
Also you can't do MAC filtering on traffic inbound from the Internet to local hosts so that doesn't help you in that direction anyhow.
"stable apart from spoofing" is meaningless since unless you isolate and filter clients properly at L1/L2 (read: switches and APs) everything can be spoofed.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
I built my first firewall with Slackware Linux and IPChains, later SUSE and IPTables. I don't remember about IPChains, but IPTables could definitely filter on MAC addresses. The reason I switched to pfSense was because Linux didn't work with DHCPv6-PD.
Also you can't do MAC filtering on traffic inbound from the Internet to local hosts so that doesn't help you in that direction anyhow.
Yep. I was at a Linux meeting a few years ago, where I had to correct the presenter on that point.
-
In a manner of speaking, widespread adoption of IPv6 in the future is going to just about send firewalls the way of the horse and buggy ...
. There is, of course, some hyperbole in that statment, but ...Individual client security/monitoring/policing will get way harder than today since a given client can have a ton of addresses. Sure you will still be able to do subnet-level stuff, but individual host stuff gets orders of magnitude harder.
-
If I have a computer or an IoT device I want to limit in its behavior, it will be very unlikely that it is spoofed.
And if I was afraid of that, I could try to detect that!
Of course you can only filter on MACs related to my own network, but with that limitation, I do not see a reason why I could filter based on starting mac (in vlan-1) or on destination mac (in vlan-2).
Of course given a situation, where level-2-tags could be read by pf (I think vlanid is one of them)
So I would not be surprised if pf could do that! It is almost identical to policy based routing. But of course that should be checked with a high level expert.
I know that it is possible on OpenBSD and elsewhere, but of course that does not necessary that it is also possible on freebsd/pf combination.
Louis
-
Of course, this is a FreeBSD problem, not pfSense, due to the pf filtering that FreeBSD uses. If it used IPTables, it wouldn't be an issue. So, this problem really should go back to the FreeBSD folks.
-
Just to indicate a potential solution direction,
A potential solution does in volve "Tagging of Ethernet Frames"
Tagging can be performed at the ethernet level if the machine doing the tagging/filtering is also acting as a bridge(4). By creating bridge(4) filter rules that use the tag keyword, PF can be made to filter based on the source or destination MAC address. Bridge(4) rules are created using the ifconfig(8) command. Example:
step-1: ifconfig bridge0 rule pass in on fxp0 src <mac-address> tag <sometag>
step-2: And then in pf.conf: pass in on fxp0 tagged <sometag> (policy based rule)This direction seems to imply that there must be bridge on ethernet level. That could perhaps significant complicate things
Louis
-
That is not available on FreeBSD. That is an OpenBSD-specific function.
-
Hi
Unfortunately , as we have already said, PF is not able to work with network packets at the L2 level.
But the FreeBSD/PF kernel has a very powerful NETGRAPH network subsystem built in. You can use it to configure packet filtering based on the MAC address . This subsystem allows you to intercept traffic before it reaches the network stack of the operating system and analyze it.
Here is its description
https://www.freebsd.org/cgi/man.cgi?netgraph(4)You will need modules to analyze the ethernet header
ng_ether + ng_vlan (possibly) + ng_bpf
-
Thanks for the tip,
I just scanned the doc, will read in more detail later. Perhaps there are some artikels as well on internet.
However, my first feeling is that it lets say "an advanced acl-filter" on level-2.
First feeling is that you could perhaps ...:
- block traffic between A and B (that could be usefull) or
- allow traffic by passing pfSense (a very bad idea !!)
And of course with "complexity (and performance)" as price
What ever, worth reading more
Louis
-
intresting link
https://people.freebsd.org/~julian/netgraph.html
-
Since the modules of this subsystem work at the kernel level, it is very high-performance and does not exert a strong load on the system.
Yes, at first it is difficult to understand , but you can understand it
The main difficulty is creating a BPF program for filtering packets . The rest is easy .
for example, to intercept traffic from a device with the MAC address 98:01:a7:8c:eb:89, the program will look like this
ether[6:4]=0x9801a78c and ether[10:2]=0xeb89
(000) ld [6]
(001) jeq #0x9801a78c jt 2 jf 5
(002) ldh [10]
(003) jeq #0xeb89 jt 4 jf 5
(004) ret #262144
(005) ret #0bpf_prog_len=6 bpf_prog=[ { code=32 jt=0 jf=0 k=6 } { code=21 jt=0 jf=3 k=2550245260 } { code=40 jt=0 jf=0 k=10 } { code=21 jt=0 jf=1 k=60297 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ]
Netgraph is managed from the console by the ngctl utility. For automation, you will need to write a script.
And, most importantly, you must have physical access to the console , because it is very easy to lose access to the firewall -
I do not know yet however,
I am not so sure about this package, it seems a package to build a L2-switch or router.
However that layer has been built by NetGate and apart from my limited knowledge, I absolutely do not want to interfere with their L2-design !!
Also note that I was not looking for a level-2 filter! If there was not IPV6 with all its "strange addresses" which are undermining firewalls, I would never be advocating MAC-addresses here. But given lack of a decent and stable IPV6-adres, you need that as attribute for level-3 filtering.
So, I will do some further reading, but my first impression is that this is not an option for the given problem. And in case I am mistaken (I hope), it must be implemented by NetGate in order to keep the system consistent and reliable.
Louis.
-
This subsystem does not work in conjunction with PF . For example, it works perfectly with ipfw ( it is used by this firewall for deep packet inspection ) .
Simply using its capabilities , you can filter packets based on the device's mac address, vlanid, and other attributes (ip, tcp/udp packets).
But, unfortunately, using this subsystem, you can't create tags that PF would understand.
