Guest network (Wi-Fi 1 & Wi-Fi 2) isolation/security issue

Hi Folks, I am in the process of setting up my Omnia and am observing an issue with guest network isolation. I have created a guest network on each radio (T5-G & T2-G) and each AP has option isolate 1, which is expected. Now I have two wireless clients each connected to a separate Wi-Fi guest AP but they can still ping each other. Is that an expected behaviour?

While the same two clients are connected to either guest WiFi simultaneously, they cannot ping each other: they can only see the other one if connected to separate radios.

The forward rule on guest_turris is set to reject, but that rule only applies to forwarding between interfaces. I only see a single network interface guest_turris, so option isolate 1 does the trick within a single AP, but there seems to be nothing to block communications between individual APs in the guest_turris firewall zone.

Have I made a configuration mistake?

UPDATE: I am trying to stay as close as possible to what Foris configures…

That is for the clients on the same wlan iface and handled by the wlan chip and not the OS. If both wlan ifaces are in the same firewall zone it is expected that they can ping each other.

There is nothing in Fortis to suggest that and that creates an impression, that the Guest Network is completely isolated while it is not.

Here we go. Anyone is willing to give this a shot?

echo 1 > /sys/class/net/br-guest_turris/bridge/nf_call_iptables
echo 1 > /sys/class/net/br-guest_turris/bridge/nf_call_ip6tables

This node’s (TOS4.x beta 2) logs showing

bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.

I am using v3.11.4 and the workaround is working by default. br_netfilter is not available in the current OpenWRT release: kmod-br-netfilter became its own package in 18.06 so it needs to be installed separately as per that link I provided.

Having said that, broken guest network isolation is a big deal in my mind.

A neat thing about using this approach is that I can now greatly simplify my configuration: I no longer need to create an interface for each wired VLAN and an interface each guest WiFi AP. I can now use two interfaces only: lan and guest. Everything trusted goes in lan and all untrusted WiFi APs and untrusted wired VLANs are going into guest.
This obviously does not isolate wired devices connected to a single VLAN port with a dumb switch, but that is a different problem.
As far as the wireless clients are concerned, I can have an AP without isolation for those devices that need to talk to each other, but only within that AP. And I can have APs with isolation where devices cannot reach each other. And as long as they are all in the same guest zone with forwarding disabled, there is no inter-VLAN (wired or wireless) cross-talk possible even though they are all in the same bridge.

1 Like

I have just tested this approach in OpenWRT master and it all works after kmod-br-netfilter is installed, so it should work the same in TOS4.

1 Like


I am a bit rusty with iptables since the OpenWRT boxes are the only ones left with it, else using the more convenient nftables. But that is another matter and rather off-topic

i usually use ebtables to limit traffic on bridges.
put in firewall.user or via hotplug.d script or rc.local

no forwarding on any bridge:
ebtables -P FORWARD DROP

no forwarding on specific bridge:
ebtables -I FORWARD -i br-guest1 -j DROP

hence only traffic from/to the AP itself (INPUT/OUTPUT) is allowed.


1 Like

Is there any benefit for using it over netfilter?

The point I am trying to make is that a working solution should be a part of the default config. When I saw one guest interface, one firewall zone, and two guest AP’s I assumed that it would just work. And then the test showed it not be the case.
I saw Turris people read the forum so I am hoping they will chime in shortly.

fwiw you first have to make the bridge call into netfilter (at a nonzero cost), whereas ebtables is the intended tool for the job.

Hmm, that thread I referenced above states that ebtables is very slow…

I do but the problem is that is does not stick with sysctl upon boot.

from the cli sysctl -w /sys/class/net/br-guest/bridge/nf_call_ip6tables=1 works as expected but /sys/class/net/br-guest/bridge/nf_call_ip6tables=1 in a /etc/sysctl.d/10 - bridge-filter.conf file does not for some reason, whilst all other files in the same directory work. :roll_eyes:

Well, I use /etc/rc.local as it is easier for me to track all the customizations in a single file.

Check out /etc/hotplug.d/net/00-sysctl that plays those files: there could be a typo or something in your script.

So ebtables is already installed as a part of v3.11.4, so the router is already incurring the cost of running it. Yeah, it makes sense to use it instead of adding something new. I will give it a shot later.

This did not work for Wireless AP Client to Wired VLAN Client: they could still communicate. Am I missing any additional config? (I did replace the bridge name with a correct one).

nftables single handles what iptables, ip6tables, arptables, ebtables and ipset combined achieve, in a single kernel module and less cpu costly.

Only caveat is that currently no connection tracking is available for its bridge filtering, if such is really needed.

sry, my vlan-ap are single-band. i use bridge filter on the ap’s only for broad/multicast and the non-fwd bridge (as described) on the router.

i guess you could use a combination of --logical-in and --logical-out for your case …
nft sounds “promising” thou