Use all-inkl.com DDNS with Synology DiskStation

I’ve recently upgraded my all-inkl.com webspace to the PrivatPlus tariff. As part of this tariff I’m now able to use DDNS running under the Domains I’m able to manage.

Setting up DDNS in KAS is explained quite well. However, I did not see instructions on how to use these credentials on a Synology DiskStation OS. Luckily, somebody else did this already.

The important part was, that when you’ll need to customize a DDNS provider first before it can be setup in DiskStation settings.

  • Go to Control Panel, External Access and click on Customize
  • Add a new name for the DDNS provider, e.g. All-Inkl.com
  • Use this Query URL (for IPv4): dyndns.kasserver.com/?myip=__MYIP__
  • Now you can add a new DDNS entry
  • Select All-Inkl.com as provider
  • Enter the credentials as required
  • Enter the hostname you want to setup for DDNS
  • Click on “Test Connection”
  • The state should be “Normal”
  • Click on “OK”

Configure Mosquitto mqtt broker user authentication in Docker running on Synology NAS

Today I’ve tried to enable user authentication for my Mosquitto mqtt broker running in a Docker container on my Synology NAS.

Here’s my shared folder for use with docker, its under /volume1/docker:

mqtt
├── data
├── log
│   └── mosquitto.log
├── mosquitto.conf
└── mosquitto.passwd

The mqtt folder needs to be accessible by the docker process running in the container, e.g. by using:

sudo chown -R 1883:1883 mqtt/

The content of my used docker-compose.yml:

version: '3'
services:
  mosquitto:
    hostname: mosquitto
    image: eclipse-mosquitto:latest
    restart: always
    volumes:
      - /volume1/docker/mqtt/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro
      - /volume1/docker/mqtt/mosquitto.passwd:/mosquitto/config/mosquitto.passwd
      - /volume1/docker/mqtt/log/mosquitto.log:/mosquitto/log/mosquitto.log
      - /volume1/docker/mqtt/data:/mosquitto/data
    ports:
      - "1883:1883"

The mapped files in the volume section need to be present, otherise docker will complain during startup of the container.

Make also sure that you’re writing mosquitto with double t. I’ve forgotten this and used only one t, wondering why nothing was working the way I’ve expected it.

Here’s the content of my mosquitto.conf:

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /mosquitto/data/

log_dest file /mosquitto/log/mosquitto.log
log_dest stdout

password_file /mosquitto/config/mosquitto.passwd
allow_anonymous false

You can setup the mosquitto.passwd using the docker container and/or an installation of mosquitto, so that you can use the mosquitto_passwd tool.

mosquitto_passwd -c /mosquitto/config/mosquitto.passwd <username>

It will ask you twice for the password for the username. If you want to setup additional users, you should omit the -c parameter, so that the existing file won’t be overwritten.

The “allow_anonymous false” line will disable anonymous authentication to the broker.

You can now SSH to your Synology and start the docker container using the docker-compose file:

docker-compose -f docker-compose.yml up -d

This will look for the docker-compose.yml in the current folder and will execute docker in daemon mode. It will restart automatically when your Synology is restarting (e.g. after system updates).

Improve OpenVPN security on Synology DiskStations

I’m using OpenVPN on my Synology DiskStation with certificates instead of Preshared Keys. A few days ago I’ve wanted to login to my VPN and it wasn’t working. After checking the log file I’ve seen that there were some issues with the used configuration file for OpenVPN.

Tue Nov 20 23:04:27 2018 Cipher algorithm 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CB' not found
Tue Nov 20 23:04:27 2018 Exiting due to fatal error

How can this be? The configuration worked for months without problems? I’ve started to remember that I’ve started to increase the security of my OpenVPN configuration using a few parameters. The Cipher algorithm is one of them. This page describes some of the changes I’ve made (unfortunately only in German).

I’ve added the tls-cipher and tls-auth options as last parameter lines to my configuration file. The synology web UI tried to parse those parameters as cipher and auth parameter when it shows those values as part of the DSM UI.

I’ve reorderded the tls-auth and tls-cipher parameter to be above the auth and cipher parameters and the DSM UI is now able to show those values correct. This will enable you to restart the OpenVPN service from the WebUI without the need to login via SSH.

How do you get supported values for auth, cipher and tls-cipher you might wonder? Just execute

openvpn --show-tls

to get the supported tls-cipher you might line up with a : separated.

openvpn --show-digests

shows you the allowed values for auth and

openvpn --show-ciphers

will show the allowed values for cipher. However, cipher and auth can also be preselected from the DSM UI.

Don’t forget to use the same values in your OpenVPN configuration on your VPN client as well, otherwise the connection won’t work.

Automount network shares on Mac OS for use in iTunes

I’ve moved my iTunes library from my Macbook’s SSD to my Synology NAS on a network share. This is quite easy and can be made inside the iTunes preferences pane. After you’ve changed the path for the iTunes Media, all iTunes managed media will be moved to the new location (assuming you let iTunes manage your files of course :)).

This allows you to have your iTunes library on your Macbook while all the large files are stored on the NAS. This is especially important for larger libraries as well as the newer Macbooks which only have a limited flash drive instead of larger harddisks.

However, there is one important problem with this solution: Once you’ve disconnected from this network share for whatever reasons and you try to start iTunes, you’ll have your iTunes Media folder reset to your user’s music folder on your boot disk. You’ll now need to reset the path to your files again, and this will again cause iTunes to check all files if they are on the right location and moves them if necessary.

I thought I’ve taken care of this problem with auto connecting to the network share with a Login Item. However, this didn’t help me much since I sometimes have disconnections to my network (e.g. when I’m on the road) and the network connection will only be created once during the login of your current user. So this doesn’t help me at all and caused me to look for another better solution.

So I’ve found this gist (the link is dead) and modified it a little bit to my environment. Therefore here’s my short list of modifications for using autofs in combination with AFP or SMB volumes:

If you now start up iTunes again, it will try to locate the media files in the /Volumes/music folder, like I manually specified it. However, autofs will now automatically mount the network share for me and iTunes won’t complain about a missing volume. This way I won’t ever need to take care of manually updating the path once I forgot connecting to my NAS 🙂

Update:
Hm, it seems that the trick with /../Volumes does not work anymore on Mac OS 10.11.4 🙁 If I try to list the content of the mounted volume an error message is returned:

ls: : Unknown error: 118

So I need to mount the volume in a different folder and need to change the path in iTunes again.

Update 2:
I’m not able to mount afp volumes anymore so I’m using smbfs like it is described here (the link is dead). However, this will require a user and password in the configuration file 🙁

Update 3:

Mac OS Sierra breaks the autofs configuration. I had to change it a little bit according to this SuperUser entry. The Gist is updated accordingly.

Update 4:

This still works on Mac OS High Sierra. However, make sure that you enter the credentials correctly and that you spare special characters, according to this blog:

Note: If you have a password longer than 8 characters, or if the password has special characters in it (like “! # $ % & ‘ ( ) * + , – . / : ; & < = > ? @ [ \ ] ^ _ { | } ~”), you may receive a “No locks available” error message and the share will not mount under /home. You will also receive a “No locks available” or similar “Host is down” error if the password is wrong or missing.

I’ve encountered the “No locks available” today and had an error in my password which blocked the auto mounter from opening the folder.

How to use client certificates with Synology VPN Server and OpenVPN

The holidays are near and I want to have access to my files on my Synology NAS, while I’m visiting my family. That’s why I’m showing you today how to configure the official Synology VPN server to use OpenVPN with client certificates instead of username/password.

 

1. Start with a custom root CA

First of all you need your own self-signed root CA. A useful tool is XCA but you can also do this from the terminal.

2. Create a certificate for your DiskStation

Create a new Certificate for your DiskStation. Be aware to use the assigned DNS name, otherwise your browser will complain when you try to connect to the web interface of the DiskStation.

3. Configure the DiskStation to use the server certificate

I’m using DSM 5. There’s a nice new Security setting in the system settings. You can define and upload a certificate there:

Import CertificateThe Private Key and Certificate fields are straight forward. However, the intermediate certificate is the tricky part I forgot. This is the certificate of your self signed root CA. Only with this additional certifacte the trust chain is complete.

4. Trusting the root CA

The next step depends on your computers OS. I’m using Mac OS where I can easily add the root CA certificate as an always trusted certificate.

5. Reload the web interface of your DiskStation

After you’ve set the certificate, the web interface should have been reloaded. Eventually you’ve been warned by your browser about a security issue (you did not trusted your root CA, therefore the web page was untrusted). After a reload and the instructions from step 4, this warning should go away. If you take a look at the certificate tab of the DiskStation’s security setting, you will see that your new server certificate is active.

6. Install the VPN Server

Install the VPN Server from Synology’s Package Center. Its configuration is done from the start menu.

7. Configure the VPN Server

Enable OpenVPN from the Settings of the VPN Server. For more details see Synology’s instructions.

8. Connect via SSH to your DiskStation

Disable user authentication on the DiskStation and enable the certificate based authentication (code taken from this wiki) in this file: /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf

#ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
ca /volume1/myCA/demoCA/my-ca.crt
#cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
cert /volume1/myCA/syn.crt
#key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
key /volume1/myCA/syn.key

#you can enable this line temporary to view log with "tail -f -n 100 /var/log/openvpn.log":
#log-append /var/log/openvpn.log

#plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
#client-cert-not-required
#username-as-common-name

#added
user nobody
group nobody
#added

 

9. Configure your client

I’m only using iOS devices and Macs. Therefore this is again a little biased 🙂 The installation of the clients for Mac and Windows is explained on Synology’s page. iOS is explained on this page (only in german but with screenshots). The initial configuration can be downloaded from the OpenVPN settings page from the DiskStation web interface. The extracted zip file contains the servers official certificates but needs to be modified to add support for the client certificates. Text is taken again from same wiki as above.

#ca ca.crt

#added
dh dh1024.pem
ca my-ca.crt
cert my.crt
key my.key
verb 3
#added

#auth-user-pass

 

The DiffieHellmann Parameters (dh) can also be created with XCA. I would recommend 2048, since 4096 takes ages to generate.

10. Give it a try

Now you can test your VPN connection on your devices. It should not ask for a password, instead it should use the my.crt and my.key you’ve set in the configuration.