How to update to the latest Tailscale version?

elvisimprsntr

Updated CE 2.8.1 to 1.90.6.

pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6.pkg

Changelog

CarlMRoss

@elvisimprsntr Updated 25.0.7 to 1.90.6:

fetch https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6.pkg || exit 1 && IGNORE_OSVERSION=yes pkg-static add -f tailscale-1.90.6.pkg && rm -f tailscale-1.90.6.pkg

Installing tailscale-1.90.6...
package tailscale is already installed, forced install
Extracting tailscale-1.90.6: ...... done

tailscale version && tailscale status
1.90.6
long version: 1.90.6
go version: go1.25.3
Warning: client version "1.90.6" != tailscaled server version “1.90.4”

service tailscaled stop && tailscale logout || true && service tailscaled restart && service pfsense_tailscaled restart
Stopping tailscaled.
Waiting for PIDS: 3897.
Stopping tailscaled.
Waiting for PIDS: 27757.
tailscale 42315 - - Waiting for device tailscale0
tailscale 43079 - - Found device tailscale0
tailscale 43473 - - Added tailscale0 to interface group Tailscale
tailscale 43659 - - Bringing up tailscale0 with --auth-key=tskey-auth-xxxxxxxxxxxxxxxx --login-server=https://controlplane.tailscale.com
backend error: invalid key: API key does not exist

service tailscaled stop && tailscale logout || true && service tailscaled start && tailscale up && tailscale version && tailscale status
Stopping tailscaled.
Waiting for PIDS: 41895.
1.90.6
long version: 1.90.6
go version: go1.25.3
Success!

mightykong

@CarlMRoss I've followed your very helpful instructions and got mine updated to 1.90.6. However, I did notice that tailscale does not start on reboot. Is this still happening for you as well? I can get it restarted with the commands you provided but having to do that manually is a concern.

CarlMRoss

@mightykong Yes, my system also requires a restart after reboot, and what has worked for me is:

service tailscaled stop && tailscale logout || true && service tailscaled start && tailscale up

What has worked for updates included a [sysrc tailscaled_enable="YES"] that is supposed to handle tailscale restart after reboot, but it has not worked for me. I am looking into it, and others will be as well. In the meantime, this is my update one-liner command line:

service tailscaled stop && tailscale logout || true && fetch https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.6.pkg || exit 1 && IGNORE_OSVERSION=yes pkg-static add -f tailscale-1.90.6.pkg && rm -f tailscale-1.90.6.pkg && service tailscaled start && tailscale up

Options: add && tailscale version && tailscale status to automate a first check; and, the "rm -f tailscale-1.90.6.pkg" is not needed, but once I saw the suggestion, I decided to keep it.

luckman212

@mightykong @CarlMRoss Looks like you might be experiencing https://github.com/tailscale/tailscale/issues/17793

I also have a 6100 + Tailscale 1.90.6 so I will test mine now.

update: I don't seem to be having this problem, which is odd because I'm usually that one guy in a thousand who has the strange bug that nobody else can reproduce.

Have you tried deleting the contents of /usr/local/pkg/tailscale/state ?

CarlMRoss

@luckman212 I had a nice chat with Netgate Support Bot, https://www.netgate.com/support. I added some highlights below:

"Netgate Support Bot
This is a known issue reported by multiple users: enabling Tailscale with sysrc tailscaled_enable="YES" does not always auto-start Tailscale after a pfSense reboot. The current workaround is to run the following after each reboot manually:
service tailscaled stop && tailscale logout || true && service tailscaled start && tailscale up"

"Netgate Support Bot
Based on all available Netgate forum reports, there is no conclusive evidence that the failure to auto-start Tailscale after reboot when using sysrc tailscaled_enable="YES" is specifically due to Tailscale’s state being stored in a RAM disk. The root cause is still under investigation by the community. Most users confirm that a manual restart is required post-boot regardless of RAM disk settings."

I will check the RAM Disk settings to learn more, but given others' lack of success, I will not experiment with it at this time. Here's what the Chatbot has to say:

"Netgate Support Bot
Yes, you can disable the RAM disk for /var to test if it helps persist Tailscale's state across reboots. Disabling the RAM disk for /var moves log files, RRD graph data, DHCP leases, and package data storage back to disk instead of volatile memory.
Impacts and considerations:
The firewall will write these files directly to disk, so settings and logs will persist through reboots and power losses.
Packages that write to /var, including Tailscale and packages like pfBlockerNG, Snort, or Squid, will have better persistence.
However, disk write activity will increase, especially for logging, RRD data, and DHCP leases.
Disabling the RAM disk reduces the risk of data loss after an improper shutdown, but you may lose some of the benefits (e.g., lower disk wear) intended for devices with fragile storage (e.g., low-cost flash or SD cards).
Some packages may behave differently on disk vs RAM disk and should be tested after reboot.
To disable the RAM disk: Go to System > Advanced > Miscellaneous > RAM Disk Settings in pfSense. Uncheck 'Use RAM Disks' for /var, then Save and Reboot.
If you use logging or packages that need persistent state (like VPNs, reporting, DHCP), disabling the RAM disk usually increases reliability but may wear storage more.""

"Netgate Support Bot
There is no direct evidence in available Netgate forum discussions that deleting the contents of /usr/local/pkg/tailscale/state resolves Tailscale's reboot persistence issue. Most reports focus on restarting the Tailscale service or re-running the 'tailscale up' command after reboot, rather than deleting state files. Deleting this directory could clear a corrupted state or force a fresh authentication. Still, it may also remove valid connections or authentication data, requiring you to re-authenticate Tailscale after reboot.

This approach might temporarily resolve glitches caused by a stale state. It is still not an established solution for reboot persistence, and you should only try it with the expectation that re-authentication will likely be required afterward. Always back up any config or state you plan to remove, just in case."

elvisimprsntr

I never reboot my appliance except for pfSense version upgrades or patches which require reboot. it's supposed to be a 24/7/365 always on device.

mightykong

@elvisimprsntr Great in theory, not in practice. I'm the same, but there are unforseen events. Power outages, crashes, etc. And yes, I'm running a UPS.

CarlMRoss

@elvisimprsntr I agree and only reboot after upgrades and Patches that require it, or in a rare, desperate attempt to fix a persistent problem. As I see it, for now, Version 25.x requires a different workflow for Tailscale updates than CE versions; we have an update workflow that doesn't require a reboot unless it coincides with applying Patches, which I did a few days ago. And we also have a workflow for restarting Tailscale after a reboot that doesn't require creating a new Authentication Code, as I did a couple of times when it all started.

Thank you for keeping us up to date with Tailscale and all the good advice.

CarlMRoss

@luckman212, Thanks for your suggestion. I will check what I have in /usr/local/pkg/tailscale/state, and also the RAM disk settings others have brought up. I could learn more about where Tailscale and pfSense store system files. If I find anything worth sharing, I will let you know.