Documentation
Multicast and mDNS over Tailscale: why it doesn't get through
Ping works, SSH works, yet the printer stays invisible, the Chromecast never shows up and the game finds no LAN match. If this is happening to you over Tailscale, nothing is broken: device discovery relies on link-local broadcast, which a routed L3 network doesn't carry — an architecture choice of WireGuard meshes, not a flaw. This page explains the mechanism, walks through the workarounds, then presents a structurally different approach: a mesh that is a broadcast domain.
The symptom: connectivity is perfect, discovery stays empty
The picture is always the same. The machines are properly connected: they ping each other over their mesh address, SSH and shares by IP work flawlessly. But everything that relies on "seeing the devices around you" stays hopelessly empty:
- The game lists no LAN match, even though both players are on the same Tailscale network.
- The remote office printer or scanner never appears in the device list.
- Chromecast, AirPlay or the TV are not offered as casting targets.
- Two ROS 2 nodes on different machines never discover each other: topics stay silent from one machine to the other.
- The UDP announcements of a PLC or a sensor never reach the supervision workstation.
The explanation: discovery relies on link-local broadcast
On a LAN, devices don't find each other by magic: they announce themselves "to everyone on the link". mDNS/Bonjour (printers, Chromecast, AirPlay), SSDP/UPnP (TVs, media boxes), WS-Discovery (ONVIF cameras), ROS 2's DDS discovery and LAN game lobbies all send link-local broadcast or multicast packets. Those packets are, by definition, confined to the segment: they don't cross a router, and strict stacks even reject any packet that has been routed.
Tailscale is a mesh built on WireGuard: it establishes encrypted point-to-point unicast tunnels between machines and presents each of them with a routed L3 network. It's a simple, robust and proven model — but a routed network carries packets to one destination, it doesn't broadcast. An mDNS packet sent on one side has no path to the other members: nobody replicates it, nobody receives it.
Hence the apparent paradox: unicast (ping, SSH, HTTP) crosses perfectly, while the whole discovery layer — the one that makes a LAN pleasant — disappears. According to Tailscale's public documentation, broadcast and multicast are not supported natively, and mDNS/SSDP discovery is limited there. NetBird, another WireGuard mesh, makes the same architecture choice.
The usual L3-side workarounds, and their limits
On a routed network, you can often work around the problem service by service. These approaches work, but none of them restores the general behavior of a LAN:
- Force unicast when the application allows it: add the printer by its IP address, type the game server's IP when the game offers a direct connection, declare a list of unicast peers in ROS 2's DDS configuration.
- Configure service by service: every application that relies on discovery needs its own solution, to be documented and maintained through every address or device change.
- Relay discovery through third-party software: mDNS reflectors exist as a general routed-network technique, at the cost of an extra component to install and operate on every site.
The common limit is structural: these workarounds address special cases, not the cause. When an application only offers automatic discovery — which is the case for many LAN games and most consumer devices — there is no general solution on the side of a network that doesn't carry broadcast.
The structurally different approach: a mesh that is a broadcast domain
The other path isn't to work around the absence of broadcast, but to restore it. VIGIL-MESH treats each network as an L2 broadcast domain: broadcast, multicast and link-local IP are replicated to every member, as if each one were plugged into the same switch — wherever they physically sit. mDNS, SSDP, WS-Discovery, ROS 2's DDS discovery and LAN games cross the encrypted mesh like on a switch.
- Broadcast is encrypted end to end: each multicast sender broadcasts under a rotating sender key, and the relay replicates packets without being able to read them.
- The transport is QUIC with end-to-end TLS 1.3, with a direct path between peers and seamless migration from the relay to the direct path.
- Zero inbound ports on the nodes: restored broadcast requires no firewall opening.
- The rest of the mesh does the same job as a classic mesh: peer to peer, centralized management, routes to a remote LAN.
Routed L3 network vs L2 broadcast domain
| Behavior | Routed L3 mesh (unicast) | L2 broadcast domain (VIGIL-MESH) |
|---|---|---|
| Unicast: ping, SSH, HTTP | Yes | Yes |
| Link-local broadcast and multicast | Not carried, by design | Replicated to every member, encrypted |
| mDNS / SSDP / WS-Discovery discovery | Limited — service-by-service workarounds | Just like on a LAN |
| LAN games | Depends on the game — direct IP connection where it exists | Match discovery as if on a single switch |
| DDS / ROS 2 multicast | Limited — unicast peers to configure | Replicated IP multicast (ROS 2 validation on the roadmap) |
Neither column is "the right one" in the absolute: if your uses are purely unicast, a routed L3 mesh serves you very well. The right-hand column matters the day discovery, application multicast or LAN games become part of the need.