How to fliter ip traffic between devices on the same lan

About me

i am a senior software engineer in the cyber security field.
i love coding and i code in many programming languages and under many different frameworks.
i have a strong background in Linux networking stack and love to solve challenges in this area.

The problem I wanted to solve

The linux way of doing packet filtering is by tools such as iptables.
the iptables is a convenient application to set rules on which kind of traffic you either want to accept or drop.
the iptables app works great for outgoing or incoming traffic. i.e a user that wants to enter a certain web site.
but' what happens if the traffic is inter lan communication ? i.e a wifi device 'x' that wishes to communicate to wifi device 'y'.
the answer is simple - this traffic can't be filtered since the traffic only going through the wifi chip and the operating system's ip stack.
this is why' iptables can't be used to set filtering rules on wifi lan communication.
i wanted to solve this issue and let the network admin the ability to filter wifi lan traffic.

What is an application that enables to do packet filtering between wifi devices under same ssid?

the first packet sent between 2 devices on the lan will be arp request.
each node has to know the hardware address of the node it wishes to communicate with.
so, in order to overcome the problem i faced, i understood that my main goal it to trick the nodes on the lan and "lie" to them about the hardware address of each other node on the lan.
to do that i created an application, running on the router whose job is to sniff arp request packets, and to generate arp reply messages with the router's own mac address. once the application runs, all the traffic enters the operating system's ip stack and can be filtered by iptables.

Tech stack

to create an app that sniffs packets, i created a raw socket that "listens" on all the traffic that the wifi adapter receives. since the wifi adapter receives a lot of traffic all the time, a raw socket that accepts all traffic could be very CPU consuming. so, i chose to use bpf packet filters. the bpf filters allow us to define filtering rules and apply them to a socket, i won't go to deep here but i'll just say it boosts performance.
so i created a filter that will only receive packets on the desired wifi adapter and only frames whose destination mac address is ff:ff:ff:ff:ff:ff (broadcast frames). the application is up and running but that was still not enough. the application indeed answered the arp requests with the correct arp reply, but it had to "compete" with another arp reply that was sent from a node on the lan. a brief explanation - when node 'x' wishes to communicate with node 'y' it sends an arp request, node 'y' answers and they start communicating. so besides my new application's arp reply there was also the "original" arp reply. so i do i get rid of the "original" arp reply ? , well, luckily most of the wifi chips come today with the ability to set wireless isolation. what that means is that lan wifi clients will not be able to communicate with each other, they can only communicate with their upstream router. that was perfect for me, since once i enable the isolation, the "original" arp reply won't reach the other client, and since the generated arp reply from the app comes from the router it wont be isolated by the wifi chip.
now we have a system whose lan devices can communicate with each other with the help of the router, it does add a little latency to the traffic but now traffic can be filtered in the normal and easy way

The process of building an application that enables to do packet filtering between wifi devices under same ssid

first i needed to understand why i can't filter lan traffic, i had to get a good understanding of the packet flow inside the wifi chip and in the linux ip stack. then, i understood that packet filtering will not be possible unless i perform some kind of networking trick.
since i know unicast traffic is switched on the wifi chip and hence can't be "seen" by the router, ir was clear to me that i have to start with the first traffic which is the broadcast arp request.
after examining the wifi chip and learning its isolation capabilities i understood that it was a "must have" ability for my application to work.
the last chalenge was not to damage too much the performance and that is where the bpf filters entered the picture. they allowed me to define specific filter for the raw socket so i did not need to handle all the packets but only a fraction of them (broadcast packets) and hence not to make my app cpu consuming.

Challenges I faced

on regular projects, normally you search answers in stackoverflow since many of the daily challenges we face as software engineers were already faced by other developers. the problem i faced did not have a documented solution. i needed to gather all my networking abilities and knowledge and to find a unique solution to this problem, and even after solving the problem a lot of "minor" problems arise that force you that read and understand very well the arp protocol and solve any additional problems you haven't thought about.

Key learnings

the easy thing was to let go and say that the problem cant be solved,
but sometimes being creative and thinking out of the box might lead you to very interesting solutions that can't be found even on stackoverflow

Tips and advice

learn and be good at whatever field you choose, sometimes all the knowledge and experience you gathered comes down to a unique problem that maybe very few before have solved or tried to solve and there you'll find all the years of hard work and experience finally pay of.

Final thoughts and next steps

this is a done project, looking forward to my next challenge.