If I change DSM default ports, does that disable the default port access for mobile apps?

Currently reading
If I change DSM default ports, does that disable the default port access for mobile apps?

481
96
NAS
DS220+, DS918+, RS1219+
Operating system
  1. Windows
Mobile operating system
  1. Android
Last edited:
So I'm still poking around my network trying to understand all the ports and how they're interacting. Eventually I'll get some reverse proxies set up, but I want to make sure I clearly understand what is going on at the base level before moving on.

I had DSM set on the default 5000/5001 ports. My android mobile apps (DS Cam & DS File) worked by simply loading in myname.synology.me for the address. I then changed the DSM ports to 38400/38401 and added those ports to my router port forwarding (ports 500,5001,38400,38401 all forwarded for now) and I lost all access with my apps. I tried myname.synology.me:5001 & myname.synology.me:38401 with no luck. If I switched DSM back to 5000/5001, then the apps worked again.

I then tried switching DSM to 38400/38401 and going into the application portal and changing the default ports for File Station to 38440/38441 and added those ports to my growing port forwarding list. myname.synology.me did not work in the apps, but myname.synology.me:38441 did.

Can someone please correct me if my conclusions below are wrong? Given my recent history I want to make sure I'm not making the wrong assumptions.
1. Changing DSM port to something else besides 5000/5001 disables all default ports for mobile app access.
2. In absence of reverse proxy, once #1 occurs, the default ports for the application must be updated under the application portal in DSM and added to port forwarding.
 
if I'm coming in through the 443 port already, do I still need the https redirect?
If you trust your network, you don’t need it.
But keep in mind that the 443 traffic terminates at the RP and gets redirected according to the rule. So if your redirection is on http, traffic will be http transported until it needs to go out over 443 again where it’s transported with https. I’d say standardize and keep your traffic over https, internally and externally. The performance impact is minimal.

right now if I type only "dsm.myname.synology.me", it auto-redirects to "dsm.myname.synology.me:5001" and I can gain access from there. I assume that the "5001" ending up at the end of the url is the result of the reverse proxy going through the 5000 port and being redirected to 5001?
Yes.
 
Upvote 0
Last edited:
🥳🥳🥳🥳🥳 well I just got all 3 DSM RP's up and running. I'm sure tomorrow I'll stub my toe on something and it'll scramble my brain, but for now things are finally making a bit of sense. 🤞
-- post merged: --

out of curiousity, when I type the RP URL "dsm.myname.synology.me" the browser now translates it as "https://dsm.myname.synology.me" but does not include the https numerical port at the end. Why is that?

Since my last question, the only things I changed was the default DSM port to 38301/38401/38501 for the 3 unique NAS, and I pointed the respective RP desination ports to my newly redefined https ports and set it up as an https destination protocol instead of http.

If the connection is https all the way through and doesn't ever go through the https redirect, does the https port not get added to the end of the url by the browser?
 
Upvote 0
If you're asking why the client web browser doesn't stick ':443' on the end then that is because 443 is the default for HTTPS and is there assumed.

The client web browser is making a HTTPS connection to the RP and here is where this connection terminates. The RP then makes its own connection to the destination web service (to one of your NAS on the NAS's custom port). The data between the client web browser and endpoint NAS is passed between these two connections and mediated by the RP: neither endpoint is aware it is not communicating directly to each other. Therefore, the client web browser doesn't have a connection URL with ':NAS_port' as it isn't connecting to the NAS but rather the RP.

If you want you could just put a port forwarding rule on your router for NAS_port and the client web browser could go directly to your other NAS.

==========

When it comes to securing communications it's useful to remember that the only secured part that the client knows is between it and the web service that it is communicating. What happens after that (e.g. within the server, to databases, onward proxying, backdoors into the server) has no guarantee of secure communications. For this reason we need independent security assessors/auditors and security standards to which businesses validate and certify their operations, infrastructure, data handling, or not.

For home, I'd personally try to keep the secure connections going as much as possible, i.e. avoid dropping to HTTP unless the RP'ed local service doesn't support HTTPS.
 
Upvote 0
If you're asking why the client web browser doesn't stick ':443' on the end then that is because 443 is the default for HTTPS and is there assumed.
I understand that :443 is the assumed default.

I initially had my DSM reverse proxy set up with the destination being localhost on an http port 5000, but I also had http redirect flagged in DSM. With this setup, I would type "dsm.myname.synology.me", and when the browser would load the webpage, the url would read "https://dsm.myname.synology.me:5001". It would go through the https redirect and add :5001 to the end of the url.

When I changed the DSM RP to having the desination being localhost on the https port 5001, then typing "dsm.myname.synology.me" would result in the url reading "https://dsm.myname.synology.me" once the page loaded. I'm curious as to why the first option tacked the :5001 onto the url but the second did not. I assume it has something to do with bypassing the redirect by going straight to the 5001 port with the RP. It doesn't really matter, it was just something I noticed.
 
Upvote 0
out of curiousity, when I type the RP URL "dsm.myname.synology.me" the browser now translates it as "https://dsm.myname.synology.me" but does not include the https numerical port at the end. Why is that?
Why are you expecting a port number to be there? Your client (browser) is communicating with the RP.
Your browser to RP over 443 (default https port), RP to NAS over https and whatever port you’ve configured for each NAS (38301/38401/38501).

It’s not like the RP redirects initially, hand you over and steps aside for the rest of the session. The connection is established (and maintained) through the reverse proxy for the duration of the session.
-- post merged: --

Will running surveillance station via RP slow down video playback noticeably? It seems like it sits there buffering or something much longer than it used to. Everything is through https.
I doubt it but why don’t you do a comparison. Connect to SS directly and compare. And if you’re doing this on LAN why not keep it that way (browser to the SS NAS).
 
Upvote 0
Why are you expecting a port number to be there?
I have no expectations either way. It was just a difference I noticed between the two setups and was curious why the former automatically tacked the :5001 on the end of the URL but the latter did not. It doesn't really matter, they both achieve the same end goal. Was just curious.

And if you’re doing this on LAN why not keep it that way (browser to the SS NAS).
Accessing it via phone over the app seems slow too. I'll keep playing with it.
 
Upvote 0
If before you were going direct HTTP 5000 and had enabled the redirect to HTTPS (essentially HSTS) then this would respond to the web browser saying to use the indicated HTTPS 5001 address. The web browser then starts a new connection attempt with the HTTPS 5001 location.

Well it’s either HSTS or that redirect option enables a rewrite rule for all HTTP 5000 to HTTPS 5001. I’ve not looked into the heart of DSM to see how it achieves this but these ways both get the web browser to change its URL location to HTTPS 5001.
 
Upvote 0
Hi all,
I just wanted to thank @NAS Newbie for creating this thread, and all the others for their time and answers.

@NAS Newbie : you have no idea how all your questions helped me. None was dumb. Or at least I hope so, because I am facing the exact same objectives and problems :)
...well, now that I said that I have to go and try to apply all of this. But everything makes more sense to me now. I guess that will help me to get things work ;)
Thank's again!
 
Upvote 0
Hi all,
I just wanted to thank @NAS Newbie for creating this thread, and all the others for their time and answers.

@NAS Newbie : you have no idea how all your questions helped me. None was dumb. Or at least I hope so, because I am facing the exact same objectives and problems :)
...well, now that I said that I have to go and try to apply all of this. But everything makes more sense to me now. I guess that will help me to get things work ;)
Thank's again!
I'm glad I could ask the dumb questions, but the other guys were the ones that deserve the credit. I've been working on a tutorial that tries to give a big-picture view of remote access to your NAS for newbies. It leans heavily on this thread and other more technical tutorials, but I'm attempting to simplify it a bit and tie all the tutorials together. Hopefully it'll be ready soon.

Feel free to ask your own questions too; as evidenced by this threads and others I've started, the people here are very good at walking you through stuff.
 
Upvote 0
Hi there,
As mentionned on last Wednesday, thank you all for all your questions and answers in this thread, it helps me lot.

I managed to access all services working on a single port (5001) through the RP server, using the alternate port I set up for DSM. But I have a problem going further: how can I set services that use several ports behind the RP? The RP configuration tool only allows one port in the source section, on in the destination, and one entry per subdomain address.

In other words and as an example: Synology Contacts not only uses ports 5000 and 5001, but also port 5555 for the CardDav server. How can I:
- avoid to open port nr 5555 in my firewall? (as that's one of the goals behind using the RP server)
- make the RP server listen to and dispatch several ports (in this case ports 5000, 5001 and 5555) with a single subdomain address, e.g. "contacts.mysite.com"?

I know NAS Newbie already asked the question at the bottom of the first page of this thread, but the discussion moved somewhere else and I couldn't find the answer...or I didn't understand the answer, as I am not native english speaker...

Can someone help with that? Maybe using the above mentioned example with Synology's Contact service? How can I place the Synology Contact service behind the RP, access it via the web address "contact.mysite.com", all of that without opening port 5555 on my router? Is it even possible?

Thank's in advance!
 
Upvote 0
Thank you for your answers.
Depends too, which CardDAV server you are using... the standalone, or the one built into Synology Contacts, as access paths/ports are different IIRC.
I will be using the Synology Contacts built in service.

Here is what I did today. May I ask for your feedback on this setup?

My objectives are:
  • Good security (considering that "perfect" doesn't exist, and I am not an IT professional, by far...)
  • User friendly addresses and settings for my family to be able to use the services. They don't want to know about ports, etc.
  • Stability, to avoid hours of IT support to my family. 'saying that because with all the trials I did in the last days with the RP, I had to constantly change my client settings to include port number, erase it, put it back again, etc. etc.

Here is what I have:
  • A domain name: mysite.com
  • Different subdomains pointing to my NAS DDNS address: nas.ddns.com (e.g. dsm.mysite.com)
  • On the router side:
    • Firewall has ports 80 and 443 open, as well as all the ports listed on Synology's website for the services I need.
    • Firewall rules are geographically limited (a very small security layer, but still good to take I guess...).
    • Open ports are all forwarded to the NAS.
  • On the NAS side:
    • http and https ports have been changed to (example) 9998 and 9999.
    • RP server is forwarding "https://dsm.mysite.com" requests to localhost:9999. Knowing that DSM rejects non-https queries. That's all, only one RP rule.
    • All other (Synology) services are being processed with the application portal. For example "audio.mysite.com" for DS Audio services or "activebackupbusiness.mysite.com" fot this service, etc., etc. No particular http or https port setup on the application portal.
What do you think about this? Did I miss something important, especially on the security side? I regret I have so many ports opened in my firewall (not that many, but still more than just 80 and 443 :) ) but that's the only way to go if I understand your previous answers correctly.
 
Upvote 0
Firewall has ports 80 and 443 open, as well as all the ports listed on Synology's website for the services I need.
I don't know your system, but for starters "all the ports listed on Synology's website for the services I need" sounds terrifying. I use none, but 443 (along with reverse proxy and a wildcard suitable domain). Synology's website ports are for the most part, unnecessary for port-forwarding. This should be handled app-by-app. For example... from the Synology Contacts CardDAV link... via port 443...

hxxps://pancake.synology.me/carddav/username
[no reverse proxy needed here]
 
Upvote 0
"all the ports listed on Synology's website for the services I need"
...means port 5555 for Synology Calendar, 6690 for Drive and so on, as per this list and according to my needs.
I don't like it either, but this brings me back to my previous question: how do you manage to put all services, including the ones requiring other ports than 80 and 443 only, behind the RP if it can only handle http and https ports, as WST16 wrote? I guess I am missing a point here. Isn't it required to give access (either by opening or with any other method) to all ports mentioned in the list for the service to work properly?

Synology's website ports are for the most part, unnecessary for port-forwarding.
How do you know which ones are, then? Trial and error?

Thank's
 
Upvote 0
How do you know which ones are, then? Trial and error?
Experience. Trial and Error. For example... if you set up Synology's VPN server, it will ask you to open ports for every VPN protocol it supports... even though you will choose one protocol. Is that really necessary? Or smart? Or secure?

...means port 5555 for Synology Calendar
Unnecessary. 2 reasons. Remotely I will seldom (nearly never) need to log into the DSM calendar, choosing a phone calendar, or PC calendar which syncs with Synology Calendar. OTOH, if I must log into the DSM calendar (I can't imagine why), I will do so using port 443 (no reverse proxy required).

how do you manage to put all services, including the ones requiring other ports than 80 and 443 only, behind the RP
Why would I need to do that? Do you actually need direct external access to every Synology service/package when you can simply log into DSM and access everything there, just as you do at home? I sense you are overthinking this. No offense meant.
 
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
Now go to your Synology account and see if you can unlink the quick connect id. Afterward can you create a...
Replies
3
Views
1,613
  • 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,231
Dear Rusty, Thank you for your response. You are correct about using version=3. However, I am currently...
Replies
2
Views
1,612
  • Solved
<<<<< SOLVED >>>>> OK so I decide to solve this by myself accordingly. Synology did offer me to go check...
Replies
1
Views
1,294

Welcome to SynoForum.com!

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

Registration is free, easy and fast!

Trending threads

Back
Top