VIGIL MESH

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

BehaviorRouted L3 mesh (unicast)L2 broadcast domain (VIGIL-MESH)
Unicast: ping, SSH, HTTPYesYes
Link-local broadcast and multicastNot carried, by designReplicated to every member, encrypted
mDNS / SSDP / WS-Discovery discoveryLimited — service-by-service workaroundsJust like on a LAN
LAN gamesDepends on the game — direct IP connection where it existsMatch discovery as if on a single switch
DDS / ROS 2 multicastLimited — unicast peers to configureReplicated 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.

Frequently asked questions

Why doesn't mDNS work across my VPN?
Because mDNS is a link-local multicast protocol: it speaks "to everyone on the link", never beyond a router. A classic L3 mesh VPN carries point-to-point unicast between machines — it routes packets to one destination, it doesn't broadcast. The mDNS packet is therefore never carried to the other members. That's not a bug: it's the expected behavior of a routed network.
Can LAN games be made to work over Tailscale?
LAN match discovery relies on local broadcast, which Tailscale — like WireGuard meshes in general — doesn't support natively according to its public documentation. Some games let you connect by direct IP address: in that case, the unicast connection through the tunnel works. When a game only offers automatic discovery, there is no general solution on the routed-network side. Refer to Tailscale's official documentation for the current state.
Is this a flaw in Tailscale?
No. It's an architecture choice, not an implementation flaw: a WireGuard mesh establishes encrypted point-to-point unicast tunnels and presents a routed L3 network. That model is simple, robust and proven — it just doesn't carry link-local broadcast, which by definition doesn't cross a router. NetBird, another WireGuard mesh, makes the same choice.
Does any alternative handle multicast natively?
Yes, two approaches exist. ZeroTier builds a genuine L2 Ethernet bridge, frames included. VIGIL-MESH stays an L3 overlay but turns each network into a broadcast domain: broadcast, multicast and link-local IP are replicated to every member as if on a switch, encrypted end to end with rotating per-sender keys. mDNS, SSDP, WS-Discovery, ROS 2 DDS discovery and LAN games get their LAN behavior back.
Is broadcast across a mesh encrypted with VIGIL-MESH?
Yes, end to end. Each multicast sender broadcasts under its own sender key, distributed to authorized members through the encrypted sessions — never by the relay. The key rotates when a member is revoked, when the sender restarts, and at least every 24 hours; the relay replicates packets without ever being able to read them.
Read nextL2 broadcast and encrypted multicast