2019-03-17 22:02:37 +07:00
|
|
|
WireGuard support for Synology NAS
|
|
|
|
==================================
|
2019-03-19 03:43:02 +07:00
|
|
|
This package adds WireGuard support for Synology NAS drives. It provides the
|
|
|
|
WireGuard kernel module and the ``wg``/``wg-quick`` commands.
|
2019-03-17 22:02:37 +07:00
|
|
|
|
|
|
|
|
|
|
|
Disclaimer
|
|
|
|
----------
|
2019-03-19 05:30:59 +07:00
|
|
|
You use everything here at your own risk. I am not responsible if this breaks
|
2019-03-20 16:31:56 +07:00
|
|
|
your NAS. Realistically it should not result in data loss, but it could render
|
|
|
|
your NAS unaccessible if something goes wrong.
|
|
|
|
|
|
|
|
If you are not comfortable with removing your drives from the NAS and manually
|
|
|
|
recover the data, this might not be for you.
|
2019-03-17 22:02:37 +07:00
|
|
|
|
|
|
|
|
2019-07-16 20:23:40 +07:00
|
|
|
FAQ/Known issues
|
|
|
|
----------------
|
2019-04-18 01:45:17 +07:00
|
|
|
* The ``Dns = x.x.x.x`` setting is unsupported. If you try it you will get the
|
|
|
|
following message:
|
|
|
|
``/usr/local/bin/wg-quick: line 31: resolvconf: command not found``
|
|
|
|
* IPv6 is probably not supported (at least not using ``wg-quick``). Due to the
|
|
|
|
system version of ``iproute2``
|
|
|
|
`being too old <https://lists.zx2c4.com/pipermail/wireguard/2018-April/002687.html>`_.
|
|
|
|
You'll get the error message
|
|
|
|
``Error: argument "suppress_prefixlength" is wrong: Failed to parse rule type``.
|
2019-12-28 21:41:57 +07:00
|
|
|
* Everything appears to be OK when running ``wg show`` but no traffic is flowing
|
|
|
|
through the tunnel. Apparently there is some kind of race when setting up the
|
|
|
|
interface. The simplest known workaround is to append
|
|
|
|
``; sleep 5; ip route add 10.0.0.0/16 dev wg0`` to the ``PostUp`` rule. This
|
|
|
|
assumes that your WireGuard IP subnet is ``10.0.x.x``. See
|
|
|
|
`issue #10 <https://github.com/runfalk/synology-wireguard/issues/10>`_ for
|
|
|
|
more information.
|
2019-04-18 01:45:17 +07:00
|
|
|
|
|
|
|
PRs that solve these issues are welcome.
|
|
|
|
|
|
|
|
|
2019-03-17 22:02:37 +07:00
|
|
|
Compatibility list
|
|
|
|
------------------
|
2019-03-22 23:05:47 +07:00
|
|
|
All models marked *Is working* have been confirmed by users to work. If your
|
|
|
|
model has the same platform as one of the working ones, chances are it will
|
|
|
|
work for you too.
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2019-03-22 22:11:03 +07:00
|
|
|
========= ========== =========== ===========================
|
|
|
|
Model Platform DSM Version Is working?
|
|
|
|
--------- ---------- ----------- ---------------------------
|
2019-03-25 21:22:55 +07:00
|
|
|
DS1019+ apollolake 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
DS114 armada370 *N/A* No (Kernel version too old)
|
|
|
|
DS115j armada370 *N/A* No (Kernel version too old)
|
2020-08-15 18:37:46 +07:00
|
|
|
DS116 armada38x 6.2 Yes
|
|
|
|
DS1511+ x64 6.2 Yes
|
2019-08-17 18:54:43 +07:00
|
|
|
DS1618+ denverton 6.2 Yes
|
2019-03-23 00:02:30 +07:00
|
|
|
DS1817+ avoton 6.2 Yes
|
2020-05-01 02:46:20 +07:00
|
|
|
DS1815+ avoton 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
DS213j armada370 *N/A* No (Kernel version too old)
|
|
|
|
DS213j armada370 *N/A* No (Kernel version too old)
|
|
|
|
DS214play armada370 *N/A* No (Kernel version too old)
|
|
|
|
DS214se armada370 *N/A* No (Kernel version too old)
|
2020-08-15 18:37:46 +07:00
|
|
|
DS216+II braswell 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
DS216se armada370 *N/A* No (Kernel version too old)
|
2020-12-20 20:48:51 +07:00
|
|
|
DS216Play monaco 6.2 Yes
|
2020-04-18 19:55:17 +07:00
|
|
|
DS218 rtd1296 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
DS218+ apollolake 6.2 Yes
|
2019-03-22 23:05:47 +07:00
|
|
|
DS218j armada38x 6.2 Yes
|
2020-08-15 19:34:59 +07:00
|
|
|
DS3617xs broadwell 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
DS414slim armada370 *N/A* No (Kernel version too old)
|
2019-04-18 01:03:31 +07:00
|
|
|
DS415+ avoton 6.2 Yes
|
2020-08-15 18:37:46 +07:00
|
|
|
DS418play apollolake 6.2 Yes
|
2019-03-22 23:16:29 +07:00
|
|
|
DS713+ cedarview 6.2 Yes
|
2019-08-22 15:14:10 +07:00
|
|
|
DS716+II braswell 6.2 Yes
|
2019-11-15 21:29:44 +07:00
|
|
|
DS718+ apollolake 6.2 Yes
|
2020-08-15 18:37:46 +07:00
|
|
|
DS916+ braswell 6.2 Yes
|
2019-03-22 23:05:47 +07:00
|
|
|
DS918+ apollolake 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
RS214 armada370 *N/A* No (Kernel version too old)
|
2019-04-18 01:03:31 +07:00
|
|
|
RS816 armada38x 6.2 Yes
|
2019-03-22 22:11:03 +07:00
|
|
|
========= ========== =========== ===========================
|
2019-03-20 16:31:56 +07:00
|
|
|
|
2019-03-22 20:11:09 +07:00
|
|
|
The minimum required kernel version is 3.10. If you have a kernel version lower
|
2019-03-20 16:31:56 +07:00
|
|
|
than that, WireGuard will not work. You can check your kernel version by
|
|
|
|
logging in through SSH and running the ``uname -a`` command.
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2020-09-22 15:24:30 +07:00
|
|
|
This project is also confirmed to be compatible with other brand NAS stations
|
2020-09-22 18:22:36 +07:00
|
|
|
using `XPEnology <https://xpenology.com/forum/topic/9392-general-faq/>`_.
|
2020-09-22 15:24:30 +07:00
|
|
|
|
|
|
|
========= ================ ========== =========== ===========================
|
|
|
|
Model Hardware version Platform DSM Version Is working?
|
|
|
|
--------- ---------------- ---------- ----------- ---------------------------
|
|
|
|
HP54NL DS3615xs bromolow 6.2 Yes
|
|
|
|
========= ================ ========== =========== ===========================
|
|
|
|
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2019-03-19 03:43:02 +07:00
|
|
|
Installation
|
|
|
|
------------
|
|
|
|
Check the `releases <https://github.com/runfalk/synology-wireguard/releases>`_
|
|
|
|
page for SPKs for your platform. If there is no SPK you have to compile it
|
|
|
|
yourself using the instructions below.
|
|
|
|
|
|
|
|
1. In the Synology DSM web admin UI, open the Package Center and press the
|
|
|
|
*Settings* button.
|
|
|
|
2. Set the trust level to *Any publisher* and press *OK* to confirm.
|
|
|
|
3. Press the *Manual install* button and provide the SPK file. Follow the
|
|
|
|
instructions until done.
|
|
|
|
|
|
|
|
Now you just need to figure out how to configure WireGuard. There are lots of
|
|
|
|
good guides on how to do that.
|
|
|
|
|
2019-03-19 05:35:14 +07:00
|
|
|
To put my WireGuard configuration on the NAS, I used SSH and created a
|
|
|
|
``wg-quick`` configuration in ``/etc/wireguard/wg0.conf``. Then I opened the
|
|
|
|
*Control panel*, opened the *Task scheduler* and created *Triggered task* that
|
|
|
|
runs ``wg-quick up wg0`` on startup.
|
2019-03-19 03:43:02 +07:00
|
|
|
|
2019-03-23 20:32:34 +07:00
|
|
|
When running ``iptables`` in the ``PostUp`` and ``PostDown`` rules I needed to
|
|
|
|
toggle the interface to make it work. My full startup task looks like this:
|
|
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
|
|
|
sleep 60
|
|
|
|
wg-quick up wg0
|
|
|
|
sleep 5
|
|
|
|
wg-quick down wg0
|
|
|
|
sleep 5
|
|
|
|
wg-quick up wg0
|
|
|
|
|
|
|
|
My ``/etc/wireguard/wg0.conf`` looks like this:
|
|
|
|
|
|
|
|
.. code-block::
|
|
|
|
|
|
|
|
[Interface]
|
|
|
|
Address = 10.0.1.1/16
|
|
|
|
PrivateKey = <nas-private-key>
|
|
|
|
ListenPort = 16666
|
|
|
|
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
|
|
|
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
|
|
|
|
|
|
|
|
[Peer]
|
|
|
|
PublicKey = <peer-public-key>
|
|
|
|
AllowedIPs = 10.0.1.2/32
|
|
|
|
|
2019-03-23 20:34:02 +07:00
|
|
|
Note that you need to modify the rules if your network interface is not
|
|
|
|
``eth0``. You can check which name your interface has by running ``ip a`` in an
|
|
|
|
SSH session.
|
2019-03-23 20:32:34 +07:00
|
|
|
|
2019-03-19 03:43:02 +07:00
|
|
|
|
2019-03-17 22:02:37 +07:00
|
|
|
Compiling
|
|
|
|
---------
|
2019-03-22 20:11:09 +07:00
|
|
|
I've used docker to compile everything, as ``pkgscripts-ng`` clutters the file
|
|
|
|
system quite a bit. First create a docker image by running the following
|
|
|
|
command in this repository:
|
2019-03-17 22:02:37 +07:00
|
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
2019-03-22 21:39:09 +07:00
|
|
|
git clone https://github.com/runfalk/synology-wireguard.git
|
|
|
|
cd synology-wireguard/
|
2019-03-22 20:11:09 +07:00
|
|
|
sudo docker build -t synobuild .
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2019-03-22 20:11:09 +07:00
|
|
|
Now we can build for any platform and DSM version using:
|
2019-03-17 22:02:37 +07:00
|
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
2019-12-29 04:37:29 +07:00
|
|
|
sudo docker run --rm --privileged --env PACKAGE_ARCH=<arch> --env DSM_VER=<dsm-ver> -v $(pwd)/artifacts:/result_spk synobuild
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2019-03-22 20:11:09 +07:00
|
|
|
You should replace ``<arch>`` with your NAS's package arch. Using
|
|
|
|
`this table <https://www.synology.com/en-global/knowledgebase/DSM/tutorial/General/What_kind_of_CPU_does_my_NAS_have>`_
|
|
|
|
you can figure out which one to use. Note that the package arch must be
|
|
|
|
lowercase. ``<dsm-ver>`` should be replaced with the version of DSM you are
|
|
|
|
compiling for.
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2019-03-22 20:11:09 +07:00
|
|
|
For the DS218j that I have, the complete command looks like this:
|
2019-03-17 22:02:37 +07:00
|
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
2019-12-29 04:37:29 +07:00
|
|
|
sudo docker run --rm --privileged --env PACKAGE_ARCH=armada38x --env DSM_VER=6.2 -v $(pwd)/artifacts:/result_spk synobuild
|
2019-03-17 22:48:12 +07:00
|
|
|
|
2019-03-22 20:11:09 +07:00
|
|
|
If everything worked you should have a directory called ``artifacts`` that
|
|
|
|
contains your SPK files.
|
2019-03-17 22:48:12 +07:00
|
|
|
|
2019-03-17 22:02:37 +07:00
|
|
|
|
2020-07-05 03:20:26 +07:00
|
|
|
Avoiding timeouts when downloading build files
|
|
|
|
----------------------------------------------
|
|
|
|
It can take a long time to pull development files from SourceForge, including
|
|
|
|
occasional timeouts. To get around this, create a folder locally and map it to
|
|
|
|
the `/toolkit_tarballs` Docker volume using the following command:
|
|
|
|
`-v $(pwd)/<path/to/folder>:/toolkit_tarballs`
|
|
|
|
to the `docker run` command listed above. This will allow the development files
|
|
|
|
to be stored on your host machine instead of ephemerally in the container. The
|
|
|
|
image will check for existing development files in that folder and will use
|
|
|
|
them instead of pulling them from SourceForge when possible. You can also
|
|
|
|
download the files directly and put them in the folder you created by downloading
|
|
|
|
them from here: https://sourceforge.net/projects/dsgpl/files/toolkit/DSM<DSM_VER>
|
|
|
|
(e.g. https://sourceforge.net/projects/dsgpl/files/toolkit/DSM6.2)
|
|
|
|
|
|
|
|
|
2019-03-17 22:02:37 +07:00
|
|
|
Credits
|
|
|
|
-------
|
|
|
|
I based a lot of this work on
|
|
|
|
`this guide <https://www.reddit.com/r/synology/comments/a2erre/guide_intermediate_how_to_install_wireguard_vpn/>`_
|
|
|
|
by Reddit user `akhener <https://www.reddit.com/user/akhener>`_. However, I had
|
2019-03-22 20:11:09 +07:00
|
|
|
to modify their instructions a lot since my NAS has an ARM CPU which made cross
|
2019-03-17 22:02:37 +07:00
|
|
|
compilation a lot trickier.
|
2019-03-23 19:19:13 +07:00
|
|
|
|
|
|
|
GitHub user `galaxysd <https://github.com/galaxysd>`_ made
|
|
|
|
`a guide <https://galaxysd.github.io/linux/20170804/2017-08-04-iptables-on-Synology-DSM-6>`_
|
|
|
|
on how to enable iptables NAT support.
|