Need a process-check for setting up SSL-Secured Synology Drive connections

Currently reading
Need a process-check for setting up SSL-Secured Synology Drive connections

4
0
NAS
DS412+, DS1511+, 2 x DS1817+, 1 x j series
(also posted this on reddit/synology, but no responses)

Hi-
Setting up two identical DS’s for a new client. One will be in their small office (primary NAS), the other at the owner’s home as an offsite Drive sync copy. Users will have the Drive client installed on their work machines and mobile devices. Most likely Mac, Windows 10 and iOS (not sure about Android, yet). Neither the office or home locations have a static IP address and owner would prefer to keep it that way.
Goals & Comments
  1. Harden NAS-to-NAS Drive syncing with SSL certificates that don’t expire every three months, ala Synology’s default LE certs.
  2. Same for client-to-NAS syncing.
  3. Minimize or eliminate any untrusted connection message noise from drive clients (though I read Windows 10 is currently an issue due to a change on LE’s end that Synology has yet to incorporate in the Windows client).
  4. For the purposes of this exercise, VPN is not an option at this time.

NAS-to-NAS sync via drive steps
  1. Register NAS with a supported Synology DDNS to get an DDNS address and setup address syncing
  2. Confirm DDNS address resolves from the internet to the external IP of site
  3. Open inbound router ports for 80 and 443
  4. Use the Syn cert wizard to request Let’s Encrypt cert with the DDNS domain
  5. Make the new cert the default for Drive app(s)
  6. Close ports 80 and 443
  7. Forward the applicable HTTPS port on the router to the DS, e.g., 5001 (is this even needed if users will only be using the drive client? Admin access will be done via quick connect.)
  8. Test HTTPS login to DSM
  9. Repeat for the 2nd NAS
  10. Setup NAS-to-NAS Drive connection using the DDNS address with the SSL option ticket and test the connection

Client-to-NAS sync steps
  1. Install client
  2. Login with correct address and credentials
I’m not at all sure this is the most efficient method.
Also, Is it possible to use a custom LE cert for the quickconnect address so we can bypass the whole DDNS thing altogether? I’m guessing not, but thought I’d ask.
Thanks in advance for the eyeballs and help.
 
Not sure why the steps mention LE certs when goal No1 states that there shouldn't be any use of LE (3 months) certs?

Forward the applicable HTTPS port on the router to the DS, e.g., 5001 (is this even needed if users will only be using the drive client?
Drive desktop client uses a specific TCP 6690 for syncing. More details here.

Also, Is it possible to use a custom LE cert for the quickconnect address so we can bypass the whole DDNS thing altogether? I’m guessing not, but thought I’d ask.
You can use your custom domain name and custom certs ofc. So there is no need to use DDNS, but if you will not use a static public IP address how will you then maintain communication unless you use a DDNS service when your IP changes.
 
Upvote 0
Last edited:
If this is only for Synology Drive and not to access other packages from the Internet then ...

Why use the default ports that any hacker script will scan?
It is recommended practice to use different HTTP and HTTPS ports for DSM, this will slow down scanning of open ports. Also, select options to direct HTTP requests to HTTPS.

[Control Panel -> Login Portal -> DSM / Web Services]

Why expose all of DSM's web portal to the Internet?
You have stated to block Internet access to ports 80 and 443, but then allow access on DSM HTTPS (5001) which gives access to any of DSM's Web packages. You can assign a specific port for Synology Drive's web connection and create a router/firewall port forwarding rule for this instead of TCP 5001.

[Control Panel -> Login Portal -> Applications / Synology Drive]

Which ports for which clients?
As already pointed out by @Rusty there are different ports for different classes of clients.

Web browsers and mobile apps use a Web connection so you use one of the IP/server name/port combinations that you have configured for Web access.

Desktop clients and Drive-to-Drive sync uses TCP 6690, and cannot be changed so ensure you are using encrypted connections.

LE certificates vs paid for certificates?
I've not see any issue using LE certificates. They will auto-renew and the clients should continue to work. The main issue would be when the server name you use to connect to Drive Server isn't covered by the certificate (by a wildcard or subject alternative name (SAN)).

When there's a certificate mismatch with the server name the user will have a dialogue asking to trust the untrusted connection. This occurs again every time the certificate is renewed.

You could get a paid certificate but you will want to do that with a private domain, then you'll have to managed renewing the certificate.

Synology DDNS and/or private domain DDNS?
You don't have to use Synology DDNS: buy a domain and look for a DNS service provider that includes DDNS and is also supported by your choice of DDNS update agent (DSM has some built in).

LE certificates can be managed for private domains too.

You could use both Synology and private domain DDNS. Even add QuickConnect too. The main point would be to be sure to get the certificates created so that they are trusted no matter how the service is connected to. For instance, I create LE certificates based on my Synology DDNS and add the wildcard for this domain, then I add explicit SAN entries for server names from my private domain... I always use the private domain to access the NAS but then I have a fallback DDNS with Synology should anything go wrong.


I would run the deployment as a pilot first (that's like a testing phase) and use LE certificates. If they behave without issue (and do a manually initiated renewal, or run for 3 months) then you can continue to use LE, if not then you can plan for purchasing certificates.
 
Upvote 0
Synology's whitepaper on QuickConnect.

Without DDNS you will be relying on Hole-Punching and the Relay Server. I've not read this document for a while but conceptually...

Hole-punching is a means of a server first creating an outbound connection and this is then used by the client to make its inbound connection. The limitation would be that the client may be in a location that blocks these types of connections, such as a firewall that limits outbound connections to known TCP services on their known 'low' ports.

page7image1121920656


If hole-punching doesn't work then the relay service will be used (if you've permitted it in Control Panel). This invariably works but... any secure connection isn't between client and NAS instead it is broken into two secure connections:
  1. client to relay service
  2. relay service to NAS
I didn't see where it said that there was a third tunnel (client to NAS) through the two half-tunnels, that would provide end-to-end encryption. So there is a theoretical gap where the connection is within the relay service environment and not secured. Plus the whole connection's security is mediated by the relay service.

page7image1121921024


I'm not saying that there is anything nefarious happening in the relay service, but I am highlighting the break in your end-to-end security and that it is not in your control. I would also point out that Synology also build and patch the NAS, and that has access to all the server data... you've already made a trust decision but using the relay service may be one step too many.

Also, the relay service will impact bandwidth performance as the connections traverse it, and Synology won't being allowing unlimited connectivity.
 
Upvote 0
Last edited:
(also posted this on reddit/synology, but no responses)

Hi-
Setting up two identical DS’s for a new client. One will be in their small office (primary NAS), the other at the owner’s home as an offsite Drive sync copy. Users will have the Drive client installed on their work machines and mobile devices. Most likely Mac, Windows 10 and iOS (not sure about Android, yet). Neither the office or home locations have a static IP address and owner would prefer to keep it that way.
Goals & Comments
  1. Harden NAS-to-NAS Drive syncing with SSL certificates that don’t expire every three months, ala Synology’s default LE certs.
  2. Same for client-to-NAS syncing.
  3. Minimize or eliminate any untrusted connection message noise from drive clients (though I read Windows 10 is currently an issue due to a change on LE’s end that Synology has yet to incorporate in the Windows client).
  4. For the purposes of this exercise, VPN is not an option at this time.

NAS-to-NAS sync via drive steps
  1. Register NAS with a supported Synology DDNS to get an DDNS address and setup address syncing
  2. Confirm DDNS address resolves from the internet to the external IP of site
  3. Open inbound router ports for 80 and 443
  4. Use the Syn cert wizard to request Let’s Encrypt cert with the DDNS domain
  5. Make the new cert the default for Drive app(s)
  6. Close ports 80 and 443
  7. Forward the applicable HTTPS port on the router to the DS, e.g., 5001 (is this even needed if users will only be using the drive client? Admin access will be done via quick connect.)
  8. Test HTTPS login to DSM
  9. Repeat for the 2nd NAS
  10. Setup NAS-to-NAS Drive connection using the DDNS address with the SSL option ticket and test the connection

Client-to-NAS sync steps
  1. Install client
  2. Login with correct address and credentials
I’m not at all sure this is the most efficient method.
Also, Is it possible to use a custom LE cert for the quickconnect address so we can bypass the whole DDNS thing altogether? I’m guessing not, but thought I’d ask.
Thanks in advance for the eyeballs and help.

First, I want to thank everyone for taking the time to reply.
(also posted this on reddit/synology, but no responses)

Hi-
Setting up two identical DS’s for a new client. One will be in their small office (primary NAS), the other at the owner’s home as an offsite Drive sync copy. Users will have the Drive client installed on their work machines and mobile devices. Most likely Mac, Windows 10 and iOS (not sure about Android, yet). Neither the office or home locations have a static IP address and owner would prefer to keep it that way.
Goals & Comments
  1. Harden NAS-to-NAS Drive syncing with SSL certificates that don’t expire every three months, ala Synology’s default LE certs.
  2. Same for client-to-NAS syncing.
  3. Minimize or eliminate any untrusted connection message noise from drive clients (though I read Windows 10 is currently an issue due to a change on LE’s end that Synology has yet to incorporate in the Windows client).
  4. For the purposes of this exercise, VPN is not an option at this time.

NAS-to-NAS sync via drive steps
  1. Register NAS with a supported Synology DDNS to get an DDNS address and setup address syncing
  2. Confirm DDNS address resolves from the internet to the external IP of site
  3. Open inbound router ports for 80 and 443
  4. Use the Syn cert wizard to request Let’s Encrypt cert with the DDNS domain
  5. Make the new cert the default for Drive app(s)
  6. Close ports 80 and 443
  7. Forward the applicable HTTPS port on the router to the DS, e.g., 5001 (is this even needed if users will only be using the drive client? Admin access will be done via quick connect.)
  8. Test HTTPS login to DSM
  9. Repeat for the 2nd NAS
  10. Setup NAS-to-NAS Drive connection using the DDNS address with the SSL option ticket and test the connection

Client-to-NAS sync steps
  1. Install client
  2. Login with correct address and credentials
I’m not at all sure this is the most efficient method.
Also, Is it possible to use a custom LE cert for the quickconnect address so we can bypass the whole DDNS thing altogether? I’m guessing not, but thought I’d ask.
Thanks in advance for the eyeballs and help.

First, I want to thank everyone for taking the time to reply. A bunch of great stuff to think on.

I hadn't realized that all LE certs expired every three months, that's why I was thinking custom LE. I really don't care if they expire/renew every three months or years, as long as they don't break sync. NAS-to-NAS drive sync breaks for me everytime the SSL renews, throwing a message about an abnormal state due to a change in the SSL cert. Simply reconnecting with credentials fixes it, but it's not something I want to do. All this has been confirmed by Synology support (I thought it was broke). They also told me that clients would have to reauthenticate as well.

That said, perhaps I should come at this a bit differently. Given the following:

Two Diskstations, a primary and secondary, syncing with Synology Drive (plus clients to primary), located at different sites with a DHCP-generated WAN address and ISP-provided routers. The business is small, with 8 clients at most.

What are your recommendations for setting up sync that is secure and requiring the least amount of admin/maintenance? All thoughts welcome, including VPN.
 
Upvote 0
This still sounds like an issue with the certificate and the server name being used to access Drive. Though I don't use NAS-to-NAS Drive ShareSync, maybe that is different.

Can you check which server name is being used to access Synology Drive: go to each device and see what server name has been configured.

Then check the SSL certificate, or certificates, assigned to Synology Drive Server and Drive's web portal unique FQDN (if you have set up one in Control Panel's Login Portal). Looking in Control Panel's Security / Certificate settings you'll see a list of all your certificates and it says what services each one is assigned to. Now look at the certificates that you assigned to Synology Drive and see if the server name's you use to access Drive services are listed in the certificate domain name (the certificate's main domain) or subject alternative name (a list of alternative server names that the certificate will secure).

If you are using Synology DDNS and LE certificates then your certificate can be:
  • Domain name: mynas.synology.me
  • Subject alternative names: *.mynas.synology.me
You could then use drive.mynas.synology.me in Login Portal for Drive's web portal. And with this certificate assigned to both 'Synology Drive Server' and 'Synology Drive - drive.mynas.synology.me' you can connect to the NAS for both mobile app (TCP 443, if you wanted to or the portal can have a dedicated port) and desktop clients (TCP 6690, with router port forwarders).

I've not noticed my mobile or desktop Drive clients stop working when their LE certificates are auto-renewed. Same goes for Active Backup for Business the client continue to work, provided the server name used to access ABB on the NAS has a correctly assign certificate.
 
Upvote 0
I want to thank everyone for their replies. I've learned quite a bit. Ultimately, the client pivoted and went with a 100% cloud solution instead of on-premises. That said, I'm going to work on getting this to work with my various devices. Again, thanks for the advice.
 
Upvote 0

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Question
Hey @jeyare thanks for taking the time to reply in such detail, I really appreciate it. I think I get it...
Replies
2
Views
1,295
I haven't touched a Sonicwall in years - that said, I would probably enable the DSM firewall as you can...
Replies
2
Views
2,571
If you are using Android, just choose "Continue" when screen mentioning "Certificate" appears after sign-in.
Replies
27
Views
6,191

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top