tailscale: Synology: tracking bug for use cases

Can you please make a small addition to the docs to talk about how to advertise routes + any extra things? Right now, it just says “command line steps required”, but doesn’t actually tell you what those steps are.

For my setup, I needed to ssh into my synology and run this:

tailscale up --advertise-routes=192.168.1.0/24 --advertise-exit-node --reset

I ran this manually. Does it need to be run periodically (e.g. if synology updates the package, will my routes continue to be advertised?)? And/or would be better to drop those options into a config file or something so that subsequent restarts of tailscaled or the entire NAS will continue to do what I want it to do?

You mention two use-cases. I have a third that I think should be supported.

• I have two Synology NAS’s in two networks, connecting them for file transfer.

This has a lot of important use-cases. Specifically, offsite backup being one important one.

I don’t have ssh configured on my Synology, is there any plan to have the Tailscale package automatically run tailscale cert (as seen in this post: https://tailscale.com/blog/tls-certs/) so that I can use HTTPS to access my Synology? I’d prefer not to enable SSH access if it’s not needed.

I’d love to push for one more use case to be considered important.

• Allowing snapshot replication between two Synology devices on isolated networks.

I currently use this for remote replication of data as well as offsite backups, and I can’t be the only one.

We submitted Tailscale 1.22 for the Package Center review process, but have relatively little control over when it might appear.

New synology kb article: https://tailscale.com/kb/1131/synology/

Hi all. Any ideas when the option --accept-routes will be available?

I won’t create the issue now since this is a new feature that came out this week, but can we use Tailscale SSH on Synology devices as well?

Not yet. It requires some Synology-specific work that we haven’t done yet.

First of all, thank you for a such useful add-on!

I use subnet routing on my Synology. Initially, I was using CLI commands to enable routing but now I trigger Tailscale setup from Synology Task Scheduler. It will most likely survive any system or plugin update (and, of course, a reboot).

It’s a No-CLI version. I created a new task that runs on boot under root account. E.g:

/bin/timeout -k 1 300 /bin/bash -c 'until /bin/pidof tailscaled; do /bin/sleep 2; done; /sbin/sysctl -w net.ipv4.ip_forward=1 && /volume1/@appstore/Tailscale/bin/tailscale up --advertise-routes=192.168.5.0/24 --reset'

The “script” waits for tailscaled deamon at boot. As you see in the example, timeout is 300 seconds to prevent unexpected interruptions of boot process. I tested it on DSM7.

Update: we’ve published https://tailscale.com/kb/1152/synology-outbound/ for instructions with how to do outbound connections from Synology (with DSM7).

@sim-san you have to do it from the command line. Use ssh to access your NAS, then run similar command to the one I used but with the subnets you like:

/volume1/@appstore/Tailscale/bin/tailscale up --advertise-routes=172.16.10.0/24,172.16.20.0/24 --reset

I think I did this as root (ran sudo -i before the command shown above)

I apologize if this is a foolish question (and it will be) but my current understanding is that I can’t run Mullvad as an exit node on Synology Tailscail since I’m unable to run sudo tailscale up --exit-node=<exit-node-name-or-ip>, correct? I’m an amateur at home networking and I’m trying to figure out a way to get PiHole in Docker + Tailscale and an encrypted DNS to play nicely!

Tailscale on Synology on DSM7 is sandboxed and unable to configure the machine’s DNS.

The new KB article linked by @apenwarr is great! Thanks to whoever wrote and posted it.

It mentions that exit nodes can only be configured at the command line, but I don’t see instructions for how to do that. Is it just the generic exit node instructions plus turn on IP forwarding (e.g. echo 1 > /proc/sys/net/ipv4/ip_forward?

If I may, I think an obvious use-case is the one you might use a traditional VPN for: remote access to mapped network drives, for example from a laptop away from home/work.

Tailscale works very well for this on my Synology DS218+ (DSM 7.2), with MagicDNS making the mapping even easier from Windows laptops, however I did have to add a subnet route to the Diskstation for it to work.

I don’t need/want access to my whole network, so I added the IP of the Diskstation with /32.

The large majority of Synology devices are on DSM 7, with a healthy number on DSM 7.2 and the rest on earlier DSM7 versions.

If you updated from DSM6 directly to DSM7.2, you’ll need to uninstall and reinstall Tailscale from the Package Center. It makes several decisions at install time based on whether it is running within DSM6.

When you configure the connection, use the tailscale IP address of the remote machine, AND in the “Advanced Settings” area set the source address as the tailscale IP address of the local machine.

On Wed, Dec 7, 2022 at 1:09 PM Igor Dobrosavljević @.***> wrote:

That was my initial thought but after going into the Security section of the Control Panel I was able to confirm that neither Synology unit has the firewall turned on.

— Reply to this email directly, view it on GitHub https://github.com/tailscale/tailscale/issues/1995#issuecomment-1341457905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDGGKV3DY6VZ7BKUK5XULWMDOG3ANCNFSM45USYXKA . You are receiving this because you commented.Message ID: @.***>

– Don

That said, they let users run things as root.

And we use that for the configure-host stuff (see https://tailscale.com/kb/1131/synology/) where you add a “user-defined script” to run /var/packages/Tailscale/target/bin/tailscale configure-host and we change permissions and stuff as root.

So we could do some more things as root.

DSM7 does not allow packages to run as root — which, looking at it from their perspective, is a reasonable choice to make for their platform.

It seems tun networking on DSM7.x was disabled 13 months ago but I wasn’t able to get outbound connections working without reverting that change using the 1.26.1 package. The issue doesn’t say why tun networking was disabled, am I going to run into some problem?

Additionally the instructions for enabling outbound connections don’t match what tailscale configure-host does. Specifically, the /dev/net directory must have 0755 permissions for the start-stop-script to enable tun networking, without this test -e returns false.

I imagine the instructions will be replaced with “create the scheduled task that runs tailscale configure-host” sometime after Synology is hosting a compatible package in their Package Center. (An update has been alluded to either in this issue or in one linked, I can’t find it again.)

@strausmann, I moved that to https://github.com/tailscale/tailscale/issues/4759

Update: we’ve published https://tailscale.com/kb/1152/synology-outbound/ for instructions with how to do outbound connections from Synology (with DSM7).

Hi, I followed the instructions for outbound connections and they work but they are not persistent through a synology reboot. When the synology starts back up, outbound connections are broke. Any idea what I could change?

# Add CAP_NET_ADMIN to the binary; required if manually installing the
# Tailscale *.spk file.
# This step is required every time you upgrade Tailscale.
sudo setcap cap_net_admin+eip /var/packages/Tailscale/target/bin/tailscaled
   
# These three commands are only needed once and persist over restarts.
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 0666 /dev/net/tun

Sorry to bother you, but I don’t understand: can I or cannot use my Synology NAS with DSM6 as Exit Node? Or only on the DSM7? Screenshot 2021-10-21 at 12 18 24

Tailscale 1.16 for Synology adds an exit node enable checkbox in the web UI. It will appear in the Package Center in a future monthly update.

Sorry comment got sent too early. Updated it.

We could probably support this using a userspace relay (#707).