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

[Bug] Used IPs are kept in memory for ephemeral nodes #1158

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

Originally created by @dparv on GitHub (Nov 20, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Seems that used IP addresses for nodes are kept in memory for ephemeral machines.

Expected Behavior

Ephemeral node IPs shouldn't take used IP addresses as they are destroyed.

Steps To Reproduce

In a use-case of running a CI that connects every 5 minutes using ephemeral key/node and using a /24 network will cause the 256th call to fail to connect with failed to allocate IP. Restarting the headscale server resolves this problem.

Environment

- OS: Ubuntu@22.04
- Headscale version: 0.26.1
- Tailscale version: 1.88.3

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

Nov 20 11:51:57 b37fe952876839BootstrapVm headscale.headscaled[307571]: 2025-11-20T11:51:57Z ERR http internal server error error="allocating IPv4 address: failed to allocate IP" code=500

from tailscale client:

backend error: handling register with auth key: allocating IPs: allocating IPv4 address: failed to allocate IP
Originally created by @dparv on GitHub (Nov 20, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior Seems that used IP addresses for nodes are kept in memory for ephemeral machines. ### Expected Behavior Ephemeral node IPs shouldn't take used IP addresses as they are destroyed. ### Steps To Reproduce In a use-case of running a CI that connects every 5 minutes using ephemeral key/node and using a /24 network will cause the 256th call to fail to connect with `failed to allocate IP`. Restarting the headscale server resolves this problem. ### Environment ```markdown - OS: Ubuntu@22.04 - Headscale version: 0.26.1 - Tailscale version: 1.88.3 ``` ### Runtime environment - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ### Debug information ``` Nov 20 11:51:57 b37fe952876839BootstrapVm headscale.headscaled[307571]: 2025-11-20T11:51:57Z ERR http internal server error error="allocating IPv4 address: failed to allocate IP" code=500 ``` from tailscale client: ``` backend error: handling register with auth key: allocating IPs: allocating IPv4 address: failed to allocate IP ```
adam added the bug label 2025-12-29 02:28:36 +01:00
adam closed this issue 2025-12-29 02:28:36 +01:00
adam commented 2025-12-29 02:28:36 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Nov 21, 2025):

This was merged for next release, I believe it should solve it: https://github.com/juanfont/headscale/pull/2831

@kradalby commented on GitHub (Nov 21, 2025): This was merged for next release, I believe it should solve it: https://github.com/juanfont/headscale/pull/2831
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 bug
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#1158
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?