0

tl;dr

I tried setting up nginx to forward a TCP connection over 6690 to Synology Drive. But when using listen 6690 ssl; the Synology Drive Client cannot find the NAS, and when using listen 6690; (without SSL) the NAS is found, but its unsigned certificate is used instead of the certificate stored with nginx. Any idea how to enable SSL and use an nginx reverse proxy with Synology Drive?

Intro

I already found several posts/questions explaining how to set up a SSL-connection to a Synology NAS using nginx as a reverse proxy on a separate computer. Thereby, when accessing (https://)my-domain.com I can (already) access my Synology Drive's settings website (i.e. the DSM reachable via port 5000/5001). However, I also want to set up Synology Drive to use the same SSL certificate from Let's Encrypt, but here I'm having difficulties setting up nginx.

Question

So, I only want Synology Drive configured and I set up the DNS of drive.my-domain.com to reach my router. Also, I acquired an SSL certificate for this domain and have adjusted the Synology Drive HTTPS port to be 10003. In my router, I forwarded ports 80, 443 and 6690 to my reverse proxy as recommended here. For nginx, I configured /etc/nginx/conf.d/synology.conf:

include /etc/letsencrypt/options-ssl-nginx.conf;

server {
    listen      80;
    server_name drive.my-domain.com default_server;

    # For Let's Encrypt verification
    location ^~ /.well-known {
        allow all;
        root /data/letsencrypt/;
    }
}

server {
    listen 80;
    listen 443 ssl;
    server_name drive.my-domain.com;

    location / {
        proxy_set_header    Host $host;
        proxy_set_header    X-Real_IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          https://<IP-OF-SYNOLOGY-NAS>:10003;
        proxy_read_timeout  90;
    }

    ssl_certificate         /etc/letsencrypt/live/drive.my-domain.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/drive.my-domain.com/privkey.pem;
    
    include /etc/letsencrypt/options-ssl-nginx.conf;
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

Further, I added the following line to /etc/nginx/nginx.conf:

...

include /etc/nginx/fallthrough.conf;

And /etc/nginx/fallthrough.conf contains the following:

stream {

    upstream synology_drive {
         server <IP-OF-SYNOLOGY-NAS>:6690;
    }

    server {
        listen     6690 ssl;
        proxy_pass synology_drive;
        
        ssl_certificate     /etc/letsencrypt/live/drive.my-domain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/drive.my-domain.com/privkey.pem;
    }
}

However, when trying to set up the Synology Drive Client, it cannot connect/find the Synology NAS. When changing the /etc/nginx/fallthrough.conf to not use SSL, i.e.:

stream {

    upstream synology_drive {
         server <IP-OF-SYNOLOGY-NAS>:6690;
    }

    server {
        listen     6690;
        proxy_pass synology_drive;
    }
}

The Synology NAS is found, but the self-signed certificate stored on the NAS is used, instead of the certificate from Let's Encrypt stored on the reverse proxy computer.

Does anybody know what I am or may be doing wrong here?

Max Z.
  • 101
  • 3

1 Answers1

1

The stream module is a layer 4 proxying module, that is, it only forwards TCP packets between the connecting client and proxied server.

As TLS happens on a higher level, nginx takes no part to the SSL encryption. I am actually surprised that nginx gives no errors on the ssl_certificate directives that are in your configuration.

Your only option is to copy the private key and certificate from nginx to the Synology device, as that is the entity that terminates TLS connection in this case.

Tero Kilkanen
  • 34,499
  • 3
  • 38
  • 58
  • Before setting up nginx as a reverse proxy, I already regularly copied the keys to Synology. But doing so seemed unstable and not the preferred method. Well... I guess I'll have to stick to it for the time being. – Max Z. Jan 24 '22 at 07:08