mDNS Over WireGuard: Three Gates Before a Peer Answers

Setting the multicast flag on a WireGuard device makes the interface eligible for discovery software, and that is the end of what the flag does. It does not tell the protocol where a group packet should go, and on a device with several peers there is no single obvious answer. Three separate gates stand between a running daemon and a discovered service.

Test them in order, because passing one tells you nothing about the next.

Gate one: the flag and the daemon's policy

A Linux WireGuard device is created as a point-to-point link without ARP, and it does not carry the multicast flag by default. Adding the flag is a local interface change, performed by whatever manages the device. Avahi has its own view of the world on top of that, and its default policy skips point-to-point interfaces entirely. Two independent eligibility tests therefore apply before a single packet moves.

So the daemon needs an explicit decision, not merely a running process. Its documented controls include allow-interfaces, deny-interfaces and allow-point-to-point, and the last one is the setting people miss.

The checks below report the link flags, the multicast route and whether the daemon's configuration parses at all:

ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check

A daemon that started successfully has not necessarily opened sockets on the interface you care about. Read its effective configuration rather than assuming that service status equals coverage.

Gate two: the route to the group

The second gate is ordinary routing. A packet addressed to 224.0.0.251 follows the forwarding table like anything else, and if the table sends it out of the physical LAN interface then no WireGuard configuration will change that. Fix the route first and the rest of the investigation becomes shorter. Look at what the kernel reports for the group address before touching any peer keys.

With no specific route, the kernel falls back to the link's own multicast handling, which is why the default looks right on a flat LAN and wrong as soon as the same group traffic is supposed to leave by a tunnel. The failure is silent from the sender's side: the query goes somewhere, and the answer never arrives.

Gate three: WireGuard picks one peer per packet

WireGuard selects an outgoing peer by looking up the destination in the allowed-address sets, and the Linux transmit path performs that lookup once per packet. There is one result, and the packet is encrypted for that peer. The same group prefix appearing in several peers' allowed lists does not create membership or replication; it creates an ambiguous lookup that resolves to one of them.

On a dedicated two-endpoint link this is exactly what you want, because there is one intended recipient for the deliberately carried group traffic. On an interface with five peers it is a limitation, not a feature, and the fix belongs in the design rather than in the configuration of any one peer.

A fan-out design needs an explicit relay, separate links, or a different discovery mechanism altogether. Publishing a two-endpoint recipe as a many-client solution because every client can ping the gateway is how this gets deployed wrong.

Inbound direction is checked differently: a received packet's source must fall inside the authenticated peer's allowed list. Adding a multicast destination there does not replace the sender's real source ownership.

Reflection is a boundary, not a bridge

Avahi's reflector reproduces mDNS messages between the interfaces it selects, at the application layer. It is a discovery boundary between networks, not an Ethernet bridge and not a general multicast router. Two reflectors joined to the same networks will happily create a loop of repeated announcements.

Reflection also hands service names and their metadata to another network, which is a privacy decision as much as a routing one. Restrict the selected interfaces, and use service filters where the installed version supports them, so only the announcements an authorised user needs cross the boundary.

Discovery and use remain separate results. A client can see an announcement for a service whose advertised address is unreachable from where the client sits, or whose port its access policy refuses. Confirm the service connection after the announcement appears, and if the application supports a stable DNS name or an explicit server address, prefer that over extending link-local discovery. The cryptokey routing description covers the destination-based peer selection this all depends on.