starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Logout and login back got different IP address #389

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

Originally created by @awsong on GitHub (Dec 8, 2022).

Bug description
I use latest code with a 3rd party OIDC connection. I found that if I logout and login again with the same user, Tailscale client will get a different IP address.

I think it's related to TS2021 protocol. The reason is that after logout, the content of /var/lib/tailscale/tailscaled.state file is like this:

{
  "_current-profile": "cHJvZmlsZS0yZjFh",
  "_machinekey": "cHJpdmtleTpjMGQzNzNlMGVmYzRhNjc5MTgyMTNkMGE1NzgzYWNkMGRhZTUyMGI5NzBhYjMxODQyYTExNzQxNDRmMDc1ODUz",
  "_profiles": "e30=",
  "profile-2f1a": null
}

When logging back in, the only anchor left in state file is machine key, which is set to all 0 when using TS2021, so Headscale is not able to relate this machine to any previous record.

It looks very like the problem lies in Tailscale client, which should preserve nodekey and rotate it as old nodekey after logout. But the same Tailscale client, if I connect to Tailscale control server, logout and login again, it will get back same IP address. Logout behaviour related to state file is the same (only machine key is remained after logout).

To Reproduce

  1. rm -rf /var/lib/tailscale
  2. start tailscaled
  3. tailscale up --login-server http://my.login.server
  4. finish login process
  5. tailscale status, show IP address
  6. tailscale logout
  7. tailscale up --login-server http://my.login.server
  8. finish login process
  9. tailscale status, the IP address is different from step 5 above.
    Context info
Originally created by @awsong on GitHub (Dec 8, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the bug report in this language. --> **Bug description** I use latest code with a 3rd party OIDC connection. I found that if I logout and login again with the same user, Tailscale client will get a different IP address. I think it's related to TS2021 protocol. The reason is that after logout, the content of /var/lib/tailscale/tailscaled.state file is like this: ```json { "_current-profile": "cHJvZmlsZS0yZjFh", "_machinekey": "cHJpdmtleTpjMGQzNzNlMGVmYzRhNjc5MTgyMTNkMGE1NzgzYWNkMGRhZTUyMGI5NzBhYjMxODQyYTExNzQxNDRmMDc1ODUz", "_profiles": "e30=", "profile-2f1a": null } ``` When logging back in, the only anchor left in state file is machine key, which is set to all 0 when using TS2021, so Headscale is not able to relate this machine to any previous record. It looks very like the problem lies in Tailscale client, which should preserve nodekey and rotate it as old nodekey after logout. But the same Tailscale client, if I connect to Tailscale control server, logout and login again, it will get back same IP address. Logout behaviour related to state file is the same (only machine key is remained after logout). <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> **To Reproduce** <!-- Steps to reproduce the behavior. --> 1. `rm -rf /var/lib/tailscale` 2. start tailscaled 3. `tailscale up --login-server http://my.login.server` 4. finish login process 5. `tailscale status`, show IP address 6. tailscale logout 7. `tailscale up --login-server http://my.login.server` 8. finish login process 9. `tailscale status`, the IP address is different from step 5 above. **Context info** <!-- Please add relevant information about your system. For example: - Version of headscale used: compiled off commit 1faac0b3d74e9194efe10a1cd77cea085f7bb64d - Version of tailscale client: 1.35.18, tailscale commit: 1b65630e8361c64fd7c0932c65c4484d9a8a6241 - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version: Linux Debian testing - Kernel version: 6.0.0-4-amd64 - The relevant config parameters you used - Log output -->
adam added the bug label 2025-12-29 01:28:10 +01:00
adam closed this issue 2025-12-29 01:28:10 +01:00
adam commented 2025-12-29 01:28:11 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Dec 8, 2022):

@awsong indeed. I am afraid here Headscale is working as intended.

TS2021 basically deprecates MachineKey (not used anymore in the protocol), so for us this is a completely new client - hence the new IP address.

@juanfont commented on GitHub (Dec 8, 2022): @awsong indeed. I am afraid here Headscale is working as intended. TS2021 basically deprecates MachineKey (not used anymore in the protocol), so for us this is a completely new client - hence the new IP address.
adam commented 2025-12-29 01:28:11 +01:00
Author
Owner
Copy Link

@awsong commented on GitHub (Dec 8, 2022):

What I'm confused about is that Tailscale client seems also use TS2021 connecting to tailscale control server, yet it can preserve same IP address.

@awsong commented on GitHub (Dec 8, 2022): What I'm confused about is that Tailscale client seems also use TS2021 connecting to tailscale control server, yet it can preserve same IP address.
adam commented 2025-12-29 01:28:11 +01:00
Author
Owner
Copy Link

@awsong commented on GitHub (Dec 8, 2022):

I found that noiseConn.Peer() field contains Tailscale client's machine key.

Maybe Tailscale server takes advantage of this information. We could do the same thing, just not sure whether it's a good way to go.

@awsong commented on GitHub (Dec 8, 2022): I found that [noiseConn.Peer()](https://github.com/juanfont/headscale/blob/main/noise.go#L39) field contains Tailscale client's machine key. Maybe Tailscale server takes advantage of this information. We could do the same thing, just not sure whether it's a good way to go.
adam commented 2025-12-29 01:28:11 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Dec 9, 2022):

@awsong you are absolutely right. I got that part of the protocol wrong. I did not find the Peer() method, so assume they deprecated MachineKey :(

I am preparing a PR to fix this.

@juanfont commented on GitHub (Dec 9, 2022): @awsong you are absolutely right. I got that part of the protocol wrong. I did not find the `Peer()` method, so assume they deprecated MachineKey :( I am preparing a PR to fix this.
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#389
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?