Client isolation on guest vlan in BATMAN mesh doesn't work

Guest and work appear to be missing: option ap_isolation '1'. And on iot its commented out - in this screen grab - you may have updated it since then.

Quote:
To enable use of 802.11s mesh

opkg remove wpad-basic
opkg install wpad-mesh-openssl # or wpad-mesh-wolfssl

...wolf is a stripped down version to save memory ~300kb

...but it probably wouldn't hurt to test:

wpad-openssl

This package contains a full featured IEEE 802.1x/WPA/EAP/RADIUS…

I use it on some of my nodes no problem. Only ~500kb. Just for test purposes perhaps as it has a more complete set of supported protocols / services.

Then my next question is which ATH10K drivers are you using on the dumb AP
(ASUS RT-AC58U)?

Try switching between CT and non-CT versions? CT version is better suited to 256mb ram machines vs the non-CT which is better suited to 128mb which is what the ASUS RT-AC58U is.

Similarly look at the A5 drivers.

opkg update everything.

Do not opkg upgrade anything.

This option doesn't have an effect on batman. batctl -m bat0.4 ap returns disabled no matter if ap_isolation parameter is present in configs or not.

Try switching between CT and non-CT versions

I was not able to make CT work on the ARCHER and I gather CT doesn't support mesh.

Also, the mesh is working fine and vlans are working fine, too. It's just that clients are not isolated within vlans.

1 Like

The wifi AP definition in /etc/config/wireless needs to be set to isolate as well. With isolate off, the wifi driver will bridge clients on the same AP without the packets even reaching the kernel network bridge.

You mean within respective ssid stanzas in /etc/config/wireless? Done it every way - no effect.

actualized configs

There were multiple reports of instability under load, likely due to 128 MB RAM being insufficient for two “ath10k” radios.

Prior to 19.07, using the non-“ct” ath10k drivers and firmware could improve stability (default was kmod-ath10k-ct).

19.07 is now using kmod-ath10k-ct-smallbuffers by default, with many reporting no issues for this device.

There are issues configuring vlans from LuCI for ipq40xx boards, please edit /etc/config/network directly.

The ASUS RT-AC58U V2 and V3 models have different soc and should be considered as a different device.

Also.....

luci->system->software->update lists->filter->batman

...try installing "batmand" B.A.T.M.A.N. layer 3 routing daemon on all routers.

... MAC address isolation is layer 2 I believe but this might help.

Maybe try installing batctl-full on all routers. Or if you have already then try the other ones. Something will jostle it to life.

Are all routers running 19.07.7?

Just a shot in the dark....

versus what this guy did....

config interface 'bat_if'
	option mtu '2304'
	option proto 'batadv_hardif'
	option master 'bat0'
	option ifname 'eth0.2' # sadly this simple line did the trick for me

Above config sample taken from near the bottom of this thread or just click on "solved" at the top of the thread.

It sounds like he was trying to do batman over wired but if you are adding a dumb AP then you are too with respect to the dumb AP as it is being wired in over LAN?

Maybe @markbirss or @cgomesu has seen this layer 2 client isolation problem?

The issue is not isolated (sorry) to ASUS, same behavior on ARCHER

Are all routers running 19.07.7

yes

try installing "batmand" B.A.T.M.A.N. layer 3 routing daemon on all routers.

Alright, this is already beyond my understanding, but I think I saw somewhere that level 3 is "old way" and not correct.
Here: Unless you've got a strong reason to use the older, Layer 3 protocol (such as interoperation with an existing mesh), `batman-adv` is suggested.

Again, the feature seems to be present but it fails to persist. I created a bug report, we'll see what the maintainer says.

option ifname 'eth0.2' # sadly this simple line did the trick for me

My setup is not wired, so I don't have to bridge to lan. The mesh itself works, pings and internet access are there, clients are hopping from one node to another - no issues there. The issue is that on each vlan a client can see other clients.

Under network->wireless, encryption can't be both off and sae.

I'm also curious if STP is impacting layer 2 client isolation since it works on layer 2. Try turning it off for testing purposes?

LuCI->network->interface->mesh lan->physical settings->STP

I'm not using STP in vanilla 802.11s on my modest 3 node mesh but I'm not sure if it's required in BATMAN.

Thank-you as this will help me when I configure BATMAN eventually.

Isolation between two clients connected to the same AP on the same router won't have anything to do with your BATMAN link to the next router. Those packets aren't going to reach the BATMAN interface.

You may want to try a regular locally-routed guest network to see if you can achieve such isolation. I have tested it on the 2 GHz radio of an RT3200 and it does work, though it may not work with other wifi chips and drivers.

An option isolate 1 in the AP configuration is of course critical. Also I have the general "keep guests out of my private IPs" rule in the firewall:

config rule
	option name 'Guest-LAN-Block'
	option target 'REJECT'
	option src 'guest'
	option dest '*'
	option dest_ip '192.168.0.0/16'
	option proto 'all'
	option family 'ipv4'

Since guest IPs are in this IP block, this in theory prevents guest-guest communication, though I didn't think the firewall worked on a "hairpin" to the same interface on the same bridge. I don't have time to test further right now though you could try with and without this rule.

1 Like

For clarification - are all isolated VLANs failing to isolate clients?

option ap_isolation '1' is the wrong syntax.

It should be: option isolate '1'

This should fix it. Client isolation happens in the AP.

Try adding: option isolate '1' to each of the configs shown above....

or just use LuCI->network->wireless->click on the AP you want clients isolated on->advanced settings->check isolate clients.

Save.
Then Save and Apply.
Then reboot.
Now use your phone to join the AP you just set to isolate and see if you can ping any other clients.

If it fails then cycle the power to that AP and retest.

Probably nothing but...

bridge was declared twice.

Fixed, thanks. I don't think it matters though as the next line would override the previous. Weird, I cannot edit the original post.

I'm also curious if STP is impacting layer 2 client isolation since it works on layer 2. Try turning it off for testing purposes?

STP option was added on a later stages of troubleshooting. It doesn't seem to affect this.

Thank-you as this will help me when I configure BATMAN eventually.

I'd be happy if anything I posted would help somebody!

For clarification - are all isolated VLANs failing to isolate clients?

Yes, behavior is similar across all VLANs. When I enable the isolation through batctl -m bat0.4 ap 1, the clients cannot be pinged and port scanner doesn't show any open ports. But the scanner is somehow able to see the others.

option ap_isolation '1' is the wrong syntax.

This is incorrect as per man:
[**meshif** **<netdev>**] **ap_isolation**|**ap** [**0**|**1**]
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html
But I will test it just in case bat0 and bat0.4 should be configured differently

or just use LuCI->network->wireless->click on the AP you want clients isolated on->advanced settings->check isolate clients.

You are mixing two things here. Wireless interfaces are configured in /etc/config/wireless and are configured with option isolate 1. The network interfaces and batman vlans are configured in /etc/config/network and have different option name.

bridge was declared twice.

Fixed, thanks

Isolation between two clients connected to the same AP on the same router won't have anything to do with your BATMAN link to the next router. Those packets aren't going to reach the BATMAN interface.

I don't really have enough knowledge to understand what this means. But batctl -m bat0.4 ap 1 does affect the way the clients interact, so I'd say batman definitely does at least something here.

option dest_ip '192.168.0.0/16'

Wow if I understand correctly what is written here, this is an atomic configuration.
Ah, wait. So only the clients coming from guest zone will be subdued, right? option src 'guest'
But how do the clients get their IPs and resolve DNS? You are blocking it all - option dest '*'

There are rules to allow port 53 and 67 input to the router. (These rules need to be in the file ahead of the overall deny rule, since the first rule that matches will be used). It's a standard guest network configuration.

1 Like

woops my bad...

Fact still remains that...

After changing and saving these settings a reboot or power cycle may be in order to get it working.

Okay, that didn't seem to work. In a way that the lan scanner on the phone is still able to find all the other clients. No ping or open ports - but it just lists them all. May that be ipv6 playing jokes? Is there supposed to be stealth in the first place? Or maybe inaccessible unpingable devices with every port blocked is what I should be expecting?

AND - when I turn batman vlan ap isolation off (batctl -m bat0.4 ap0), my phone is able to ping other devices on the vlan. How's that possible?

Latest gateway firewall:


config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option drop_invalid '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan private'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

config zone
	option name 'guest'
	option output 'ACCEPT'
	option network 'guest'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option dest 'wan'
	option src 'guest'

config rule
	option dest_port '53'
	option src 'guest'
	option target 'ACCEPT'
	option name 'guest_DNS'
	option family 'ipv4'

config rule
	option dest_port '67'
	option src 'guest'
	option target 'ACCEPT'
	option name 'guest_DHCP'
	option family 'ipv4'

config zone
	option forward 'REJECT'
	option name 'work'
	option output 'ACCEPT'
	option input 'REJECT'
	option network 'work'

config rule
	option src 'guest'
	option name 'guest_lan_block'
	option target 'REJECT'
	list dest_ip '192.168.0.0/16'
	option dest '*'
	list proto 'all'

config rule
	option dest_port '53'
	option src 'work'
	option target 'ACCEPT'
	option name 'work_DNS'
	option family 'ipv4'

config rule
	option dest_port '67'
	option target 'ACCEPT'
	option src 'work'
	option name 'work_DHCP'
	option family 'ipv4'

config forwarding
	option dest 'wan'
	option src 'work'

config zone
	option forward 'REJECT'
	option name 'iot'
	option output 'ACCEPT'
	option input 'REJECT'
	option network 'iot'
	option family 'ipv4'

config forwarding
	option dest 'wan'
	option src 'iot'

config rule
	option src 'work'
	option name 'work_lan_block'
	option target 'REJECT'
	list dest_ip '192.168.0.0/16'
	option dest '*'
	option family 'ipv6'
	list proto 'all'

config rule
	option dest_port '53'
	option src 'iot'
	option target 'ACCEPT'
	option name 'iot_DNS'
	option family 'ipv4'

config rule
	option dest_port '67'
	option src 'iot'
	option target 'ACCEPT'
	option name 'iot_DHCP'
	option family 'ipv4'

config rule
	option src 'iot'
	option name 'iot_lan_block'
	option target 'REJECT'
	list dest_ip '192.168.0.0/16'
	option dest '*'
	list proto 'all'


latest bridge firewall


config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan private'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'


Don't worry. Someone will know the answer to this.

In the meantime here is a little food for thought / questionable workarounds:

  1. If you have enough routers you could attach individual routers to the mesh nodes by LAN (or AP/STA? - more demanding on the mesh nodes resources though) and have REAL LANS (run them as routers not dumb APs) per se on independent subnets. Individual routers running 19.07.7 should be able to isolate clients. This is what I am moving towards until pioneers such as yourself carve a path forward.

  2. Another alternative is to make individual VLANS for each device you want isolated. Do laugh. I have done this before just for a laugh with a different router / product family. This is more work - but UCI is arguably cut and paste after the first few are set up - you can just copy them and change a few variables. Layer 2 isolation is imperfect even on other products and may not be secure. Thus just separate everything onto isolated VLANs. Even that is not perfect and does not guarantee security. The number of VLANs you can make is memory constrained. Make a note of how much memory they are using each time you create one.

  3. Turn off software/hardware flow offloading on all routers - maybe it is bypassing layer 2 functionality the same way it impacts QOS/SQM?

Thoughts...

The problem your routers are exhibiting is probably a mixture of router hardware and router software not working correctly more so than your config IMHO.

It looks like BATMAN and OpenWrt are not playing nicely on layer 2 (unable to isolate clients) despite most of your settings looking good. If this is the case then this is something the developers would have to address.

Crazy ideas...

Maybe your phone is caching results (like firefox caching webpages) try verifying isolation by alternative means. Erase the app and reinstall?

Buy more used routers cheap off the internet? That's what I am doing. It's fun!

Solution #1 costs more but then you have more redundancy and functionality / distibuted processing power.

Solution #2 doesn't cost anything. VLANS are free! If you can make one, you can make a 1001!

Last thoughts. IPC40xx product family has always been problematic with VLANS and many choose to avoid it and go for mediatek for VLAN or other chipsets.

I have IPQ4019 / EA8300 meshed with regular 802.11s (you have IPQ4018 in the ASUS I think) so I am probably not going to have success with layer 2 isolation either unless the developers can patch them or whatever may be the case. Eventually I will test and configure BATMAN. But I am fairly happy with the ease of use and stability I have right now with plain 802.11s and my config is twice as fast as my 150Mbps internet connection.

1 Like

Hey, @andy_archer_asus . I can try to help you out but I'm finding it hard to follow everything that you've done and cannot tell how your devices are currently configured. As @mk24 pointed out, client isolation within the same network has nothing to do with batman and it shouldn't be overly complicated to implement it--it's just a matter of adding option isolate 1 to the guest wifi-iface stanza in /etc/config/wireless.

I know you've already put several hours into trying to solve this issue using your current configuration but moving forward, my suggestion is the following:

  • First, reset both your network devices to their default settings.
  • Then follow my mesh guide until the VLAN configuration part. Test connectivity to rule out any hardware-specific issue with the mesh configuration. (Do not modify any default values unless you know what you are doing.)
  • If all looks good, then go ahead and create mesh VLANs (bat0.1, bat0.2, etc.), as explained in the guide. Test connectivity in each VLAN.
  • If the VLAN config is good, create a wireless access point for your guest network and add option isolate 1 to the guest wifi-iface stanza in /etc/config/wireless. Reboot your device and once it comes back up, connect two clients to the guest WAP and try pinging each other.

If that doesn't work, then reply this message with the current config files (/etc/config/network, /etc/config/wireless, /etc/config/dhcp, /etc/config/firewall) of all your network devices (remove the passwords before posting them here) and in your "dumb" AP, let me know if you disabled /etc/init.d/odhcpd, /etc/init.d/dnsmasq, and /etc/init.d/firewall.


Client isolation works just fine and it's trivial to implement it (see @mk24 comments). Nothing wrong with the implementation.

2 Likes

If it's helpful you should be aware that you can run iptables on bridges. nftables is even easier. But current OpenWrt runs iptables, so you just have to enable a sysctl for iptables on bridges, and then write some code to make it so that no LAN->LAN packets are allowed to bridge.

Thank you, Carlos! In fact, I spent several days with your guide - very awesome and I think it's the guide that made setting up the mesh just a breeze. Really really great work.
Now I did have to re-read and re-check some parts until I got a good enough understanding of what's happening there, but at this point I'm pretty certain that the mesh itself works as it supposed to.

I'm at the point where VLANs are created and working, wireless interfaces for the vlans are configured with option isolate 1, so that's not a culprit. Now as I said previously toggling batman's ap_isolation option for vlans changes the behavior in a way that clients are not pingable any more, so batman does do something for this.

Please also check this out:

ap isolation

Available since: batman-adv 2011.4.0

Standard WiFi AccessPoints support a feature known as 'AP isolation' which prevents one connected wireless client to talk to another wireless client. In most situations this is considered a security feature. If the WiFi AP interface is bridged into a batman-adv mesh network it might be desirable to extend this wireless client isolation throughout the mesh network, therefore batman-adv has the ability to do just that (turned off by default). This setting only affects packets without any VLAN tag (untagged packets). The ap isolation setting for VLAN tagged packets is modifiable through the per-VLAN settings.

https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking

This protocol can be used to change VLAN-specific settings
> of a batman-adv soft-interface.
> At the moment only ap_isolation is available, but new ones
can be easily added as soon as batman-adv get to support more.

https://b.a.t.m.a.n.open-mesh.narkive.com/DGlFDtrs/b-a-t-m-a-n-patch-openwrt-feed-batman-adv-enable-batadv-vlan-protocol

I did post my configuration and updated it in the first post - both for the gateway and the bridge.

If you have a setup available for a quick test, can you please try to set ap_isolation for a vlan (batctl -m bat0.1 ap 1), check the status batctl -m bat0.1 ap and try something like service network restart. After you do that, check the status of the option again batctl -m bat0.1 ap and see if it's still enabled.