[os-tailscale] Settings are applied with the frozen `tailscale up`, silently resetting every preference the plugin does not manage

[nikosch86]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug

os-tailscale applies its configuration by running tailscale up ${tailscaled_up_args} from the rc script's poststart, on every service start.

Upstream has deliberately frozen tailscale up because it is destructive: it reverts every preference not named on the command line back to its default. From tailscale/tailscale#15460:

we froze tailscale up to stop the bleeding and force people to move over to set

tailscale set is the supported replacement — "entirely imperative, only modifying the things you mention on the command line". Because up is frozen, preferences added to Tailscale after the freeze exist only in set: up has no flag for them, cannot express them, and resets them.

The consequence on OPNsense is that any preference the plugin does not itself model is silently discarded on every boot, every service tailscaled restart, and every settings save in the GUI (saving restarts tailscaled). There is no error, nothing in the UI, and nothing in the logs.

I could not find a previous report of this root cause — the existing reports I found describe individual symptoms of it (see Additional context), which is why I'm filing it separately.

This is not a regression, so there is no last-known-working version: it has been the behaviour for as long as the plugin has applied settings with up. What changed over time is Tailscale's side — as more preferences became set-only, the amount of configuration up silently discards grew.

To Reproduce

Steps to reproduce, using --relay-server-port (peer relay, Tailscale >= 1.86) as a concrete example of a set-only preference with no plugin setting:

1. Configure and enable Tailscale normally under VPN > Tailscale.
2. From a shell, set a preference the plugin does not model:
   tailscale set --relay-server-port=40000
3. Confirm it took effect: tailscale debug peer-relay-sessions → Server port: 40000.
4. Restart tailscaled by any of: rebooting, service tailscaled restart, or simply pressing Save on VPN > Tailscale > Settings (no setting need actually be changed).
5. Check again: tailscale debug peer-relay-sessions → Server port: not configured.

The preference is also gone entirely from tailscale debug prefs. Nothing is logged and the UI gives no indication that a setting was discarded.

Expected behavior

Preferences that the plugin does not manage should survive a service restart.

Applying settings with tailscale set instead of tailscale up achieves this: set only touches the flags it is given, so preferences outside the plugin's scope — present and future — are preserved rather than destroyed. It also aligns the plugin with the command upstream supports.

Screenshots

Not applicable — the failure is silent and produces no UI output. That is part of the problem.

Relevant log files

The generated /etc/rc.conf.d/tailscaled (note there is no --relay-server-port, and no way to add one):

tailscaled_up_args="--timeout=60s --advertise-exit-node=false --accept-routes --accept-dns=false --ssh=false --login-server=https://REDACTED --advertise-routes=10.23.89.0/24 ${tailscaled_up_args_ext}"

The up invocation, in /usr/local/etc/rc.d/tailscaled:

86:  start_postcmd="${name}_poststart"
103: tailscaled_poststart()
109:         if [ -n "${tailscaled_up_args}" ]; then
110:                 ${ctlname} up ${tailscaled_up_args}

Before and after a service tailscaled restart:

# tailscale debug peer-relay-sessions
Server port: 40000
Sessions count: 4
# service tailscaled restart
Stopping tailscaled.
Starting tailscaled.
# tailscale debug peer-relay-sessions
Server port: not configured (you can configure the port with 'tailscale set --relay-server-port=<PORT>')
Sessions count: 0

Note also that tailscaled logs nothing by default on OPNsense: the rc script defaults tailscaled_syslog_output_enable="NO", so the daemon runs under daemon -f with its output discarded. Even with it enabled, the default tailscaled_syslog_output_priority is info, one level below the level(notice..emerg) cutoff on the f_local_system filter in /usr/local/etc/syslog-ng.conf.d/syslog-ng-local.conf — so the lines are emitted and then dropped. Both must be changed before any of this is diagnosable, which may be worth a separate look.

Additional context

The practical impact in our case: a firewall acting as a Tailscale peer relay had the relay silently disabled from the first restart after boot. It was found dead after three days of uptime, while all surrounding documentation and monitoring still described the node as an active relay. Nothing indicated a setting had been discarded.

The documented workaround for custom flags — hand-writing an additional rc.d script — does not actually solve it, because rc.d scripts run at boot, while the reset happens on every restart. A box that restarts tailscaled on a schedule therefore loses the setting permanently until the next reboot.

I believe this single root cause explains several existing reports, which is the main reason to fix the command rather than add settings one at a time:

• Tailscale 1.3: Subnet route changes not advertised #5114 — advertised subnet route changes not taking effect; the reporter worked around it by running tailscale set --advertise-routes=... by hand. Closed as not planned.
• os-tailscale: tailscale logged out from opnsense after reboot even though key expiry is disabled #4661 — node logged out after reboot despite key expiry being disabled.

In each case a preference set outside the plugin's argument list does not survive.

Suggested fix

Use tailscale up only for the initial login/authentication (its remaining supported purpose), and apply plugin-managed settings on subsequent starts with tailscale set --<flag>=<value>. This needs no new GUI fields and fixes every set-only preference at once.

If a full migration is too large a change, a smaller step that would still help a lot: an "extra options" free-text setting appended to a tailscale set invocation, so operators can express preferences the plugin does not model.

Environment

OPNsense 26.1.11_10 (amd64)
os-tailscale 1.4
tailscale 1.98.5
Intel® Celeron® J3160 @ 1.60GHz (4 cores)
Network: 4x Intel® I210 Gigabit Network Connection