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

Inter-controlplane federation #724

New Issue
Closed
opened 2025-12-29 02:22:58 +01:00 by adam · 4 comments
adam commented 2025-12-29 02:22:58 +01:00
Owner
Copy Link

Originally created by @ckiee on GitHub (Jun 11, 2024).

Use case

Hi! Currently I cannot use headscale, because I like to share my machines with friends who are on controlplane.tailscale.com. They are using a network effect, and it prevents me from accessing a good feature like infinite/automatic key expiry which I currently have to rotate every 90d even though I do not personally require this.

Description

I would like headscale instances to be able to talk to eachother, and to the tailscale.com CP — specifically for device sharing across controlplanes.

Our control plane will be provided with an authkey for an another controlplane, which it will use to create "proxy machines", replicating our machines' view of the world, but on another instance.

Me, a [headscale.]puppycat.house tailnet/user will be able to talk to tailscale.com:

  • My headscale instance is configured with user accounts on other *scale instances.
  • headscale nodes share -i … --to tailscale.com or [headscale-blub.]example.com (another headscale)
  • I am given a share link for my machine's virtual clone on this other instance, which I give to my friend
  • My friend accepts this invite to "my" machine, and starts sending traffic.
  • The connection is established on their controlplane, which my controlplane is a client to.
  • The controlplane-acting-as-client receives this, and rewrites their messages to my controlplane -- while adding a suffix to their machine name (same as current intra-CP sharing on tailscale.com: their-machine.their-tailnet.ts.net, we would have their-machine.their-user.headscale.example.com)
  • The rest of the port punching protocol proceeds normally, and the users of the machines cookiemonster.ckie.headscale.puppycat.house and deep-space-probe.snake-beaver.controlplane.tailscale.com are happy because they just connected to eachother
    (Note: We have to ensure we have intersections in the two instances' DERP lists, otherwise it will be sad and randomly fail when we have to fallback.)

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

Drawbacks to consider

  • We might break our social contract with tailscale, as this removes some dependence on tailscale.com. Probably not a big deal since we don't have SSO/SCIM/MDM/audit logs, and those seem like the bigger ticket items for corps than self-hosted federation between multiple controlplanes which really changes nothing for centralized orgs. So this only benefits people socially, and they will still move to the corporate controlplane if they already were going to before.
  • This complicates the design workload of the controlplane.
  • This can create a very ugly protocol if we do not seriously walk through it before jumping into impl.

Alternatives to consider

We could extend the controplane↔client protocol to allow for more on-band network management and make this bridge a separate component that can be ran anywhere. This would keep headscale lean but introduce a bazillion other considerations that we wouldn't need when we are the controlplane. Still, it is possible.

Originally created by @ckiee on GitHub (Jun 11, 2024). ### Use case Hi! Currently I cannot use headscale, because I like to share my machines with friends who are on `controlplane.tailscale.com`. They are using a [network effect](https://en.wikipedia.org/wiki/Network_effect), and it prevents me from accessing a good feature like infinite/automatic key expiry which I currently have to rotate every 90d even though I do not personally require this. ### Description I would like headscale instances to be able to talk to eachother, and to the tailscale.com CP — specifically for device sharing across controlplanes. Our control plane will be provided with an authkey for an another controlplane, which it will use to create "proxy machines", replicating our machines' view of the world, but on another instance. Me, a `[headscale.]puppycat.house` tailnet/user will be able to talk to `tailscale.com`: - My headscale instance is configured with user accounts on other *scale instances. - `headscale nodes share -i … --to tailscale.com` or `[headscale-blub.]example.com` (another headscale) - I am given a share link for my machine's virtual clone on this other instance, which I give to my friend - My friend accepts this invite to "my" machine, and starts sending traffic. - The connection is established on their controlplane, which my controlplane _is a client to_. - The controlplane-acting-as-client receives this, and rewrites their messages to my controlplane -- while adding a suffix to their machine name (same as current intra-CP sharing on tailscale.com: `their-machine.their-tailnet.ts.net`, we would have `their-machine.their-user.headscale.example.com`) - **The rest of [the port punching protocol](https://tailscale.com/blog/how-nat-traversal-works) proceeds normally**, and the users of the machines `cookiemonster.ckie.headscale.puppycat.house` and `deep-space-probe.snake-beaver.controlplane.tailscale.com` are happy because they just connected to eachother (_Note:_ We have to ensure we have intersections in the two instances' DERP lists, otherwise it will be sad and randomly fail when we have to fallback.) ### Contribution - [X] I can write the design doc for this feature - [X] I can contribute this feature ### Drawbacks to consider - [x] We might break our social contract with tailscale, as this removes some dependence on tailscale.com. Probably not a big deal since we don't have SSO/SCIM/MDM/audit logs, and those seem like the bigger ticket items for corps than self-hosted federation between multiple controlplanes which really changes nothing for centralized orgs. So this only benefits people socially, and they will still move to the corporate controlplane if they already were going to before. - [ ] This complicates the design workload of the controlplane. - [ ] This can create a very ugly protocol if we do not seriously walk through it before jumping into impl. ### Alternatives to consider We could extend the controplane↔client protocol to allow for more on-band network management and make this bridge a separate component that can be ran anywhere. This would keep headscale lean but introduce a bazillion other considerations that we wouldn't need when we are the controlplane. Still, it is possible.
adam added the enhancementstale labels 2025-12-29 02:22:58 +01:00
adam closed this issue 2025-12-29 02:22:58 +01:00
adam commented 2025-12-29 02:22:59 +01:00
Author
Owner
Copy Link

@nadongjun commented on GitHub (Aug 13, 2024):

I’m also looking for a similar feature. It seems that Tailscale’s configuration might allow for merging tailnets. Do you have any updates on this?

Related resources:

@nadongjun commented on GitHub (Aug 13, 2024): I’m also looking for a similar feature. It seems that Tailscale’s configuration might allow for merging tailnets. Do you have any updates on this? Related resources: - https://gist.github.com/drio/b90b772a2857e873bf95214841ee95d1 - https://github.com/tailscale/tailscale/issues/183
adam commented 2025-12-29 02:22:59 +01:00
Author
Owner
Copy Link

@ckiee commented on GitHub (Aug 13, 2024):

Those two links seem to be running two tailscaled's which while working around the problem does defeat the point of this (and you can see the two concurrent instances struggle a bit to both config the host)

Currently I am waiting for some validation from @juanfont, et al. before I dive in at some unknown point (^:

@ckiee commented on GitHub (Aug 13, 2024): Those two links seem to be running two `tailscaled`'s which while working around the problem does defeat the point of this (and you can see the two concurrent instances struggle a bit to both config the host) Currently I am waiting for some validation from @juanfont, et al. before I dive in at some unknown point (^:
adam commented 2025-12-29 02:22:59 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 26, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Dec 26, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:23:00 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 2, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Jan 2, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 stale
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#724
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?