Subdomains (and also with reverse proxy) always display the DSM login page on DSM 7.2.1

Currently reading
Subdomains (and also with reverse proxy) always display the DSM login page on DSM 7.2.1

5
2
NAS
DS224+
Operating system
  1. Windows
Mobile operating system
  1. Android
Hi all!

Please help me, I've tried everything and I'm at a loss for ideas

DS224+, DSM 7.2.1-69057 Update 3

1706405507871.png


I added a repo https://packages.synocommunity.com/ to install community packages. 'Syncthing' and 'Gitea' are installed from it

1706404687718.png

1706404825515.png

---
1706404839377.png

---
Firewall was disabled for testing:
1706404860976.png

---
1706404875190.png

---
1706404894861.png

---
Checkout configurations for 'Certificate' below
---
1706404923695.png

---
1706404942975.png

1706404963717.png

1706404974249.png

---
1706404987360.png

---
1706405009790.png

---
1706405024843.png

---
1706405045161.png

1706405764204.png

1706405136089.png

---
Checkout configurations for 'Applications' below
---
1706405160251.png

1706405178802.png

All HSTS (http->https redirects) toggles are disabled for tests.


Problem #1

Subdomains for syno applications and reverse proxy not working.

If I create an alias for the Synology Photos:
1706405200041.png


everything works as expected, app available on:

App also available on ports 80 and 443 with lan-domain (I don't know why, but let it be):

But if I enter "Customized domain":
1706405241544.png


then always DSM login page opened:
1706405261018.png


If we go to any other 4th level domain, we get exactly the same result:
1706405292503.png

In other words, the "Customized domain" didn't affect anything - DSM login page opens on any level 4 subdomain.

The same thing happens if I configure reverse proxy. Syncthing for example (which runs on port 8384):
1706405340789.png

---
1706405352392.png

---
1706405378224.png

1706405531422.png

I'm at a loss. Maybe it's because of level 4 domains? And everything will work fine on level 3 domains?


Problem #2

If I make a "Customized domain" on DSM tab to "myaccount.synology.me":
1706405795580.png


then this page will always return 404:
1706405821121.png


Subdomains continue to (not) work as described above.

Maybe I'm missing something? What is this setting for?
 
Two things:

1) Do you have port 443 forwarded from your router to the synology 443?

2) to use dms with reverse proxy, under login portal go to advanced. Create an https dsm rp item. Source would be https 443 and then it’s routed to localhost 5001

Let’s see if we can get just that bare minimum to work first.
 
Upvote 0
The same thing happens if I configure reverse proxy. Syncthing for example (which runs on port 8384)
Why are you port forwarding 443 to your 5001 internal port? Just port forward it to 443 as well. nginx (internal reverse proxy) is running on 80/443 alongside 5000/5001 (btw you should change these for security purposes ASAP) so there is no need to map 443 to 5001, but rather 443 to 443 if you want to use reverse proxy records.
 
Upvote 0
Last edited:
The problem is you don’t solely make the port changes in customized port under local portal -> synology photos. By you entering https port 5443 there that means the photos service is running on port 5443 and not reverse proxy of 443.

Entering the customize port there without doing the reverse proxy setup means you’d have to enter your domain name:5443 but you don’t have that port forwarded on your router to your nas; nor would you want it set this way if you want to use reverse proxy.

There’s one port forward from router to nas for reverse proxy. Forward 443 on router to 443 nas. Then go into login portal, advanced, and select reverse proxy to create your rp entries. Now if you used some sort of customized port this is where you need to enter that too. So for photos you set 5443 as custom port, create a rp line source 443 to local host 5443 and it should work.

picture yourself a communication line. Typing in a subdomain sends to request to your public ip/domain name over 443. 443 request of this domain name hits the router and says send it to the nas because nas is the one that’s directing this where to go. The rp name matches photo.domain on 443 which then says hey send it to 5443, which then sends it to the app.
 
Upvote 0
Last edited:
1) Do you have port 443 forwarded from your router to the synology 443?

so there is no need to map 443 to 5001, but rather 443 to 443 if you want to use reverse proxy records.

OMG! I finally realized my mistake!
5000/5001 ports is only for DSM, they're not shared to all the other applications.

Forwarding 80 to 80 and 443 to 443 on router solved all the problems described above!

1706479050585.png


And I didn't even have to follow this recommendation:
2) to use dms with reverse proxy, under login portal go to advanced. Create an https dsm rp item. Source would be https 443 and then it’s routed to localhost 5001

Gerard, Rusty thank you very much!

Did you restart your web server after implementing all your changes in subdomain and reverse proxy?
Yes, nginx restarted automatically (or reload configs) when the appropriate settings is saved - any changes I made to the settings had an immediate effect.

By you entering https port 5443 there that means the photos service is running on port 5443 and not reverse proxy of 443.
I didn't change the default ports for the app - the specified ports in the inputs in my screenshots above are html's <input /> placeholder, not the actual value.
But thanks for your explanation!


But I have a couple more questions, if you'll excuse me

1.
nginx (internal reverse proxy) is running on 80/443 alongside 5000/5001 (btw you should change these for security purposes ASAP)
Do you mean override ports 5000/5001?
If so, why? DSM on these ports is only available on the internal network. Or am I missing something?
If you mean 80/443, that was the original point - not to specify ports when typing the address.


2. I failed to set up automatic http->https redirection in "Reverse Proxy" settings.

Any of "HSTS"-checkboxes works as expected (for consistent reproducible results during testing I had to disable "https-only mode" in Firefox and systematically execute "Forget about this site" in history for cache reset) except for the one in "Reverse Proxy Rules".

In the case of Syncthing, the rules have this configuration:
1706478293596.png


If I go to https://syncthing.myaccount.synology.me, everything works as it should.

If I go to http://syncthing.myaccount.synology.me, I get the expected result - site is unreachable:
  • first redirected to http://syncthing.myaccount.synology.me:5000
  • get a response with the code NO_ERROR_CONNECTION_REFUSED:
1706479792119.png


Well, let's add the rules for http:
Note - "HSTS"-checkbox is disabled when "http" is selected in source protocol
1706480276419.png


Syncthing is now available over both http and https. But how do I set up automatic redirect from http to https?
In my case, checked "HSTS"-checkbox in the first rules doesn't affect anything (or I just haven't found a correlation).

The weird thing for me is that the "HSTS"-checkbox becomes disabled when "http" is selected in the source protocol.
Why is it available when "https" is selected? https doesn't need to be upgraded to https, it already is.
And why is it disabled with "http"? That's where there is a need to upgrade the protocol from http to https.

I tried adding one rule (instead of the last one):
1706480971418.png


But it didn't bring the expected result - Syncthing still available over both http and https (because, I guess, when accessed over http there is an internal redirect to external https-address, not an external redirect).

Am I missing something again?
 
Upvote 0
If so, why? DSM on these ports is only available on the internal network. Or am I missing something?
In case you have plans opening those to the web is what I mean. If that is not the case, ignore it.

But how do I set up automatic redirect from http to https?
I would recommend to use a custom reverse proxy, and not the built in one, but if you want to continue to use it, then maybe this process will help you to get redirect working as intended.


WebStation will be needed to get this working, so again, if this is not something that you want, I would again suggest to just use a dedicated/separate nginx reverse proxy that has this built in, like NPM for one.

 
Upvote 0
I would again suggest to just use a dedicated/separate nginx reverse proxy that has this built in, like NPM for one.


Is there a way to configure this to run in one container, instead of having an app container and DB container?
 
Upvote 0
Is there a way to configure this to run in one container, instead of having an app container and DB container?
Ofc you can make a single compose for this no problem. Personally I like to separate front end apps from back end (but that is just me), so that is the reason why the guide is presented that way.
 
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
The setup is: DS918+ running the latest version of DSM 7 LetsEncrypt certificate are working at all...
Replies
0
Views
2,021
  • Question
This is how you can configure redirect on Syno if you are using RP - HTTP to HTTPS redirect I might be...
Replies
4
Views
3,608
  • 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
965
  • 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,732
I accessed to log and when I trying connect I have message: "SSTP_DUPLEX_POST...
Replies
9
Views
1,818
  • Solved
Glad it’s working. Now you can help the next person! No reward necessary 😎
Replies
14
Views
2,362

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