Communication between Guest Network (IoT) and LAN device | RT-AC86U - 386.5_2

[lluke]

Hi All,
I’m trying to setup my network to isolate IoT devices from internal LAN (wired and regular WiFi), my personal devices (iOS and MacOS) are accessing the IoT ones through a single LAN device hosting Homebridge.

Now the possible scenarios for the IoT devices are the following

• IoT device requires internet to properly work and to get managed
• IoT device requires internet only for OTA updates but can be managed locally
• IoT device can be updated and managed locally (single direction calls, from box to device)
• IoT device can be updated and managed locally (bidirectional calls, from box to device and viceversa)

So that my ideal solution would be to have

• Guest WiFi network #2 for IoT devices
• Homebridge box connected to LAN through Ethernet
• Personal devices connected to LAN through regular WiFi and Ethernet

I’m almost done but I’m struggling allowing the communication between the Guest network and the standard lan only to a single device.
I’ve configured the Guest Wifi with “Access intranet” set to Disable, this allow to achieve the segregation I need.

Now I’m trying to enable the communication with the Homebridge box with the following script (tried both with nat and firewall start):

#!/bin/sh

## allow homebridge to talk to IoT devices on firewalled guest network
MAC="XXXXXXXXXXXX" # HB box ether mac address
EBT=$(ebtables -L --Lx --Lmac2) # existing ebtables FORWARD chain rules

if echo "$EBT" | grep -iq "$MAC"
then
  # do nothing because custom rules already in place
  logger "nat" "Custom ebtables rules for HB already in place"
else
  # add custom rules
  ebtables -I FORWARD -i wl0.2 -d $MAC -j ACCEPT
  ebtables -I FORWARD -o wl0.2 -s $MAC -j ACCEPT
  logger "nat" "Custom ebtables rules for HB added"
fi

Unfortunately the communication it is not working and I’ve already evaluated Yazfi but it isn’t a viable solution for the high amount of devices for which I’ve to set up a registered IP (DHCP) and that I’d like to manage from a UI and not a script.

Do you have suggestion on how to achieve the scenario mentioned above?

 

[eibgrad]

I'm NOT an ebtables expert, but based on what I do know, I see two problems here.

First, when access to the intranet is disabled, the router adds the following rules to ebtables, specifically in the BROUTING chain of the broute table.

admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

Note the broute table is traversed *before* the filter table (where you have installed your rules). ACCEPT and DROP mean different things in this context than those same targets on the filter table. The ACCEPT target means the traffic must be bridged, while DROP means it must be routed. That's what allows guests to have access to the WAN but NOT the local IP network, except for the router itself (GUI, DHCP, DNS, etc.).

So your attempt to allow a specific MAC address access won't work (at least for intranet access purposes) since the BROUTING chain has been specifically configured to NOT allow bridging (again, except for the router itself).

Seems to me you'd be better off to insert an ACCEPT rule for the IP assigned to the Homebridge device into this same table+chain, which of course requires statically assigning an IP.

ebtables -t broute -I BROUTING -p IPv4 -i wl0.2 --ip-src 192.168.1.100 -j ACCEPT

IOW, unlike any other device on wl0.2, the Homebridge (192.168.1.100) is allowed to bridge to any location on its own network interface.

Secondly, there is no specifically defined event for invoking ebtables. So your guess is as good as mine as to when that makes the most sense. If I had to guess, perhaps the service-event event (specifically when passed the wireless argument), since it's critical the router has already configured ebtables before making your own changes.

But before worrying about how to install it, reboot the router, wait for it to stabilize, and try creating the static route and adding the rule I suggested above from an ssh session to see if it indeed works.

 

[lluke]

Thanks a lot for the input @eibgrad , I did some experiments and either the ebtables way is wrong or I did some errors in configuring it.

The first step I’d like to unblock before achieving my needs is to have a device on the Guest network able to connect to the Homebridge box (IP: 192.168.10.2, MAC: XX:XX:XX:XX:XX:XX).

With the ipad connected to the Guest network and the following ebtables unfortunately I’m not able to make an HTTP call w/ success

admin@RT-AC86U-9DF8-LL:/jffs/scripts# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 7, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.10.2 --ip-proto tcp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.10.2 -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.10.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.10.0/27 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.10.0/27 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.10.0/27 --ip-proto tcp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.10.0/27 --ip-proto tcp -j DROP

Also by adding these rules to the filter table still no clue to make a call from Guest to LAN

admin@RT-AC86U-9DF8-LL:/jffs/scripts# ebtables -t filter -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-d XX:XX:XX:XX:XX:XX -o wl0.2 -j ACCEPT
-d XX:XX:XX:XX:XX:XX -i wl0.2 -j ACCEPT

So that I’ve now 2 questions:

• Do I need to execute any command after altering the ebtables or the update is applied live? E.g. restarting any service, ….
• Do you have any other suggestion to experiment for my needs?

Thanks again for the support

 

[eibgrad]

Once the rules are applied and show in the ebtables dump, afaik, they should be active.

I presume if you ENABLE intranet access (thus no ebtables rules), you do have access to the Homebridge from the guest network? I just want to be sure that ebtables is the only obstacle, and NOT something else we haven't considered.

 

[lluke]

Your assumption is correct, as soon as I enable the intranet access for the guest network then the ebtables becomes empty and the LAN and the guest network can see each other.
In other words I can reach the homebridge box from the guest network and I can reach the guest network from the homebridge box.

 

[eibgrad]

I would NOT (at least for now) qualify the rule you added for ebtables w/ a specific protocol (tcp). Just allow anything to go through. Perhaps there's additional requirements that can't be met w/ only tcp access.

IOW, when diagnosing a problem, try NOT to be overly restrictive. Get it working first, THEN become more restrictive until it breaks. Then you'll know specifically what broke it.

 

[GSpock]

I'm NOT an ebtables expert, but based on what I do know, I see two problems here.

First, when access to the intranet is enabled, the router adds the following rules to ebtables, specifically in the BROUTING chain of the broute table.

admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

@eibgard, in the above, didn't you mean "when intranet access is disabled the router adds ...." instead ?

because access to my guest network 3 is disabled and I have those rules ....

ASUSWRT-Merlin RT-AX86U 386.5_2 Fri Mar 25 14:23:26 UTC 2022
xxx@RT-AX86U:/jffs/scripts# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

 

[eibgrad]

@eibgard, in the above, didn't you mean "when intranet access is disabled the router adds ...." instead ?

because access to my guest network 3 is disabled and I have those rules ....

ASUSWRT-Merlin RT-AX86U 386.5_2 Fri Mar 25 14:23:26 UTC 2022
xxx@RT-AX86U:/jffs/scripts# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

Yes, I misspoke. Thanks. Corrected above.

 

[lluke]

After a lot of tries but especially thanks to the initial input of @eibgrad I’ve decided to go for a different strategy.
I’ve segregated my devices by ip “subnets“ (the quotes are mandatory since they’re only logical groups and not actual subnets with a lan and a broadcast ip).

The segregation is the following:

• Full: 192.168.10.0/26
• IoT Servers: 192.168.10.4/30 (e.g. Homebridge box)
• IoT Manageable only through internet: 192.168.10.16/29
• IoT Manageable through local net: 192.168.10.32/29
• DHCP: 192.168.10.48/28

Then I’ve applied the following rules similar to the originals added by Asus when “Intranet access” is disabled

admin@RT-AC86U-9DF8-LL:/tmp/home/root# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 7, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-src 192.168.10.48/28 --ip-dst 192.168.10.32/29 -j ACCEPT
-p IPv4 -i wl0.2 --ip-src 192.168.10.32/29 --ip-dst 192.168.10.48/28 -j DROP
-p IPv4 -i wl0.2 --ip-src 192.168.10.32/29 --ip-dst 192.168.10.32/29 -j DROP
-p IPv4 -i wl0.2 --ip-src 192.168.10.32/29 --ip-dst 192.168.10.16/29 -j DROP
-p IPv4 -i wl0.2 --ip-src 192.168.10.16/29 --ip-dst 192.168.10.48/28 -j DROP
-p IPv4 -i wl0.2 --ip-src 192.168.10.16/29 --ip-dst 192.168.10.32/29 -j DROP
-p IPv4 -i wl0.2 --ip-src 192.168.10.16/29 --ip-dst 192.168.10.16/29 -j DROP

If you see any improvement you’re more than welcome but so far it seems my network is properly isolated and all the integrations for the automation are still working.

Now I need to understand where to add the initialisation of these ebtables rules any suggestion here is again welcome.

Edit —>
(Not so) small note to consider: it seems that with the following configuration all the devices connected to the same Guest network can see each other, so that I guess I’ll have to find a working setup for the combo “Intranet access” disabled and my additional needs of communication.
From the experience it seems ebtables rules are applied only when there is a “connection” between a guest network and the others (LAN, WiFi, other Guest) and not when routing is applied internally to it.
Tomorrow I’ll continue experimenting and I’ll keep the forum posted on any interesting discoveries, any input is always welcome.

 

[eibgrad]

I assume before adding your own ebtables rules, you enabled intranet access in the GUI, so only your rules get added. But I believe when you do that, the GUI disables AP isolation for the guest network (it happens at the wireless driver level, NOT ebtables). So you will probably have to enable AP isolation if you still want guests isolated from each other.

nvram set wl0.2_ap_isolate=1
nvram commit
reboot

The tricky part is if you make any changes to the guest setup, you'll probably have to reapply these changes.

 

[lluke]

@eibgrad your assumptions were correct, but here the situation is getting more and more complicated than the expected.

As soon as I enable the ”AP isolation” and I apply the same ebtables rules as above I’m not able to get any communication between the IoT servers and any device connected to the Guest network.
It seems that this setting is affecting the routing logic before the ebtables rules are considered…

Is this something you were expecting or should I maybe consider a different approach?

 

[lluke]

After several failures with custom rules and ebtables I have finally gave a chance to YazFi, still not super user friendly for the IP reservation but the segregation has been really easy to achieve.

Here the corresponding discussion about YazFi if someone else is in the same situation!

Thanks a lot again for all the support @eibgrad.