Bug #16342
openIncorrect behavior of logout button in Tailscale
0%
Description
Tailscale after press "Logout and Clean" button and then try to start connection again, it will produce error in the status that aut-key no valid
In the Tailscale admin panel in the server it will consider this connection as from different instance.
So if I switch to the reused key, yach time I do logout and connect again it will create a new instance in admin panel in Tailscale server.
Tested on 24.11 and 25.07-RC
Tailscale 1.76.1 and 1.82.5
Files
Updated by aleksei prokofiev 9 months ago
Also, if change working key to different, save changes and then put working key back it won't connect and key will be no valid.
Updated by dylan mendez 9 months ago
- Status changed from New to Confirmed
Can confirm this issue in latest pfSense development versions
Updated by Per Otto Opstad 9 months ago
This issue is not limited to clicking the log out button in Tailscale.
In my case, I’m experiencing the same problem without ever logging out manually.
It seems to occur when the firewall is rebooted. Upon reboot, the Tailscale key appears to become corrupted or invalid.
My suspicion is that the problem is related to how the key is stored and later retrieved — possibly resulting in a faulty or incomplete key during the fetch process.
Updated by Christian McDonald 9 months ago
I'm seeing different behavior here.
When using a reusable preauth key, if I click `Logout and Clean`, the local Tailscale instance logs out and clears the local state cache. However, if I restart Tailscale with the same preauth key, Tailscale reauthenticates and creates a new machine node in the Admin Panel. This is expected behavior.
What else am I missing here?
I'm not seeing this:
it will produce error in the status that aut-key no valid
Updated by aleksei prokofiev 8 months ago
Retested on 25.07.1
stepes:
1. Create key in admin panel
2. Setup Tailscale on pfSense using this key and connect instance
3. Change key in pfSense to any wrong key or random number and save
4. Put correct key back and save
5. You can't connect any more with this key
If you use a Reusable key and try to provided these steps, so each time when you put back correct key it will create new instance in admin panel.
Updated by Christian McDonald 8 months ago
aleksei prokofiev wrote in #note-6:
Retested on 25.07.1
stepes:
1. Create key in admin panel
2. Setup Tailscale on pfSense using this key and connect instance
3. Change key in pfSense to any wrong key or random number and save
4. Put correct key back and save
5. You can't connect any more with this keyIf you use a Reusable key and try to provided these steps, so each time when you put back correct key it will create new instance in admin panel.
Thanks for the repro steps. I will try again
Updated by Roger Winfield 6 months ago
Per Otto Opstad wrote in #note-3:
This issue is not limited to clicking the log out button in Tailscale.
In my case, I’m experiencing the same problem without ever logging out manually.It seems to occur when the firewall is rebooted. Upon reboot, the Tailscale key appears to become corrupted or invalid.
My suspicion is that the problem is related to how the key is stored and later retrieved — possibly resulting in a faulty or incomplete key during the fetch process.
I have the same reboot issue on 25.07.1 SG4200. After a normal reboot the following status:
Tailscale Status (/usr/local/bin/tailscale status)- Health check:
- - You are logged out. The last login error was: invalid key: API key does not exist.
Any help or suggestions would be greatly appreciated.
Updated by Per Otto Opstad 6 months ago
Yes, i can confirm this is an issue on the latest public build 25.07.1.
Developers, please take another look. I can give you access to my fw for further testing.
This is for my company a big issue since i have all my customer managed using tailscale.
If a fw is restarted i loose management to the firewall.
Roger Winfield wrote in #note-9:
Per Otto Opstad wrote in #note-3:
This issue is not limited to clicking the log out button in Tailscale.
In my case, I’m experiencing the same problem without ever logging out manually.It seems to occur when the firewall is rebooted. Upon reboot, the Tailscale key appears to become corrupted or invalid.
My suspicion is that the problem is related to how the key is stored and later retrieved — possibly resulting in a faulty or incomplete key during the fetch process.I have the same reboot issue on 25.07.1 SG4200. After a normal reboot the following status:
Tailscale Status (/usr/local/bin/tailscale status)
- Health check:
- - You are logged out. The last login error was: invalid key: API key does not exist.
Any help or suggestions would be greatly appreciated.
Updated by Paul Mavrovic 3 days ago
I can confirm same issues with many managed firewalls I have.
Updated by Per Otto Opstad 2 days ago
- File install_tailscale_fix.sh install_tailscale_fix.sh added
I have implemented a working workaround and after further testing I believe the root cause is now clear.
The issue is not related to logout specifically, but to how the auth-key is used by the service.
Root cause:
The pfSense Tailscale service is passing the --auth-key on every startup, not only during the initial registration.
This causes the following:
- The node is already registered and has valid local state
- On service restart (e.g. reboot), Tailscale attempts to authenticate again using the auth-key
- The key is no longer valid (expired / already used / not reusable in this context)
- Tailscale enters a broken state:
"You are logged out. The last login error was: invalid key: API key does not exist"
This explains why:
- The issue happens on reboot (without logout)
- Multiple users in this thread see the same behavior
- Connectivity is lost even though the node was previously working
Workaround:
I have resolved this by modifying the rc script:
/usr/local/etc/rc.d/pfsense_tailscaled
Specifically, removing/commenting out:
pfsense_tailscaled_up_flags="--auth-key=..."
After doing this:
- Tailscale starts using the stored state instead of re-authenticating
- Reboots no longer break connectivity
- No new nodes are created in the admin panel
Additionally, I implemented a watchdog that:
- Detects known failure states (invalid key / logged out / NoState)
- Restarts the service automatically
- Re-applies the fix if needed
Conclusion:
The auth-key should only be used for initial provisioning, not on every service start.
As long as --auth-key is passed on each startup, this issue will continue to occur.
Updated by Christian McDonald 2 days ago
Per Otto Opstad wrote in #note-12:
I have implemented a working workaround and after further testing I believe the root cause is now clear.
...
Conclusion:
The auth-key should only be used for initial provisioning, not on every service start.As long as --auth-key is passed on each startup, this issue will continue to occur.
Thanks, reports like this make fixing things much easier. :)
