Thanks for all your work here on making Tailscale work for Synology! Is it expected behavior that v1.12.1 with sudo tailscale up --advertise-routes=10.2.1.0/24 --reset would make the subnet routing option appear in the admin panel but not actually function if you try to reach those IPs over Tailscale?

The things we don't support on Synology are:

• tailscale up --accept-routes, as we don't mess with the routing table or use iptables.
• using an exit node (for the same reason)
• any tailscale up --netfilter-mode=XXX value other than off.

With --netfilter-mode=off you would need to program iptables yourself in order for the routing to work.

Thanks @maisem. I think my confusion was from --advertise-routes vs --accept-routes. Sounds like they do the same thing and neither is supported on Synology (at least DSM7) yet.

Sorry comment got sent too early. Updated it.

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

advertise-routes should work fine on DSM7 (for TCP and UDP, but not ICMP). It's accept-routes that doesn't work on DSM7.

@bradfitz Confirmed it's not working for TCP/UDP on my end with DSM7 and v1.12.1. Happy to share any debug information that's helpful!

I just upgraded to DSM7 and I am successfully able to use the nas as an exit node and a subnet router.
@michaelyork can you share the params that tailscaled is running with: ps aux | grep tailscaled

@maisem Of course, see below.

michaelyork@<redacted>:/$ ps aux | grep tailscaled
tailsca+ 10124  0.7  0.1 717908 21604 ?        Sl   Aug03  23:14 /volume1/@appstore/Tailscale/bin/tailscaled --state=/volume1/@appdata/Tailscale/tailscaled.state --socket=/volume1/@appdata/Tailscale/tailscaled.sock --port=41641 --tun=userspace-networking
michael+ 22995  0.0  0.0  23220  1228 pts/0    S+   18:35   0:00 grep --color=auto tailscaled

Hi, I have installed Tailscale (1.9.156) on my DS720+ running DSM 7.0-41890 and my nas shows up in my machines list but as I was trying to add subnet routing I get an error when trying to run the following:

sudo tailscale up --advertise-routes=172.16.10.0/24,172.16.20.0/24 --reset
-ash: tailscale: command not found

any ideas about what I'm doing wrong?

ps aux | grep tailscaled
tailsca+  2418  0.7  0.2 717000 20728 ?        Sl   21:22   0:15 /volume1/@appstore/Tailscale/bin/tailscaled --state=/volume1/@appdata/Tailscale/tailscaled.state --socket=/volume1/@appdata/Tailscale/tailscaled.sock --port=41641
root     28872  0.0  0.0  23236  2232 pts/0    S+   21:57   0:00 grep --color=auto tailscaled

Installed from the Package Center, the tailscale binaries should be in /volume1/@appstore/Tailscale/* which isn't included in $PATH.

@DentonGentry thanks, I just found it and fixed my issue :-)

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

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?

Where can I find the steps to enable subnet on Synology 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)

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.

For my Syno (DS218+) it is said in the Tailscale machine web monitoring "This machine is running an old version of Tailscale (1.9.156-tf944614c5-g2eb5d087c) and should be updated". Updates should come from the Synology packet center? or is there another way to update (if update available).

We're working on fixing that: the Synology package currently in the package center is being lumped in with Linux systems, for where there is a later version available and the admin panel is flagging it as hving an update.

1.9.156 is the version currently available in the package center. The next release in the package center should be out soon and will be a 1.12 release which, importantly, should also let us distinguish it in the admin panel.

For now, please ignore the update indication.

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

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).

The link provided mentions version 1.12.4 from github but newest version on github is 1.12.1

To paraphrase #1995 (comment), TS DNS not working is WAI.

However seems that the configure-synology script could fix this?

Aside: Synology DSM 7 does not deal well with an AWOL DNS server: if you manually configure the NAS DNS to 100.100.100.100, and TS isn't operating, you won't be able to log in via the web UI ! (fortunately ssh still works)

Aside: would be good for tailscaled to revert to using a public DNS, say 1.1.1.1, when it's not connected - means anyone who configured quad-100 in /etc/resolv.conf will at least have something when TS is down.

Aside: Synology DSM 7 does not deal well with an AWOL DNS server: if you manually configure the NAS DNS to 100.100.100.100, and TS isn't operating, you won't be able to log in via the web UI ! (fortunately ssh still works)

If you have Mail Server running, tailscale running and the DNS set to 100.100.100.100 as primary and a public one as secondary, you will get CPU usage of tailscale through the roof. Only fix I have found is to install DNS server, make it recursive and make a forward only zone of ts.net to the 100.100.100.100 server and the rest to resolve recursively.

Is anyone running Tailscale on DSM 7.2 ? I (foolishly in hindsight) updated both my devices to 7.2 and outgoing connectivity to other TS hosts is broken.

Running through the https://github.com/tailscale/tailscale/blob/main/cmd/tailscale/cli/configure-synology.go 'script' manually, no errors pop up; the tun device is present and the tailscaled binary has the intended capabilities. However, the tun interface does not show up in ip link:

$ synoversionget --full-version
7.2-64570 Update 1
$ tailscale version
1.44.0
  tailscale commit: 5d008cd8350247adebabd966933e23fe334e9d74
  other commit: 6dac82fa03e9212fb13ce7252dac41745629356a
  go version: go1.20.5-ts40dc4d8

$ sudo /var/packages/Tailscale/target/bin/tailscale configure-host
Done. To restart Tailscale to use the new permissions, run:

  sudo synosystemctl restart pkgctl-Tailscale.service

$ sudo synosystemctl restart pkgctl-Tailscale.service
[pkgctl-Tailscale.service] restarted.
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:32:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1
    link/sit 0.0.0.0 brd 0.0.0.0
8: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none 

However if I configure a static route pointing to the local tailscale0 address, it works and I can reach the destination network (192.168.99.0/24 being available via my tailnet):

$ sudo ip ro add 192.168.99.0/24 via 100.xx.xx.xx
$ sudo ping 192.168.99.10
PING 192.168.99.10 (192.168.99.10) 56(84) bytes of data.
64 bytes from 192.168.99.10: icmp_seq=1 ttl=63 time=69.6 ms
64 bytes from 192.168.99.10: icmp_seq=2 ttl=63 time=58.6 ms

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.

... [updated] both my devices to 7.2 and outgoing connectivity to other TS hosts is broken.

...

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.

Closing this out; I suspect I was confused earlier in that I had the mistaken idea that the Synology setup supported accepting routes, it doesn't (known limitation: https://tailscale.com/kb/1131/synology/#limitations--known-issues).

TS 1.38.4 and 1.44.0 works fine on DSM 7.2 for me.

So, I've come back around after resolving an issue that I'd run into where my Tailscale app got into a broken state with my session but uninstalling/reinstalling would not fix the issue.

In such case, I ended up dropping into a root shell over SSH to my Synology NAS and deleting the contents of the following directory:

/volume1/@appdata/Tailscale

If you want to be more targeted (e.g. retaining your log files) you can likely drop just the .state file in that directory. I had found a number of files and most were logs, with just one tailscaled.state file.

# you will need root privileges to delete this file

rm "/volume1/@appdata/Tailscale/tailscaled.state"

After wiping this out, I was able to successfully log back in through my IdP and setup my Synology NAS as a node again.

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

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.

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!

@bradfitz could we add a bullet point for tailscale ssh on synology? I know it's far out as DSM imposes a sandbox but would be nice to have in the future.

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!

I don't get what you are trying to reach, maybe you need to create a TUN device?

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!

I am trying to do the same thing and running the above command on my NAS gave me an error and sent me to this page.

My use call is that my usenet provider appears to be throttling the downloads on my Synology NAS based on my IP Geolocation (I am currently on a 12 month assignment overseas). I'm following up with the provider separately on that but the support is hopeless.

If I download from my Mac and use my remote exit node in Australia, I get no throttling. This is my current workaround.

But I want the downloads farmed off to my NAS which I leave on 24/7.

Any workaround to get the Synology to route via my remote exit node?

Going through the steps for enabling outbound connections https://tailscale.com/kb/1131/synology/#enabling-synology-outbound-connections will create a /dev/net/tun device, which makes the Synology DSM7 device operate in the same mode as a Debian system and might do better for what you're trying to do.

Hello,

I've just tested the steps in the article you mention, but it doesn't solve the issue. Communications from Tailscale clients to my internal network are still NAT'ed to the Synology IP address, event with the --snat-subnet-routes=false option.

@mwi001 Did you solve this somehow?

Does disabling SNAT not work on Synology?

Is running Tailscale in a docker container with --net=host and other caps an alternative to the official Synology package? Will that fix this issue?

I managed to get it working by using a Task Scheduler script on Synology. The issue is that Synology doesn't support --accept-routes natively, as mentioned in this thread, but I was able to set up Tailscale with the following workaround:

In the Task Scheduler, as root on boot, I used this script:

/var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes

/var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes

I found this same solution posted on reddit but I get this:

zsh: command not found: synosystemctl

I am wondering that you have zsh on your DSM, it is not installed on my synology. Did you by any chance did not run the command on the synology but locally?

The other option is that zsh did not have the binary in the PATH variable, on my system the binary is located in /usr/syno/bin/synosystemctl

just curious about the updates on this.

It seems for me since the last update of the synology, i`m unable to route traffic towards subnets behind another node.
i have a remote client 100.123.x.x that provides a subnet 192.168.10.0/24.

we cant use --accept-routes, but i was able to provide a ip route add 192.168.10.0/24 via 100.123.x.x before.
that worked so far.

but now i have 7.2.2-72806 Update 1 installed, this does not seem to work anymore.
i`m running in TUN mode, but whatever i seem to try, i cant get traffic to that remote subnet anymore.

Any other having this as well?

I could swear it worked before and now it doesn't

just curious about the updates on this.

It seems for me since the last update of the synology, i`m unable to route traffic towards subnets behind another node. i have a remote client 100.123.x.x that provides a subnet 192.168.10.0/24.

we cant use --accept-routes, but i was able to provide a ip route add 192.168.10.0/24 via 100.123.x.x before. that worked so far.

but now i have 7.2.2-72806 Update 1 installed, this does not seem to work anymore. i`m running in TUN mode, but whatever i seem to try, i cant get traffic to that remote subnet anymore.

Any other having this as well?

I could swear it worked before and now it doesn't

just curious about the updates on this.
It seems for me since the last update of the synology, im unable to route traffic towards subnets behind another node. i have a remote client 100.123.x.x that provides a subnet 192.168.10.0/24. we cant use --accept-routes, but i was able to provide a ip route add 192.168.10.0/24 via 100.123.x.x before. that worked so far. but now i have 7.2.2-72806 Update 1 installed, this does not seem to work anymore. im running in TUN mode, but whatever i seem to try, i cant get traffic to that remote subnet anymore.
Any other having this as well?

I had the same issue after updating to DSM 7.2.2-72806 Update 1, and I solved it by setting up three separate scheduled tasks in the Control Panel's Task Scheduler to run on boot. Here's the exact process I used:

1. Open the Control Panel and go to Task Scheduler.

2. Create three separate tasks with the following commands, ensuring they run in this exact order at boot:

   Task 1:
   /var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes --accept-dns=true

   Task 2:
   sudo synosystemctl restart pkgctl-Tailscale.service

   Task 3:
   /var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes --accept-dns=true

3. Make sure all tasks are set to run at boot and configured in the correct order.

This is the workaround that worked for me, but there may be other ways to make it work. Let me know if this helps or if you find an alternative solution!

I could swear it worked before and now it doesn't

just curious about the updates on this.
It seems for me since the last update of the synology, im unable to route traffic towards subnets behind another node. i have a remote client 100.123.x.x that provides a subnet 192.168.10.0/24. we cant use --accept-routes, but i was able to provide a ip route add 192.168.10.0/24 via 100.123.x.x before. that worked so far. but now i have 7.2.2-72806 Update 1 installed, this does not seem to work anymore. im running in TUN mode, but whatever i seem to try, i cant get traffic to that remote subnet anymore.
Any other having this as well?

I had the same issue after updating to DSM 7.2.2-72806 Update 1, and I solved it by setting up three separate scheduled tasks in the Control Panel's Task Scheduler to run on boot. Here's the exact process I used:

1. Open the Control Panel and go to Task Scheduler.
2. Create three separate tasks with the following commands, ensuring they run in this exact order at boot:
   Task 1:
   /var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes --accept-dns=true
   Task 2:
   sudo synosystemctl restart pkgctl-Tailscale.service
   Task 3:
   /var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service; /var/packages/Tailscale/target/bin/tailscale up --reset --accept-routes --accept-dns=true
3. Make sure all tasks are set to run at boot and configured in the correct order.

This is the workaround that worked for me, but there may be other ways to make it work. Let me know if this helps or if you find an alternative solution!

Thanks, I will try this out. Before you responded, I managed to get into my old synology setup (the working one) and confirmed that everything is stil working fine. I noticed the difference in versions, working one is 1.76.1, non-working is 1.78.

After checking the debug prefs outputs on both, these are the only two different things:
"RouteAll": true, (on broken machine is false)
"NetfilterMode": 2, (on broken machine is 0)

What does it look like on your machine with the workaround you found?

Tip for Enable Outbound Connections

To enable outbound connections with TUN device after an automatic update, do NOT use the plain command tailscale update --yes as recommended. Instead, use this command:

output=$(tailscale update --yes)
echo "$output"
if echo "$output" | grep -q "Updating"; then
/var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service;
fi

That command will

1. Run tailscale update --yes and wait for completion, capturing the output text into variable output
2. Print the output so it still appears in emails and in Task Scheduler → Action → View Result
3. Check output for text "Updating"
4. If "Updating" not found, then do nothing.
5. If "Updating" found, then additionally run /var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service

!!!
Note you do still need the separate task for enabling outbound connections upon boot.
!!!

Context

When Tailscale automatically updated, it broke my backup (Hyper Backup) until I rebooted my NAS. Spent a few hours this morning figuring out the issue, devising the solution above, and testing it to my satisfaction.

Recommended scheduled task for update:
https://tailscale.com/kb/1131/synology#schedule-automatic-updates
tailscale update --yes

Recommended triggered task for enabling outbound connections
https://tailscale.com/kb/1131/synology#enable-outbound-connections
/var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service

Output I saw from tailscale update --yes when an update was available:

Updating Tailscale from 1.58.2 to 1.78.1; --yes given, continuing without prompts.
Downloading "https://pkgs.tailscale.com/stable/tailscale-x86_64-1.78.1-700078001-dsm7.spk"
Download size: 30032384
Downloaded 512/30032384 (0.0%)
Downloaded 30032384/30032384 (100.0%)
Downloading "https://pkgs.tailscale.com/stable/tailscale-x86_64-1.78.1-700078001-dsm7.spk.sig"
Signature OK

Output I saw from tailscale update --yes when an update was not available:

already running stable version 1.78.1; no update needed

FYI, I just learned that for DSM7, the HTTPS certificates can be auto-renewed with a scheduled task with the undocumented command tailscale configure synology-cert.

See the clear tutorial from Simmo Saan (Sim642). See more details in Tailscale KB: Enabling HTTPS, Github issue #4674 and pull #10994, and on and on Reddit.