Reverse Proxy for Synology Drive Client

Currently reading
Reverse Proxy for Synology Drive Client

16
0
NAS
DS1621xs+, DS1621+
Operating system
  1. macOS
  2. Windows
Mobile operating system
  1. iOS
DS1621xs+
DSM 6.2.3-25426U3

I'm new to reverse proxies. I've set up external access to DSM using reverse proxy from external port 443 to my internal port for DSM access, e.g. https://dsm.xxx.dsmynas.com > 10.0.1.2:5501. The only port I have open externally is 443.

I'm now trying to do the same for Synology Drive Client on 6690. If I set up the reverse proxy the same way, e.g. https://drive.xxx.dsmynas.com > 10.0.1.2:6690, my Synology Drive Client (MacOS) on an external network can't connect. It works fine if I set up port forwarding of 6690 and set up the Drive Client to connect to xxx.dsmynas.com. I tried being specific in the Drive Client address settings, e.g. https://drive.xxx.dsmynas.com:443, but that still resulted in a connection failure. Is the Drive Client tied to only looking for port 6690? And in that case, I will have to have that port exposed as the reverse proxy won't work?

Thanks,
Howard
 
The desktop Drive client doesn’t use web HTTP/HTTPS services so you will have to open TCP 6690 for this. The mobile apps seem to use web services, which can be proxied using the web-based reverse proxy.

If you search the forum for 6690 you’ll find some posts about this exact situation.
 
Is the Drive Client tied to only looking for port 6690?
Unfortunately: yep

And in that case, I will have to have that port exposed
Yep

as the reverse proxy won't work?
That I don't know for sure. I don't know if it's purely HTTP traffic, which in this case can work via a layer 7 HTTP reverse proxy.
Otherwise, it should still be possible to reverse proxy this from layer 4. But Synology's GUI doesn't support it. So thats why I have a seperate reverse proxy in a Docker container.
 
Thanks both. I searched for reverse proxy and drive but didn't think to search for the port number. The reverse proxy setup in Docker is well over my head at the moment, but I've bookmarked that thread for future reference. Thanks.
 
But Synology's GUI doesn't support it
Actually, you can get it using Syno UI.

Control Panel > Application portal > Drive app. Here you define the Drive app on a custom HTTP/HTTPS port. Then use that port on the Reverse proxy tab to make a custom https://drive.xxx.domain.com:443 entry. It works, I have it configured like that.
 
Actually, you can get it using Syno UI.

Control Panel > Application portal > Drive app. Here you define the Drive app on a custom HTTP/HTTPS port. Then use that port on the Reverse proxy tab to make a custom https://drive.xxx.domain.com:443 entry. It works, I have it configured like that.
For the desktop Drive client sync? That uses TCP 6690 (old Cloud Station sync) which, AFAIK, isn't a web service.

Have just tried it behind work's firewall and it's all blocked: drive_domain, drive_domain:433, drive_domain:6690, https://... they all fail. But web browsing to https//drive_domain works. In this situation it's best to forget Drive sync for Finder/Explorer access and use WebDAV via a reverse proxy rule.
 
For the desktop Drive client sync?
No, not for the client-side. That has to work on 6690. My reference was just for the Drive web ui access. The fact that you can configure it via reverse proxy as I understood that @Shadow was referring to that specific element that cant be configured.

As you and Shadow already said, 6690 for the client is baked in.

In this situation it's best to forget Drive sync for Finder/Explorer access and use WebDAV via a reverse proxy rule.
Would agree yes, if opening 6690 on top of 443 is not an option.
 
No, not for the client-side. That has to work on 6690. My reference was just for the Drive web ui access. The fact that you can configure it via reverse proxy as I understood that @Shadow was referring to that specific element that cant be configured.

As you and Shadow already said, 6690 for the client is baked in.


Would agree yes, if opening 6690 on top of 443 is not an option.
Hey Rusty,

I am running DSM 7.x. I set the https port for Drive in the Control Panel->Login Portal to 10003. I created a Let's Encrypt cert for drive.mydomain.com and setup a reverse proxy for drive going from 443 to 10003. When I hit drive.mydomain.com, it connects successfully. My issue is that the Public link that Drive generates for a file stored on Drive has port 10003 in it. Here is what it looks like.


If I remove :10003 and just let the reverse proxy do what it does, the public link works fine. My only issue is that I need to remember to remove the :10003 before sending a link to anyone. Do you have any ideas on how I can get around this issue? Thanks.
 
Do you have any ideas on how I can get around this issue?
I would say that you have either DDNS or QC configured on that machine as well?

If so, try this article to customize your domain name and stop DSM from adding custom ports to it.

 
Thanks Rusty! With the help of another person, I solved my problem this way: In Synology Drive Admin Console, go to Settings > Sharing > Customize sharing link. This allowed me to continue using reverse proxy for drive https access using port 443 for public links. Seems like a pretty clean solution.
 
@ddetton - Exactly what I'm trying to do! Couple questions for clarification...

Reverse Proxy setup - destination port = 6690?
Did you add a web service port (HTTP or HTTPS) for the Synology Drive application?
Drive admin console > Customize Sharing Link - what format did you use for the domain?
  • Did you add an http header?
  • Did you add a port number to the end? (I wouldn't think so, but had to ask)
 
Synology Drive uses TCP 6690 for non-Web agent connections. That means agents that are installed on Macs, PC, etc. and non-Web connections cannot be handled by the Reverse [Web] Proxy. For Drive's mobile apps then these are using Web connections and you can add reverse proxy via Login Portal and setting a customised domain.

You could then set the Drive Admin Console's Sharing setting to use the customised domain.
 
Ah, ok. Thanks for the explanation. I assumed that ddetton was able to make the configuration work with the desktop agent.
 

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

I accessed to log and when I trying connect I have message: "SSTP_DUPLEX_POST...
Replies
9
Views
1,823
I don't want to use NPM or any other software; I found a solution that works with Synology's built-in...
Replies
4
Views
2,635
  • Question
Does this only happen when you try to access packages via the 'office' links in Drive's menu? And have you...
Replies
1
Views
967
  • Question
Ofc you can make a single compose for this no problem. Personally I like to separate front end apps from...
Replies
10
Views
1,478
  • Solved
I think it was point 1 that was messing me up. And it was a simple fix, honestly. We'll have to see if I...
Replies
3
Views
1,740
  • Solved
Glad it’s working. Now you can help the next person! No reward necessary 😎
Replies
14
Views
2,365
The thing is... Too many users freeload off Marius and then come to the forums for assistance. Give Marius...
Replies
4
Views
1,909

Welcome to SynoForum.com!

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

Registration is free, easy and fast!

Back
Top