Prevent VAP from accessing the internet (with ebtables)
0
votes
1
answer
355
views
I'm trying to find a way to connect smart home devices to my local network but deny them access to the internet.
Rather than set individual rules bound to an IP address, I'm trying to create a virtual WiFi on my DD-WRT router that has access to the local network, but drops internet-bound packets.
By default, any new virtual WiFi gets mixed in with the main pool of bridged interfaces.
This is not a totally uncommon problem, and the standard approach seems to be move the virtual interface into a bridge of its own and use a different subnet and a whole mess of
iptables
rules.
e.g. https://unix.stackexchange.com/questions/462055/dd-wrt-prevent-vap-from-accessing-the-internet
Surely we can do better than that.
I expected to be able to add a single ebtables
rule to get the effect I want. Something like this illegal rule:
ebtables -t broute -I BROUTING -i wl0.1 -o $(get_wanface) -j REJECT
-o
and REJECT
aren't valid in this context, so the closest I can get is:
ebtables -t broute -I BROUTING -i wl0.1 -p IPv4 --ip-destination ! 192.168.1.0/24 -j DROP
The design here intends to hook into the broute table (very early in the global chain) and DROP packets out of the bridge router. The packets it targets are any that come in on the virtual WiFi and intend to go somewhere other than the local subnet.
This kind-of works. Maybe for the first local / WAN test I do, but after that my diagnostic apps hang and the network feels very unhealthy.
I think this is because ebtables can't do anything fancy with IP, so the concept of REJECT doesn't really apply here. This is a problem, because DROP leaves the phone off the hook and I have nothing handling where the DROP'd packets go (I don't even know where they go / how to intercept them / how to REJCET them etc.)
Does this ebtables
approach have legs or is it a lost cause?
Asked by Brandon Lesko
(11 rep)
Oct 19, 2022, 04:11 AM
Last activity: Oct 20, 2022, 06:26 PM
Last activity: Oct 20, 2022, 06:26 PM