starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Allow multicast traffic to flow through the network #653

New Issue
Closed
opened 2025-12-29 02:21:39 +01:00 by adam · 3 comments
adam commented 2025-12-29 02:21:39 +01:00
Owner
Copy Link

Originally created by @WhyNotHugo on GitHub (Feb 27, 2024).

Why

Currently clients connect using headscale/tailscale cannot route multicast traffic to each other, which means standard protocols like mDNS don't work. The result is that clients cannot discover each other as if they were in the same network.

Bespoke discovery protocols, like syncthing's local discovery (also done over multicast) can't work, and device can't find each other when on the same network. In the case of syncthing, it resorts to global discovery (using public discovery servers), and devices connect to each other over the Internet.

From a general discovery point of view, it's as if devices were not on the same network.

Description

WireGuard itself supports multicast traffic fine, and discovery works normally as if devices were on the same network. Tailscale client seems to use a tun-type device rather than a wireguard-type device, so Wireguard's native support is of no use for this case.

A tun-type device routes at layer 3 traffic and usually results in multicast packets not travelling through to other endpoints. A tap-type device needs to be used instead.

As a potential solution, I'd like to configure my own clients will create a tap network device rather than a tun type network device, so that my clients can discover each other and interact with each other as if they were on the same physical network.

Do you think this is feasible?

Additional context

There's a feature request for this on Tailscale's issue tracker too, thought the whole thread does not add any additional information.

Originally created by @WhyNotHugo on GitHub (Feb 27, 2024). ## Why Currently clients connect using headscale/tailscale cannot route multicast traffic to each other, which means standard protocols like mDNS don't work. The result is that clients cannot discover each other as if they were in the same network. Bespoke discovery protocols, like syncthing's local discovery (also done over multicast) can't work, and device can't find each other when on the same network. In the case of syncthing, it resorts to global discovery (using public discovery servers), and devices connect to each other over the Internet. From a general discovery point of view, it's as if devices were not on the same network. ## Description WireGuard itself supports multicast traffic fine, and discovery works normally as if devices were on the same network. Tailscale client seems to use a `tun`-type device rather than a `wireguard`-type device, so Wireguard's native support is of no use for this case. A `tun`-type device routes at layer 3 traffic and usually results in multicast packets not travelling through to other endpoints. A `tap`-type device needs to be used instead. As a potential solution, I'd like to configure my own clients will create a `tap` network device rather than a `tun` type network device, so that my clients can discover each other and interact with each other as if they were on the same physical network. Do you think this is feasible? ## Additional context There's [a feature request](https://github.com/tailscale/tailscale/issues/1013) for this on Tailscale's issue tracker too, thought the whole thread does not add any additional information.
adam added the enhancement label 2025-12-29 02:21:39 +01:00
adam closed this issue 2025-12-29 02:21:39 +01:00
adam commented 2025-12-29 02:21:40 +01:00
Author
Owner
Copy Link

@WhyNotHugo commented on GitHub (Feb 27, 2024):

I'm actually starting to think that this wouldn't require changes on the server side. At least for an experimental approach, if the clients behave consistently with one another, the server doesn't need to care about these details since it's not part of the network itself... right?

@WhyNotHugo commented on GitHub (Feb 27, 2024): I'm actually starting to think that this wouldn't require changes on the server side. At least for an experimental approach, if the clients behave consistently with one another, the server doesn't need to care about these details since it's not part of the network itself... right?
adam commented 2025-12-29 02:21:40 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Mar 4, 2024):

Hi,

This is sadly nothing we can fix, has to be done quite a few levels lower in the stack. Wireguard also has problems with this and as you mention, a tun device per now doesnt support this, and we cannot change that.

I'm personally interested in this and also tracking the mentioned Tailscale issue, and there is no reason that when that is solved, then we should also be able to have it.

@kradalby commented on GitHub (Mar 4, 2024): Hi, This is sadly nothing we can fix, has to be done quite a few levels lower in the stack. Wireguard also has problems with this and as you mention, a tun device per now doesnt support this, and we cannot change that. I'm personally interested in this and also tracking the mentioned Tailscale issue, and there is no reason that when that is solved, then we should also be able to have it.
adam commented 2025-12-29 02:21:40 +01:00
Author
Owner
Copy Link

@WhyNotHugo commented on GitHub (Mar 4, 2024):

Yup, further researching this led to the same conclusion: nothing to do here for now.

I think experimenting with clients is feasible (as long as they all behave the same), but that doesn't require support from the control plane AFAIK (unless you want to mix tun and tap clients).

@WhyNotHugo commented on GitHub (Mar 4, 2024): Yup, further researching this led to the same conclusion: nothing to do here for now. I think experimenting with clients is feasible (as long as they all behave the same), but that doesn't require support from the control plane AFAIK (unless you want to mix tun and tap clients).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#653
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?