"Tailscale is not online" problem

AlphaDog45

I am also effected by this and it happened upon a reboot within the 180 day key expiry. Running the tailscale down and up with reuath, followed by pasting the URL into a browser fixes it, but is far from ideal.

manupfdude

Hi all,

I wanted to share that I’m also experiencing issues with Tailscale (v1.86.4) on the latest pfSense CE (v2.8.0).
After either a pfSense reboot or a Tailscale service restart, my node is logged out of Tailscale — exactly as many of you have described here.

It bothered me enough that I opened a support ticket with the Tailscale team. I explained the problem, included details, and linked this thread as a reference. The good news is that support responded quickly and said they’re setting up a pfSense VM to reproduce the issue.

In the meantime, they suggested a workaround:

“Based on the behavior described here and in the thread, it looks like the auth key used for authentication may be expiring. Since OAuth clients don’t expire, switching to an OAuth Client rather than an Auth Key might resolve this.
See our docs here:
https://tailscale.com/kb/1215/oauth-clients#registering-new-nodes-using-oauth-credentials

I tested this, and after configuring Tailscale with OAuth, everything worked!
Tailscale now stays connected and authenticated even after a reboot or service restart.

That said, I did tell support that while OAuth solves the issue, it used to work out of the box with the simpler interactive login / auth key flow. Something seems to have changed on the Tailscale side, and I hope they identify and fix it. But until then, the OAuth workaround is a solid fix.

I’d love to hear how it’s working for the rest of you.
Anyone else try OAuth yet?

Cheers

yobyot

@manupfdude This is a very inventive approach!

I'd like to try it but have a couple of questions about pfSense implementation.

Where did you enter the key and secret? And what scopes did you grant the Tailscale OAuth client?

manupfdude

@yobyot
I've SSHed into pfsense
and for the sake of testing I've simply run the command:

tailscale up --auth-key=tskey-client-kQ_THE_REST_IS_A_SECRET\?preauthorized=true\&ephemeral=false --accept-dns=false --accept-routes --advertise-exit-node --advertise-routes=X.X.X.X/24 --advertise-tags=tag:pfsense

Note the preauthorized=true and ephemeral=false
I gave this key all permissions (temporarly as I just wanted to verify it's working)
of course I had to register the tag used also in the ACL tags pane:
https://login.tailscale.com/admin/acls/visual/tags

so far so good

lbm_

@manupfdude Interesting. Thanks for the detailed answer. Im also facing the same issue unfortunately where I need to auth again after an reboot.

Are you with this approach having issues with the advertised routes not working ? I have to manually do (I havent tried your approach yet to see if this fixes the issue).

 tailscale set --advertise-routes=192.168.1/24,192.168.2.0/24 after I login. Even though they are set in the UI

yobyot

Well,

I spent some time tonight playing around with this and I think I have it.

Some suggestions for others:

Generate the OAuth client in the Tailscale admin before anything else.
Make sure to create the tag you'll need. One per pfSense instance (and clearly, one OAuth client per pfSense instance).
Give the OAuth client the permissions you think appropriate.
Very Important: make sure that you can generate an API key with the OAuth creds. The OAuth creds are, apparently, used by the CLI to generate an API key. The latter is what does the trick in tailscale up.
Do this from the pfSense console:
curl -d "client_id=kY5Mv4h8kQ11CNTRL" -d "client_secret=tskey-client-kY5[invalidchars]CNTRL-ZXo2FfBbb[moreinvalidchars]GVT" "https://api.tailscale.com/api/v2/oauth/token"
If you don't get back something like this, you'll never be able to get it to work:
{"access_token":"tskey-api-kM[lotsofinvalidchars]NTRL-[stillmoreinvalidchars]9YevL","token_type":"Bearer","expires_in":3600,"scope":"all"}
Here's what worked for me if the above returned an API token:
/usr/local/bin/tailscale up --auth-key=tskey-client-[greekedout]GVT\?ephemeral=false\&preauthorized=true --accept-dns=false --accept-routes --advertise-exit-node --advertise-routes=192.168.211.0/24 --advertise-tags=tag:[yourtaghere]
Make sure you have the cron package installed. Then add a @reboot entry using the full path (see above). I also added a cron entry every six hours as if Tailscale is up, this command does not interrupt or reset any sessions.

I've left some bytes of the creds in these examples to make it clearer where your full creds should go. The curl command requires the escape symbol (\) in the parameters that will be passed to the control plane.

FWIW, I lost an hour or more because I had (God only knows why) set Tailscale on one pfSense instance to accept DNS. Do this and the router cannot resolve the control plane API endpoint. Dumb. And I own it.

I don't know if this "fixes" everything. But it's a lot of work and it shouldn't be necessary. Somehow, this package to be useful needs to survive reboot without the need to go to these lengths.

left4apple

@manupfdude Thanks for the info. If I understand correctly, pfSense Tailscale package will ensure tailscaled is running all the time even after reboot, yet Tailscale is actually using your command to authenticate itself, right? The KEY entered in the pfSense Tailscale UI has already expired(or you can enter fake KEY there).

manupfdude

@left4apple Basicaslly - Yes.
The key on the UI is no longer relevant (once you go with the oauth route)
I'm on version 1.88.3 of tailscale, after several reboots (due to power outages...) - TS still connected and authenticated :-)

KStarRunner

This seems like a bug to me. Every other platform where TailScale is setup, the tskey-auth is only used once, and then immediately discarded. Clients don't maintain the original tskey-auth, but rather a separate credential which was bootstrapped by the tskey-auth.

So why is pfSense storing this key? IMHO, the GUI should accept the key, and once bootstrapped, delete it. The persistent presence of the tskey-auth makes me think pfSense keeps attempting to re-use it each time the service restarts.

The correct behavior would seemingly be to accept the tskey-auth in the GUI, and then once the bootstrap is completed, delete it from the stored configuration. Should a new value be entered into the GUI, presume that means a new bootstrap is needed and start fresh. But as long as that box remains blank, keep on using the existing credentials.

yobyot

@KStarRunner Clearly, it’s a bug.