0

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

Brandon Lesko
  • 11
  • 2
  • Anyway... from man page: "broute is used to make a brouter, it has one built-in chain: BROUTING. **The targets DROP and ACCEPT have a special meaning in the broute table** (these names are used instead of more descriptive names to keep the implementation generic). **DROP actually means the frame has to be routed** [...]" . Whatever you're doing, you probably shouldn't be doing it in this table and chain. – A.B Oct 19 '22 at 06:22
  • Right, I understand that - last paragraph acknowledges they still exist after DROP. I appreciate the reply, but I respectfully disagree. I think this might be the place to do this with my topology unless there's a specific technical reason why not? – Brandon Lesko Oct 19 '22 at 18:01

1 Answers1

1

tldr:

ebtables -F INPUT
ebtables -A INPUT -i wl0.1 -p IPv4 --ip-destination 192.168.1.1/24 -j ACCEPT
ebtables -A INPUT -i wl0.1 -p IPv4 --ip-destination 255.255.255.255 -j ACCEPT
ebtables -A INPUT -i wl0.1 -p IPv4 -j DROP
ebtables -A INPUT -i wl0.1 -p IPv6 -j DROP
ebtables -L --Lc
  1. (optional) Flush (clear out) any pre-existing ebtables rules
  2. Accept anything coming in on restricted WiFi sent to the local subnet
  3. Accept anything coming in on restricted WiFi sent to the broadcast address
  4. Drop anything else coming in on restricted WiFi that looks like IPV4
  5. Drop anything else coming in on restricted WiFi that looks like IPV6
  6. (optional) Show the rules just added + counters

Recall - the aim of this exercise was to create the following configuration:

br0 -
  - eth0   Wired ethernet  |  192.168.1.0/24  |     INTERNET
  - wl1    5   GHz WiFi    |  192.168.1.0/24  |     INTERNET
  - wl0    2.4 GHz WiFi    |  192.168.1.0/24  |     INTERNET
  - wl0.1  2.4 GHz WiFi    |  192.168.1.0/24  |  NO INTERNET

(Note - all interfaces within the same bridge, all on the same subnet, most with internet, one without)

Why specify a protocol on the DROP rule when I could just DROP everything else? I found that being protocol-agnostic...

ebtables -A INPUT -i wl0.1 -j DROP

...works for a WiFi connection that is already established. But, for new WiFi connections they are unable to authenticate. I think this is because the rules were intercepting non-IP traffic necessary for WPA2-PSK.

Hope this helps someone. My use case is to join Kasa smart home devices to my network and make them accessible by my local smart home system, but stopping them from phoning home or self-updating. (The self-updating part was the main motivation since I'm hearing stories about TPLINK closing the open protocol).

Brandon Lesko
  • 11
  • 2