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

[Feature] Machine sharing #1088

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

Originally created by @stjepangolemac on GitHub (Aug 19, 2025).

Use case

  • no need to run multiple networks anymore if you can share machines
  • many cases should be supported when using shared machine as an ssh jump box

Description

I'm not sure if this is already possible with Headscale but it seems that Tailscale recently enabled sharing of machines between tailnets.

https://tailscale.com/kb/1084/sharing

It's very easy and should often circumvent the problem of wanting to connect to multiple networks. Is this supported or planned at the moment?

Contribution

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

How can it be implemented?

No response

Originally created by @stjepangolemac on GitHub (Aug 19, 2025). ### Use case - no need to run multiple networks anymore if you can share machines - many cases should be supported when using shared machine as an ssh jump box ### Description I'm not sure if this is already possible with Headscale but it seems that Tailscale recently enabled sharing of machines between tailnets. https://tailscale.com/kb/1084/sharing It's very easy and should often circumvent the problem of wanting to connect to multiple networks. Is this supported or planned at the moment? ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancementstale labels 2025-12-29 02:28:12 +01:00
adam closed this issue 2025-12-29 02:28:12 +01:00
adam commented 2025-12-29 02:28:12 +01:00
Author
Owner
Copy Link

@Nathanael-Mtd commented on GitHub (Aug 19, 2025):

That's not possible because Headscale can't handle more than one tailnet.

@Nathanael-Mtd commented on GitHub (Aug 19, 2025): That's not possible because Headscale can't handle more than one tailnet.
adam commented 2025-12-29 02:28:12 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Aug 22, 2025):

That's not possible because Headscale can't handle more than one tailnet.

That would not really be a problem but the tailscale clients can't handle connecting to multiple servers at the same time.

It would be a security nightmare if moron X could connect to different separate Meshes/VPNs/ and somehow started routing between them (or gatewaying traffic at the application layer). Your security policies would grow exponentially.

We had one user do that using docker containers and he is now working on dusting and sorting the paper document archive in the cellar.

@noseshimself commented on GitHub (Aug 22, 2025): > That's not possible because Headscale can't handle more than one tailnet. That would not really be a problem but the tailscale clients can't handle connecting to multiple servers at the same time. It would be a security nightmare if moron X could connect to different separate Meshes/VPNs/<whatever you want to call it> and somehow started routing between them (or gatewaying traffic at the application layer). Your security policies would grow exponentially. We had one user do that using docker containers and he is now working on dusting and sorting the paper document archive in the cellar.
adam commented 2025-12-29 02:28:12 +01:00
Author
Owner
Copy Link

@Nathanael-Mtd commented on GitHub (Aug 22, 2025):

That's not possible because Headscale can't handle more than one tailnet.

That would not really be a problem but the tailscale clients can't handle connecting to multiple servers at the same time.

It would be a security nightmare if moron X could connect to different separate Meshes/VPNs/ and somehow started routing between them (or gatewaying traffic at the application layer). Your security policies would grow exponentially.

We had one user do that using docker containers and he is now working on dusting and sorting the paper document archive in the cellar.

It's not an issue with Tailscale public service, but it only works because there are 1 backend service for every Tailscale nodes and tailnet, and it knows nodes and keys for each device to share it between nodes (with user acceptance needed).

It's not possible on Headscale because Headscale can't host multiple tailnets. And the tailscale netmap system probably can't allow nodes from different headscale instances.

Maybe if Headscale implement a trust system to link different Headscale instances it can be possible, but I'm pretty sure that implementation never will never happens because it's out of the project scope.

@Nathanael-Mtd commented on GitHub (Aug 22, 2025): > > That's not possible because Headscale can't handle more than one tailnet. > > That would not really be a problem but the tailscale clients can't handle connecting to multiple servers at the same time. > > It would be a security nightmare if moron X could connect to different separate Meshes/VPNs/<whatever you want to call it> and somehow started routing between them (or gatewaying traffic at the application layer). Your security policies would grow exponentially. > > We had one user do that using docker containers and he is now working on dusting and sorting the paper document archive in the cellar. It's not an issue with Tailscale public service, but it only works because there are 1 backend service for every Tailscale nodes and tailnet, and it knows nodes and keys for each device to share it between nodes (with user acceptance needed). It's not possible on Headscale because Headscale can't host multiple tailnets. And the tailscale netmap system probably can't allow nodes from different headscale instances. Maybe if Headscale implement a trust system to link different Headscale instances it can be possible, but I'm pretty sure that implementation never will never happens because it's out of the project scope.
adam commented 2025-12-29 02:28:13 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 21, 2025):

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

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

@github-actions[bot] commented on GitHub (Nov 29, 2025):

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

@github-actions[bot] commented on GitHub (Nov 29, 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#1088
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?