added: ap_isolation option for bat0

[seth0r]

To implement client isolation in Gluon there is the isolate option for wireless networks. To extend this isolation over a batman-adv mesh network, batman-adv supports the ap_isolation option. The default batadv config handler supports this option, the gluon-bat0 config handler not. This change adds the support for this option to the gluon-bat0 handler.

[blocktrron]

Please add a description containing your intention with this change. To me this is not obvious.

[AiyionPrime]

@seth0r You might want to answer below, instead of editing older posts, that way the chance of overlooking your contributions is harder.

Maybe we could start one step further back: Why do you think gluon is missing client isolation?

Maybe I'm missing some bigger goal here?

[AiyionPrime]

To implement client isolation in Gluon there is the isolate option for wireless networks. To extend this isolation over a batman-adv mesh network, batman-adv supports the ap_isolation option.

@seth0r in first post

[...] The picture above shows a simple scenario where AP-Isolation is enabled either on node A and B: communications between wireless stations are prevented, while communications between wireless and wired clients are allowed.

Remember that B.A.T.M.A.N.-Advanced AP-Isolation will provide "inter-meshnode communications" prevention only. Therefore if you want to block communications between clients connected to the same access point (actually mesh node) you may want to enable the "classic AP-Isolation" function provided by the access point itself.

https://www.open-mesh.org/projects/batman-adv/wiki/Ap-isolation#What-is-it

@seth0r To me it looks like your goal is to isolate clients.
But to my understanding of the referenced paragraphs this is not, what Ap-Isolation does.
I blocks the communications to wireless stations, but not to other clients.

Not sure whether that is useful (regardless of your goal), I asked @T-X for a review.

All in all I think client isolation in any way is not a goal of gluon or Freifunk.

Feel free to wait longer with answering the requests for more information, but don't feel discouraged, when you find a closed PR then.

[AiyionPrime]

We'll be closing this in seven days.

[T-X]

In my opinion for a Freifunk like open community network does not make much sense. But for a centrally administrated, mesh encrypted one could be.

The PR looks incomplete though. You'd also need to set the wireless isolate flag here: https://openwrt.org/docs/guide-user/network/wifi/basic#common_options1

Ideally, in my opinion, it should be implemented as follows:

• Add a Gluon site configuration option
• Setting it should a) enable the batman-adv isolation and b) wireless isolation
• The batman-adv Extended isolation should be used instead of the basic batman-adv AP isolation. This would allow to also properly filter broadcast/multicast between clients for one thing. And to also filter between wireless and wired clients.
• If the batman-adv gateway mode is "server" (like the check in the gluon-ebtables-filter-ra-dhcp package) then don't filter/isolate towards this particular wired br-client side, as there's gateway behind it that needs to be reachable for all clients.

Then it would be a complete and easy to use feature for administrators, I think.

[seth0r]

In my opinion the decision to use Client Isolation should be with the community. I am certainly not proposing to enable it by default.
Yes, the end goal is to isolate clients, I had planned to build an client isolation package, witch would enable the wireless isolation and batman-adv isolation. An option in the site configuration I had also on my mind.
The problem I had, and all this PR solves, was that I can add the ap isolation option for batman-adv in the config, but it is not respected.
The usual arguments for client isolation are security related, to protect the clients from each other.
Since I did not really understand the Extended Isolation, I was ok with the normal AP isolation. We have in our community only a few wired clients and the lack of isolation for wired clients would allow to provide services in the network despite the client isolation. But I see the point there.

[blocktrron]

Looking at this, I think we can have a place for it in Gluon, although i don't see it in the Freifunk-case.

However, I don't think the current approach is sufficient. I'd like to see a site-option which if toggled activates ap_isolation on batman-layer as well as client-isolation on the hostapd layer.

Can you extend it in this way?

[blocktrron]

Oh, and on a second thought - Does it work with both options activated on a dual-band AP? If I'm not mistaken, this might not be the case, as the data is forwarded not through BATMAN but on the linux bridge-layer, rendering isolation in hostapd as well as batman useless, doesn't it?

[rotanid]

When devices connected to the same FreiFunk router can communicate directly with each other, there is a risk of insecure data transmission. As FreiFunk is an open network, it can be easy for attackers to pose as legitimate devices and gain access to confidential information. Client isolation can reduce this risk by blocking direct communication between devices and ensuring that data is only transmitted via the FreiFunk router.

While some users may be technically proficient and understand the risk, the target audience of FreiFunk is a wider public that may not have the technical knowledge to recognize and avoid the risk of insecure transmissions. Therefore, it is important that FreiFunk networks are securely configured. I think optional security features like client isolation are useful.

your argument might be valid if your understanding of Freifunk is only "free hotspot for internet", but that is not the origin of Freifunk, it is also about communication without internet, and this is totally in contrast with client isolation.

[andycandy-de]

OK, my understanding of Freifunk was that it is an open network aimed at providing as many people as possible with access to the internet. To achieve widespread WLAN coverage, several Freifunk routers can connect to each other and share the internet connection of a router within the network.

So it's a free network evreryone can join and communicate. I am wondering how this can work because it's a open and volatile network. IPs of the participants can change or participants can join to another Freifunk router (roaming) and so can lose the direct connections. Maybe I don't understand the topic enough. However, I'd like to use my Freifunk router to share my internet connection. Unfortunately, I miss the option for client isolation, as I consider it to be meaningful for me and I think the Freifunk router owners also has the option to decide how they want to use the router.

[T-X]

@andycandy-de thanks for your input! I'm appreciating your concerns and thoughts to make internet access more secure for ordinary, everyday users. And yes, client isolation could reduce a potential attack surface in some way.

But note that for people with a more technical background this might look like putting up two sticks and calling it a fence. Yes, the direct way is blocked - but it's easy to circumvent. Any such client isolation approach is never fully fencing of clients in an open network like Freifunk, as anyone can set up a mesh node which itself will always be able to have direct access to its clients.

Strictly speaking, client isolation can only work as a meaningful fence if a) crypto is involved and b) the number of people operating nodes is limited and trusted and c) access initiated from the internet side is blocked as well. But as mentioned before, that is likely not Freifunk anymore for many people.

I think the Freifunk router owners also has the option to decide how they want to use the router.

Well, in (a) Freifunk (community) we have to agree to some, often informal rules to make things work and compatible. Like which mesh routing protocol to use or which wlan channels or wlan ESSID to use, as obvious examples. But also if you'd have client isolation enabled on your node that might break with my expectation to reach my self-hosted file and backup servers on my mesh node at home. So in my opinion (if considered at all) this should be a site and not a per node config-mode option. Of course, a node owner has the right to do whatever they want (as legally allowed to) with their own device. But then (a) Freifunk (community) might also have the right to disallow you from calling it "Freifunk".

[T-X]

Anyway, I think we can cut the political discussion short. For non-Freifunk use-cases client isolation can be useful. And maintainers have signaled that they are open to non-Freifunk use-cases in the past, I think (and the copyfree license seems to go in this direction, too?). Suggested changes to the PR to make it work properly have been made by @blocktrron and me.

---

For a political discussion and clarification in the Freifunk context, it might make sense to open a ticket on the Freifunk Memorandum of Understanding here: https://github.com/freifunk/MoU. That way, ideally we could update the Memorandum at some point to avoid any such ambiguities.

(Feel free to react with emojies to this comment, so that we can get some consensus (or vetos) on this without bloating the ticket further.)

[T-X]

@blocktrron

Oh, and on a second thought - Does it work with both options activated on a dual-band AP? If I'm not mistaken, this might not be the case, as the data is forwarded not through BATMAN but on the linux bridge-layer, rendering isolation in hostapd as well as batman useless, doesn't it?

No, for the simple batman-adv AP isolation it won't, good point. Another reason to go for proper batman-adv extended isolation (which marks packets for firewalls) + ebtables integration.

[blocktrron]

@T-X Is batman even involved here? The packet should not be handled by batman in the dual-band case from my understanding.

[T-X]

@blocktrron absolutely right, batman-adv won't be involved in the dual-band case. What I meant to say was that if you'd go for batman-adv extended isolation then you'll have to add according ebtables rules to handle the marked packets. And while at it you can add according ebtables rules for the dual-band case you mentioned, too.

[blocktrron]

Okay, now I got it. So this needs some more extensive rework. And quite possibly with the additional ebtables rules, I have a hard time seeing this feature land before we've migrated over to firewall4 / nftables.

[neocturne]

Okay, to summarize what we discussed in our last meetup Mumble:

Generally, AP isolation is considered an anti-feature by most people involved in Freifunk. While there is not a single generally accepted definition of "Freifunk", for most people providing free internet access is not the only reason to build a Freifunk network - creating a network that can work as an alternative to the internet for communication and sharing of information is just as or even more important. A Freifunk network doesn't even need to be connected to the internet at all.

However, we realize that Gluon is not only useful for Freifunk! There have been some very cool projects based on Gluon that are not about community meshes at all, for example using it in sensor networks for research purposes.

For the latter reason, we would accept an AP isolation feature PR on the following conditions:

• It must be configurable using site/domain configs, defaulting to off
• It must be documented
• It must be complete, enabling isolation not only in batman-adv, but also between wireless clients of the same node, as discussed in the above comments
• It should not make the code for network configuration significantly more complex

[AiyionPrime]

I think the (missing) documentation could use a section, why this feature is not meant for Freifunk, but for sensor-networks or other projects, that do not aim for open and unrestricted access to the network.

[seth0r]

I would declare this done.
Please let me know if there is anything I should change.

[T-X]

@seth0r this looks much better to me, thanks for adding all these changes!

The way how marks are added and checked looks correct to me. The way batman-adv is configured looks correct, too. The way UCI is configured for WiFi looks good for the client_radio* (I'm not familiar with OWE, someone else might need to confirm that).

Two small ideas for improvements:

• Use the "+" for ebtables firewall rules to match any interface with a specific prefix, so just use "eth+", "client+" and "owe+". That way we would already be compatible if for instance three WiFi radio support were (re)added.
  (Ideally, there'd be some way to retrieve the exact interface names, but don't quite know how that's easily possible right now. I'm only aware of network_get_device() from /lib/functions/network.sh to get the "br-client" from the "client" UCI network section name. Not sure how that would best be done for bridge ports)
• Add a check for the gw_mode, similar to https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-ebtables-filter-ra-dhcp/luasrc/lib/gluon/ebtables/200-dir-dhcpv4. If gw_mode is "server" then don't install those firewall rules. To keep it easy to use a Gluon node as an entry for a gateway with the same firmware and site as for non-gateway nodes.

---

Edit: And nice, extensive documentation. As you mention "Client isolation is a security feature", I'd love to see some warning about its limitations. For instance that this is "best effort" in a community mesh setup, that any node operator can change their config to be able to communicate with a client that is behind any other, unmodified node. And that a client can still be eavesdropped on on the raw WiFi. Mention that it is only a full security feature if WiFi encryption with a non-public password is used in conjunction.

Edit2: As you mention "This mode may not be very useful in a Freifunk context.", I'm wondering if it would make sense to also add there that this would likely also violate the Pico Peering Agreement (https://picopeer.net/), which is part of the Freifunk Memorandum of understanding: https://github.com/freifunk/MoU/blob/master/FreifunkMemorandumofUnderstanding_en.md#principles-of-freifunk (so in the worst case people might ask to rename the project, to not contain the word "Freifunk" then. Don't know/remember if there is a trademark on "Freifunk" by its original founders though, so not sure if it could be legally enforced.)