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] Ability to change IP address #804

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

Originally created by @aalmenar on GitHub (Sep 25, 2024).

Use case

The use case is for reorder the ips according to my "network planning". Also if you reinstall a server it would be easier to have it have the old ip address for whatever reason you may need. It also should bring feature parity to Tailscale that currently allows to do this

Description

The feature should be as simple as setting a specific IP address to a node.

Contribution

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

How can it be implemented?

I suppose of how i tested it, by updating the database the field of ip of the node, reconnect the client and done, new ip is working. Obviously magicDNS needs update but i still dont know how it works exactly.

Originally created by @aalmenar on GitHub (Sep 25, 2024). ### Use case The use case is for reorder the ips according to my "network planning". Also if you reinstall a server it would be easier to have it have the old ip address for whatever reason you may need. It also should bring feature parity to Tailscale that currently allows to do this ### Description The feature should be as simple as setting a specific IP address to a node. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? I suppose of how i tested it, by updating the database the field of ip of the node, reconnect the client and done, new ip is working. Obviously magicDNS needs update but i still dont know how it works exactly.
adam added the enhancementstale labels 2025-12-29 02:24:13 +01:00
adam closed this issue 2025-12-29 02:24:13 +01:00
adam commented 2025-12-29 02:24:13 +01:00
Author
Owner
Copy Link

@europacafe commented on GitHub (Oct 9, 2024):

+1
Tailnet IP should be able to be changed to, say, an old IP that is no longer used, or any IP that hasn't been used.

@europacafe commented on GitHub (Oct 9, 2024): +1 Tailnet IP should be able to be changed to, say, an old IP that is no longer used, or any IP that hasn't been used.
adam commented 2025-12-29 02:24:13 +01:00
Author
Owner
Copy Link

@vadimpiven commented on GitHub (Oct 12, 2024):

looks like this issue is similar https://github.com/juanfont/headscale/issues/2012

@vadimpiven commented on GitHub (Oct 12, 2024): looks like this issue is similar https://github.com/juanfont/headscale/issues/2012
adam commented 2025-12-29 02:24:14 +01:00
Author
Owner
Copy Link

@aalmenar commented on GitHub (Oct 14, 2024):

looks like this issue is similar #2012

its not exactly the same. That one talks about reusing ip addresses, i mean to manually set the wanted ip address to a node

@aalmenar commented on GitHub (Oct 14, 2024): > looks like this issue is similar #2012 its not exactly the same. That one talks about reusing ip addresses, i mean to manually set the wanted ip address to a node
adam commented 2025-12-29 02:24:14 +01:00
Author
Owner
Copy Link

@yanlong-li commented on GitHub (Jan 10, 2025):

At present, this can only be achieved by modifying db.sqlite

@yanlong-li commented on GitHub (Jan 10, 2025): At present, this can only be achieved by modifying db.sqlite
adam commented 2025-12-29 02:24:14 +01:00
Author
Owner
Copy Link

@lukaslindnermusic commented on GitHub (Mar 2, 2025):

+1 for this.

It would be good for optically grouping devices together, for example, all production servers have 100.64.10.1-254, all test servers 100.64.20.1-254 etc., or all raspberry pis are in the range from 100.64.0.20-100.64.0.29, or other use cases.

As it is already possible to do this by just changing the value in the database, maybe this could also be realized by a command such as "sudo headscale nodes change-ipv4 -i 3 100.64.20.3" or something like this.

Of course, there should be a check and exit with a warning if the new ip is already in use.

@lukaslindnermusic commented on GitHub (Mar 2, 2025): +1 for this. It would be good for optically grouping devices together, for example, all production servers have 100.64.10.1-254, all test servers 100.64.20.1-254 etc., or all raspberry pis are in the range from 100.64.0.20-100.64.0.29, or other use cases. As it is already possible to do this by just changing the value in the database, maybe this could also be realized by a command such as "sudo headscale nodes change-ipv4 -i 3 100.64.20.3" or something like this. Of course, there should be a check and exit with a warning if the new ip is already in use.
adam commented 2025-12-29 02:24:15 +01:00
Author
Owner
Copy Link

@lukaslindnermusic commented on GitHub (Mar 2, 2025):

Additionally, there could also be an optional, additional option to specify the ip directly within the node register command.

@lukaslindnermusic commented on GitHub (Mar 2, 2025): Additionally, there could also be an optional, additional option to specify the ip directly within the node register command.
adam commented 2025-12-29 02:24:15 +01:00
Author
Owner
Copy Link

@itbencn commented on GitHub (May 7, 2025):

+1
This proposal is great. Some usage scenarios require associating IP and devices and keeping them unchanged. Tailscale currently supports modification, but headscale cannot be modified and the IP changes after each redeployment

@itbencn commented on GitHub (May 7, 2025): +1 This proposal is great. Some usage scenarios require associating IP and devices and keeping them unchanged. Tailscale currently supports modification, but headscale cannot be modified and the IP changes after each redeployment
adam commented 2025-12-29 02:24:15 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 6, 2025):

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

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

@github-actions[bot] commented on GitHub (Aug 14, 2025):

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

@github-actions[bot] commented on GitHub (Aug 14, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:24:15 +01:00
Author
Owner
Copy Link

@lukaslindnermusic commented on GitHub (Aug 14, 2025):

Nooooo, please reopen it. 😢

Why is a stale-bot auto-closing this? The devs are not waiting for a delayed response by a user, but the other way around.
There are multiple users that would really like this feature!

@lukaslindnermusic commented on GitHub (Aug 14, 2025): Nooooo, please reopen it. 😢 Why is a stale-bot auto-closing this? The devs are not waiting for a delayed response by a user, but the other way around. There are multiple users that would really like this feature!
adam commented 2025-12-29 02:24:15 +01:00
Author
Owner
Copy Link

@aalmenar commented on GitHub (Dec 10, 2025):

Can we talk about reopening this one?

@aalmenar commented on GitHub (Dec 10, 2025): Can we talk about reopening this one?
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#804
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?