Prevent VXLAN packages from Wired mesh from entering BATMAN

[jplitza]

Bug report

What is the problem?

Due to miscabling/misconfiguration, it is possible for packets coming from the mesh to be encapsulated in VXLAN packets, sent out of a wired mesh port, arriving at a LAN port of another node and then and being fed back into the mesh with the VXLAN encapsulation as multicast.

What is the expected behaviour?

A node receiving VXLAN packets with the correct VNI and destination address for its domain does not forward them into the mesh, even if received on a port not configured for wired mesh.

Gluon Version:

v2021.1.2 (but probably later as well?)

Site Configuration:

https://github.com/FreifunkBremen/gluon-site-ffhb

Custom patches:

[neocturne]

Hmm, in the past, gluon-ebtables-filter-multicast should have caught such packets, but this has been relaxed in 98f3f63. In theory, batman-adv's noflood feature should ensure that these packets are never flooded through the mesh, and only forwarded to nodes that have joined the multicast group.

I guess we could add a specific rule to never allow packets to Gluon's multicast group address.

cc @T-X

[T-X]

Good question. I'm wondering if it could actually be a feature. For example I could have a building/dorm/allotment use it's own, local Gluon mesh domain. But with bordering nodes into the city wide Gluon mesh domain. Then the city's mesh packets could travel from one side of the local area domain to the other via mesh-on-wan/lan / VXLAN. As long as there are not too many bordering nodes in the local mesh domain, due to BATMAN's O(n^2) overhead relative to the number of neighbor nodes.

If we could filter with ebtables for the VXLAN VNI, that would be great. But as far as I know we can't easily do that with ebtables right now. So yeah, maybe then ebtables filtering for IPv6 destination ff02::15c + UDP destination port 4789 would be safer for now.

[jplitza]

In theory, batman-adv's noflood feature should ensure that these packets are never flooded through the mesh, and only forwarded to nodes that have joined the multicast group.

I arrived at that conclusion a few hours later as well (by sniffing the interface below). ;-) So I'm not sad if this issue is simply closed.

[neocturne]

Still seems like it might have very weird effects (including lost packets due to MTU issues) as soon as two nodes are connected incorrectly. I'd prefer gluon-ebtables-filter-multicast to overblock by default; requiring to disable it for some unusual use cases is fine (and making it more configurable is also a long-term wishlist item...)