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] Assign IP addresses to non-headscale devices #811

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

Originally created by @yuri-so on GitHub (Oct 4, 2024).

Use case

Currently, when accessing multiple networks with identical subnets (e.g., 10.10.10.0/24), only one network can be routed at a time. Switching between these networks requires manually disabling one subnet route and enabling another, which is inefficient.

Description

Introduce the ability to assign unique Headscale IPs (100.64.0.0/10) to specific devices, bypassing the need to route entire subnets. This would allow direct access to individual devices across multiple networks without conflicting subnet routes.

Example Use Case:

Network1: 10.10.10.0/24 (Switch/AP at 10.10.10.11)
Network2: 10.10.10.0/24 (Another Switch/AP at 10.10.10.175)

With this feature, users could assign a unique Headscale IP (e.g., 100.64.x.x) to the switch at 10.10.10.11 on Network1 and another Headscale IP to the switch at 10.10.10.175 on Network2. This eliminates the need for manual routing of entire subnets and simplifies access to specific devices on overlapping subnets.

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 @yuri-so on GitHub (Oct 4, 2024). ### Use case Currently, when accessing multiple networks with identical subnets (e.g., 10.10.10.0/24), only one network can be routed at a time. Switching between these networks requires manually disabling one subnet route and enabling another, which is inefficient. ### Description Introduce the ability to assign unique Headscale IPs (100.64.0.0/10) to specific devices, bypassing the need to route entire subnets. This would allow direct access to individual devices across multiple networks without conflicting subnet routes. Example Use Case: Network1: 10.10.10.0/24 (Switch/AP at 10.10.10.11) Network2: 10.10.10.0/24 (Another Switch/AP at 10.10.10.175) With this feature, users could assign a unique Headscale IP (e.g., 100.64.x.x) to the switch at 10.10.10.11 on Network1 and another Headscale IP to the switch at 10.10.10.175 on Network2. This eliminates the need for manual routing of entire subnets and simplifies access to specific devices on overlapping subnets. ### Contribution - [X] 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:24:19 +01:00
adam closed this issue 2025-12-29 02:24:19 +01:00
adam commented 2025-12-29 02:24:19 +01:00
Author
Owner
Copy Link

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

If I understand you correctly, I do not think we can do this, the only thing we do is pass a set of routes down to the Tailscale client, which then builds a routing table on what to send where. Headscale by itself cant really map addresses to subnet routers.

If I am misunderstanding and you can find a feature like this in Tailscale's documentation, then we might be able to build it.

As a potential work around, tho tedious, you can announce /32 subnet routes, so for the subnet router that is in front of Switch/AP at 10.10.10.11 you can announce 10.10.10.11/32, but you will have to manage them all "manually" or make some script to talk to the API.

@kradalby commented on GitHub (Oct 4, 2024): If I understand you correctly, I do not think we can do this, the only thing we do is pass a set of routes down to the Tailscale client, which then builds a routing table on what to send where. Headscale by itself cant really map addresses to subnet routers. If I am misunderstanding and you can find a feature like this in Tailscale's documentation, then we might be able to build it. As a potential work around, tho tedious, you can announce `/32` subnet routes, so for the subnet router that is in front of `Switch/AP at 10.10.10.11` you can announce `10.10.10.11/32`, but you will have to manage them all "manually" or make some script to talk to the API.
adam commented 2025-12-29 02:24:20 +01:00
Author
Owner
Copy Link

@ChibangLW commented on GitHub (Oct 4, 2024):

4via6 subnet routers is probably what you want or need.

It should be supported in headscale.

I am not sure it would be a good idea to assign a tailnet ip to non-tailnet devices (if at all possible).

@ChibangLW commented on GitHub (Oct 4, 2024): [4via6 subnet routers](https://tailscale.com/kb/1201/4via6-subnets) is probably what you want or need. It should be supported in headscale. I am not sure it would be a good idea to assign a tailnet ip to non-tailnet devices (if at all possible).
adam commented 2025-12-29 02:24:20 +01:00
Author
Owner
Copy Link

@yuri-so commented on GitHub (Oct 4, 2024):

4via6 might actually be it.

i disabled ipv6 tho

implementing that into my workflow is going to be a pain in the ass lmao

@yuri-so commented on GitHub (Oct 4, 2024): 4via6 might actually be it. i disabled ipv6 tho implementing that into my workflow is going to be a pain in the ass lmao
adam commented 2025-12-29 02:24:20 +01:00
Author
Owner
Copy Link

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

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

@github-actions[bot] commented on GitHub (Jan 3, 2025): This issue is stale because it has been open for 90 days with no activity.
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#811
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?