Improving OpenVPN security on Synology NAS

This guidance refers to DSM 5.2-5592 Update 4, with VPN Server 1.2-2456, and the official Android client v1.1.16 (build 74).

When setting up a VPN on a Synology NAS, you can make a choice between PPTP, OpenVPN, and L2TP/IPsec. For assorted reasons, I chose OpenVPN. However, I was underwhelmed with the security stance of the default Synology configuration. Specifically, the default was TLS/1.0, and used a username/password combo for authentication. TLS/1.0 has issues – the current best-practice is to use TLS 1.2. Just relying on a username/password opens you up to brute-force attacks, especially if you use a weak password as many people do in their intranet.

I have changed this configuration to use TLS 1.2, and TLS-authentication. I opted not to use a user key.

Below I have documented how to install and configure OpenVPN at this security level on a Synology NAS. I am using CloudStation to distribute files between my NAS and my clients – other approaches such as SMB shares would also work.

1) Install the VPN Server

Identify and set up a way to distribute files from the NAS to your client computers (e.g. phone, laptop, etc). I used CloudStation, with the Android and Windows DS Cloud clients.

Set up Dynamic DNS. Go to Control Panel, External Access, DDNS, and click Add. Follow the relevant instructions. Make a note of the hostname you pick. Alternately, from your home network browse to or similar and make a note of your public IP address. Note: Most ISPs will give you a dynamic public IP address, which can change over time, hence the recommendation for Dynamic DNS.

Install VPN Log onto the NAS with admin credentials. Go to Package Center, Utilities, and click on Install for VPN Server (by Synology Inc).

Set up Port Forwarding. If your home router supports UPnP, go to Control Panel, External Access, Router Configuration. Click on Set up router, if prompted. When set up, click Create, Built-in application, and check the row which says “VPN Server UDP 1194 1194”. Click Apply, and then Save. If you encounter problems with this, you may not be using a UPnP server. In which case you need to go into your home router config, and set up port forwarding. You’ll want to forward traffic from your external IP UDP/1194, to the IP address of your NAS (e.g. UDP/1194.

Optional: You may want to use a non-standard port rather than 1194. If so, you’ll either need to select a Custom Port in the router configuration page, or manually configure on your router. Just replace all mentions of 1194 in the above with the port you select, making sure you don’t use a port which is already in use.

Set up Auto Block. Go to Control Panel, Security, Auto Block. Check the “Enable auto block” checkbox, set the settings as appropriate. I recommend clicking on Allow/Block list, and adding the IP address of the computer you use to administer the NAS from to the “Allow List”. This will stop the NAS from blocking you even if you get the password wrong a few times. Click Apply when done.

2) Configure the VPN Server

GUI Setup

Go to VPN Server, General Settings, and uncheck “Grant VPN permission to newly added local users”. Verify that Auto Block is set up. Click Apply.

Go to VPN Server, Privilege, then uncheck all check boxes except the OpenVPN entries for the users you want to allow OpenVPN access. (Note: I’m assuming you’re not using PPTP/L2TP). I highly recommend you don’t allow admin to VPN in. Click Save when done.

Go to VPN Server, OpenVPN. Check the Enable checkbox, and set up your Dynamic IP address range etc. This must be a different subnet to your home network. If you chose to use a different port/protocol in step 1, change the Port and Protocol values. When complete, click Apply.

Click Export configuration – this will download a zip file to your local machine. Unzip that into your CloudStation folder.

Terminal Setup

SSH in. After doing the above, SSH into your NAS, as user “root”, using the same password as “admin”. If you cannot SSH in, go to Control Panel, Terminal & SNMP, and verify that “Enable SSH service” is checked, and configured as you expect.

Do the following commands, where $user is the username you’re using for cloudstation, and assuming the folders are in volume 1, and you unzipped the downloaded configuration into a folder called openvpn.

> cd /var/packages/VPNCenter/target/etc/openvpn/keys
> openvpn --genkey --secret ta.key
> cp ta.key /volume1/homes/$user/CloudStation/openvpn/
> chown $user.users /volume1/homes/$user/CloudStation/openvpn/ta.key
> vi /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf

Add the following lines:-

tls-version-min 1.2
tls-auth /var/packages/VPNCenter/target/etc/openvpn/keys/ta.key 0

Save the changes (Esc, :wq), then optionally exit the SSH session.

Restart the VPN server. This can be done by going to Package Center, Installed, VPN Server, and Clicking Action->Stop, then when stopped clicking Action->Start.

3) Configure the client

Edit the openvpn.ovpn file in your CloudStation. Find the YOUR_SERVER_IP and replace it with the dynamic DNS hostname or IP address you identified in step 1. Then add the following line:

tls-auth ta.key 1

Save the file.

Upload the ca.crt, openvpn.ovpn, and ta.key files on to your phone – they all need to be in the same directory. If using CloudStation, this will be done automagically when your phone is on your home WiFi.

Install the client “OpenVPN Connect” package on Android. Run it. Press the three dots in the top right, and go to Preferences. Scroll down to Minimum TLS version, and set to TLS 1.2. Go back to the main screen.

Press the three dots again, and select Import. Then “Import Profile from SD Card”. Browse to wherever you downloaded the openvpn.ovpn file, and select it. Enter your username and password.

Disconnect your phone from your home WiFi, and make sure mobile data is enabled. Click Connect. Fingers crossed, after a few seconds, a connection should happen.

If you don’t connect, and no error is shown, try the following:-

  • Verify that you’re using the correct IP/hostname
  • Verify you’ve set up port forwarding correctly
  • If you can’t tell the above, try changing the protocol to TCP. This can be done via the Synology GUI, or by changing the “proto udp6” in the server file to “proto tcp-server”. You’ll also need to change the openvpn.ovpn line “proto udp” to “proto tcp-client”. Don’t forget to restart the server, and delete and reimport the client.
  • Verify that the changes you made manually to the server config are still present, by ssh’ing in and checking with vi. It’s possible that changing settings via the GUI will clobber any manual changes you have made.

4) Optional improvements

By using a non-standard port (i.e. not 1194) you’ll be less likely to turn up on port scans.

Using the ta.key with tls-auth means that anyone attempting to connect to your server will need that key. If you want to use a user key instead or as well as a password, that could add extra security.

By default, with TLS1.2, the connection seems to be TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 which should be sufficient. If you want a different TLS cipher, first identify the string by SSHing to the server and running: openvpn –show-tls You can then set the selection through adding a “tls-cipher <: delimited ciphers>” in both the server and client.


2 thoughts on “Improving OpenVPN security on Synology NAS

  1. Good tutorial, but the OpenVPN android app keeps asking for a certificate. If I select to install the ca.crt it still keeps asking for a certificate and because of the certificate Android now warns that “Network may be monitored” by a third party. I can choose to connect without a certificate, and it works fine then, but does not that defeat the purpose?

    • Good point, I missed the optional ca.crt installation. The error message is because the ca.crt is installed as a User cert in “Trusted credentials” – there’s no way to ‘trust’ it to remove that warning unfortunately. The mitigation here is to manually check the list of certs in that store periodically.

      That said, this ca.crt isn’t actually needed when we’re using the ta.key. Basically, we’re relying on a pre-shared key to verify that the server is the correct server, rather than relying on the server having a server certificate signed by a certificate authority which we have the certificate for (ca.crt).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s