How to update to the latest Tailscale version?
-
@Wolf666, I have the same version as you and the same problem. Found this solution with Grok:
fetch https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3_1.pkg
IGNORE_OSVERSION=yes pkg-static add -f tailscale-1.88.3_1.pkg
It may be possible to do it in one step,
IGNORE_OSVERSION=yes pkg-static add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3.pkg -
@CarlMRoss Thanks, it worked! I cannot give you a thumb-up because I am not allowed.
-
@Wolf666, Thumbs up to Grok AI. It beat ChatGPT and Claude to the answer from the start.
-
Finally took the plunge and installed CE 2.8.1 on a spare appliance and updated to 1.88.3_2
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3_2.pkgI applied the tailscale patch. No observed issues.
-
Updated CE 2.8.1 to 1.90.1.
There is already a .2 and .3
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.1.pkg -
Seems like only the client was updated
tailscale status Warning: client version "1.90.1" != tailscaled server version "1.88.3" -
Did you restart the Tailscale daemon?
-
@elvisimprsntr said in How to update to the latest Tailscale version?:
Did you restart the Tailscale daemon?
DOh! That fixed it :)
-
Updated CE 2.8.1 to 1.90.4.
Looks like they are already working on .6
pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.90.4.pkg -
For pfSense+ Version 25.0.7 FreeBSD 15.0-CURRENT: I had a recent issue after upgrading Tailscale to 1.90.4 and afterwards rebooting pfSense. Tailscale would not authenticate. After researching, I found a solution and a suggested workflow for future upgrades.
First, I was able to get Tailscale to re-authenticate by executing the following commands (Tailscale Service was offline after the reboot):
service tailscaled stop
tailscale logout
sysrc tailscaled_enable="YES"
service tailscaled start
tailscale upSo that you know, here is the AI-generated one-liner for future upgrades on 25.x FreeBSD 15.0-CURRENT systems. I will test with the next available upgrade package:
"service tailscaled stop && tailscale logout || true && fetch https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-X.Y.Z.pkg || exit 1 && IGNORE_OSVERSION=yes pkg-static add -f tailscale-X.Y.Z.pkg && rm -f tailscale-X.Y.Z.pkg && sysrc tailscaled_enable="YES" && service tailscaled start && tailscale up && tailscale version && tailscale status"
-
@CarlMRoss said in How to update to the latest Tailscale version?:
upgrading Tailscale to 1.90.4 and afterwards rebooting pfSense
Although I am on 2.8.1 CE, I have never observed the problem you encountered.
All I've ever needed to do is restart the Tailscale daemon after upgrade.
-
@elvisimprsntr Thank you. I would not be surprised if I ended up with a lengthy solution that works but needs significant improvement.
I am using a Netgate 6100 with pfSense+, starting with version 24.x. I had updated Tailscale without trouble per this discussion by using pkg add -f https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-x.y.z.pkg. This worked until pfSense+ version 25.0.07 (FreeBSD 15-CURRENT) and Tailscale upgrade 1.88.3.
After several attempts and web searches, I was only able to install that upgrade by using: fetch https://pkg.freebsd.org/FreeBSD:15:amd64/latest/All/tailscale-1.88.3.pkg, and then IGNORE_OSVERSION=yes pkg-static add -f tailscale-1.88.3.pkg.
Then, I could not restart Tailscale, no matter what I tried, including the sequence: service tailscaled stop, tailscale logout, service tailscaled start, and then tailscale up.
-
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 -
@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: ...... donetailscale 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 existservice 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! -
@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.
-
@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.
-
@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? -
@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."
-
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.
-
@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.
