[os-tailscale] Support tailscale set arguments

[AlexRusbridge]

Important notices
Before you submit a pull request, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I opened an issue first for non-trivial changes and linked it below.
• AI tools were used to create at least part of the code submitted herewith.

If AI was used, please disclose:

• Model used:
  • Claude Opus 4.6
• Extent of AI involvement:
  • Understanding the plugin architecture and debugging. No LLM generated code was used.

---

Related issue

• Closes Tailscale - add peer relay function #5122

---

Describe the problem

Tailscale have a preference for adding new flags to the tailscale set command, instead of tailscale up.

// When adding new flags, prefer to put them under "tailscale set" instead
// of here. Setting preferences via "tailscale up" is deprecated.

up.go

This means that any new functionality added to tailscale is likely to be configured through set. In the plugins current state, we can't configure these options.

We can already see the impact with the --relay-server-port flag.

---

Describe the proposed solution

This PR adds a new rc.d script tailscaled_set that will apply tailscale set flags after the tailscaled service has started.

It supports defining arguments via the tailscaled_set_args variable.

For now, we can configure --relay-server-port and --webclient via the UI. But this PR opens up the possibility of more set arguments.

---

Note: There is another solution, where the FreeBSD port of tailscaled could support tailscaled_set_args alongside it's tailscaled_set_args.

[sheridans]

This looks like a promising idea, let me have a look over it and ensure nothing breaks.

[AlexRusbridge]

Hey @sheridans, have you had a chance to look at and test the changes?

Looking more, at the Tailscale docs; The only other flags only covered by the set command are:

• --relay-server-static-endpoints
• --report-posture

Should we look at adding them to this PR too?

[aaronblair]

This looks awesome. Great work @AlexRusbridge. Interested to the review from @sheridans. Can't wait to have this feature.

[AlexRusbridge]

Hey @sheridans, any update on reviewing this PR?

[aaronblair]

@sheridans: Would it be possible to get this reviewed and merged? It would be a great add for Tailscale on OPNSense.

[aaronblair]

@fichtner: Thoughts?

[fichtner]

This is difficult... I'm not a fan of adding another service rc.d script to accommodate extra features. Ideally this is something FreeBSD wants similar to the following which would keep everything in one rc.conf template:

https://github.com/opnsense/ports/blob/2238512cd2de1664d52fd146f59e6f64956792ab/security/tailscale/files/tailscaled.in#L109-L111

The question that comes to mind is why we're then also adding a time-based workaround for probing readiness for 15 seconds... worst case it will just block for that period. Why do modern services regress back to requiring these ancient workarounds?

Cheers,
Franco

[AlexRusbridge]

Hey @fichtner, thanks for taking a look. I do agree using a wait here isn't ideal, and it's prompted me to try and find the root cause as to why the relay server port isn't persisting between reboots.

I think what's happening is the implementation of tailscaled in the FreeBSD port is causing the /var/db/tailscale/tailscaled.state (which also contains any config defined by tailscale set) to be rebuilt each time on boot:

1. tailscaled_poststart launches the daemon and immediately runs tailscale up ${tailscaled_up_args}, before the daemon has reconnected and reached the Running state.
2. When the tailscaled daemon is running, tailscale up will follow a lightweight path where it sources config from the existing tailscaled.state.
   • See tailscale/cli/up.go#L585-L593
3. In our case, the daemon isn't Running, so we fall through to the full Start() path, which rebuilds config from defaults, plus whatever is in tailscaled_up_args.
   • See tailscale/cli/up.go#L675-L681
4. Using the full Start() path causes the tailscale.state to be overwritten, causing the relay server port to be lost on boot.

I think this problem is unique to the FreeBSD port, as other OSs will let the tailscaled handle the reconnection to the tailnet, which uses the existing tailscaled.state.

Because of that, I agree that the ideal solution here is to propose an upstream fix to the FreeBSD port. Specifically, a change so poststart doesn't re-run tailscale up on an already-configured node, since the deamon can already connect to a tailnet using the existing tailscaled.state.

I'm not sure I have the time and/or experience to take this any further, but open to other suggestions.