There is an obvious appeal to putting the security function on the radio.

Traffic is protected before it reaches any general-purpose host. One less box to mount, one less cable to route, one less thing to power and one less thing to fail. Mesh radios increasingly run Linux, commonly OpenWrt, so a tunnel stack will cross-compile and it will run.

Getting it to run is not the difficult part.

The difficult part is that a mesh network and a point-to-point tunnel are different kinds of object, and the interaction between them is where deployments quietly lose the property they were bought for.

A mesh is a shape, not a link #

A tunnel between two hosts is a link. It has two ends, both known in advance, and its job is to move packets between them.

A mesh is a network that discovers its own topology and re-routes continuously as nodes move, appear, fail and come back. Its defining property is that nobody configured the shape and nobody has to reconfigure it when the shape changes.

Those two models fight.

Consider how a tunnel decides where a packet goes. In WireGuard's case, reachability is a static association between a peer and a set of addresses, configured ahead of time. It is a routing table wearing a cryptographic hat, and it is deliberately fixed.

Dynamic routing is the opposite proposition. The whole point is that no one enumerates which destinations sit behind which neighbour, because that changes minute to minute.

Vendor documentation is unusually blunt about the consequence. Running dynamic routing over WireGuard effectively requires one peer per tunnel, because as soon as several peers share a tunnel you have to hand-define which networks live behind each of them, which is precisely the work dynamic routing exists to eliminate.

So you get a choice. Run one tunnel interface per neighbour, and accept that interface count and key state grow with the mesh rather than with the node. Or hand-configure the topology of a network whose entire purpose is that its topology is not configured.

Neither is what anyone thought they were buying.

Multicast is where it actually breaks #

Routing protocols find their neighbours by shouting.

Broadcast and multicast are how a node announces itself and how it learns what else is out there. Take that away and the protocol has no discovery mechanism. OSPF over a tunnel needs special configuration precisely because it cannot use multicast to find neighbours, and the general guidance is that any protocol depending on broadcast or multicast is unlikely to work across a tunnel at all.

On a radio this matters far more than it does on wire, and for a reason that is easy to miss.

On a shared medium, a broadcast is genuinely one transmission. The node keys up once and every node in range hears it. Convert that same payload to unicast and you transmit it once per recipient, over the same air, competing with itself.

The mesh stacks already understand this and treat it as an explicit trade. batman-adv converts multicast to unicast only up to a configurable number of destinations, defaulting to sixteen, and reverts to broadcast flooding above that threshold. The reasoning recorded in the implementation is that low-bitrate wireless broadcast is expensive and that its cost scales with the size of the mesh, so below a certain fan-out, unicast is cheaper.

That is a deliberate airtime decision, made by the layer that can see the medium.

Wrap the whole thing in a point-to-point tunnel and the decision disappears, because everything above the tunnel is unicast by construction. The mesh loses the ability to make the trade it was designed to make, on the one resource it cannot manufacture more of.

Where the crypto sits decides what survives #

There are three broad placements, and they are not interchangeable.

Below the routing layer, encrypting each radio link individually. The mesh keeps its topology, its discovery and its broadcast efficiency, because internally it is routing in the clear. The air is protected. Every node that forwards a packet can also read it, which is acceptable when every node is equally trusted and unacceptable when some of them might not come back.

Above the routing layer, encrypting end to end between endpoints and letting the mesh forward ciphertext. Confidentiality survives an untrusted forwarder. But the routing layer has to stay legible enough to keep working, which means the topology remains visible to anyone listening, and topology is intelligence. Who is talking to whom, how often, and from roughly where is a serious disclosure even when the content is opaque.

Or in place of the routing layer, which is the tunnel-over-mesh configuration described above, and is the one that produces a set of links where there used to be a network.

None of the three is free, and the choice between them is a genuine engineering trade rather than a best practice. What happens in most deployments is that nobody makes the choice explicitly. A tunnel gets deployed because it was the available tool, and the properties that were given up are discovered later, usually under exactly the conditions that made the mesh attractive in the first place.

The dependency nobody draws #

The management path inherits all of this and adds a circularity.

Management traffic to a node in the mesh traverses the mesh, competes for the same airtime as everything else, and degrades under the same conditions. That is tolerable. What is not tolerable is a design where the management path depends on the tunnel, because the failure you most need to reach a node to fix is a routing or keying failure, which is the failure that removes your ability to reach it.

A management channel that cannot survive the loss of the thing it manages is not a management channel. It is an assumption.

The conversation that does not happen #

This is not a hard problem intellectually. It is a hard problem organisationally.

A security engineer looks at a mesh radio and sees a network interface, which is a reasonable thing to see, because that is what the operating system presents. A radio engineer looks at the same device and sees a shared medium with a finite airtime budget and a routing protocol keeping the network alive on top of it.

Both are correct. The integration falls between them, and in most organisations they do not share a document, a backlog or a meeting.

The result is a system that works on the bench, works in the car park, and behaves differently the first time it is asked to operate as an actual mesh, at range, in motion, with contention.

The question was never whether the software would run on the radio.

It will.

The question is whether what you have afterwards is still a mesh.