Title: Native Synology package not binding to OS-level Tailscale interface (subnet routing)
Setup:
- Channels DVR Server (native Synology package, not Docker) on a Synology DS418
- DS418 also runs Tailscale as a separate OS-level Synology package, functioning as a subnet router advertising my home LAN (172.16.70.0/24) for weeks without issues
- Remote sites (two locations) connect via their own local Tailscale subnet routers, routing into my home network over Tailscale — this setup already works for every other local service
Problem:
Devices without a Tailscale client (Fire TV Stick and Sony TV's specifically) at remote sites cannot reach Channels DVR Server on port 8089, even though:
- Ping to the DS418's LAN IP succeeds perfectly from the remote site (0% loss)
- The remote site's firewall rules and static routes are confirmed correct via packet capture (tcpdump shows the SYN packet successfully leaving the remote subnet router into the Tailscale tunnel)
- Devices that ARE running Tailscale directly (phone, laptop) connect to Channels perfectly fine from the same remote locations
Diagnosis:
Settings → General on the Channels admin page shows: "Advertising [hostname].local via 1 network: [LAN IP, link-local IP]" — it never lists the Tailscale interface, even after a full Synology reboot. Enabling HTTP Logging and retrying confirms zero incoming requests ever reach Channels from the remote subnet — the connection attempt never reaches the application layer at all.
Already ruled out:
- Firewall rules (added explicit allow rules, still fails)
- Sophos ACLs and Tailscale ACLs (tested maximally permissive rules, still fails)
- DSM's own firewall (confirmed disabled)
- Full reboot of the Synology (no change to the "1 network" detection)
- Channels' own embedded Tailscale toggle (unrelated — it's a separate identity from the OS-level Tailscale, toggling it on/off makes no difference)
This looks like it may be the same "wrong Tailscale device" detection issue mentioned by a developer in the 2022 experimental Tailscale integration thread. Is this a known limitation of the native Synology package specifically, and is Docker required to properly bind to all host network interfaces? Any workaround for the native package would be appreciated.