Reverse proxy with CNAME and DDNS redirecting to DMS main port

[chris.arney]

I have a DS420j. I've got another computer on the same network running a service on a non-standard port. I was able to get the reverse proxy working with the DDNS service that Synology offers. I was able to get a certificate. I can confirm it works from outside my network beautifully. I've got my own domain that I'd like a subdomain to be redirected to that service on my computer, so I setup a CNAME to for my subdomain to point to a subdomain on the DDNS, BUT it gets redirected to my DSM instead. For example, this works:
https://service.user.synologyDDNS.com connects fine to my internal 192.168.0.100:1234
But this does not work:
https://user.mydomain.com (CNAME to service.user.synologyDDNS.com) instead connects to 192.168.0.200:5001 (My DS420j)

What am I doing wrong? It works fine with the DDNS subdomain, but not my own subdomain I own?

 

[Rusty]

Welcome to the forum!

so I setup a CNAME to for my subdomain to point to a subdomain on the DDNS

Don't do that. Just make an alias and point it to your ddns name (aka public IP address of the destination). Then, using the reverse proxy, configure a record "user.mydomain.com" on 443/https and point it to 192.168.0.100:1234

That should work just fine with 0 issues.

 

[chris.arney]

I would have, but my internet IP isn't static. I'm not sure how often it changes, but I'm not paying for a static IP or anything. I have a feeling it doesn't change often, but I haven't taken a look at it. I've got AT&T fiber.

 

[Rusty]

I would have, but my internet IP isn't static. I'm not sure how often it changes, but I'm not paying for a static IP or anything. I have a feeling it doesn't change often, but I haven't taken a look at it. I've got AT&T fiber.

There is no need for it. Just enter the alias pointing to your ddns name, no need for a public ip (it was just an example)

 

[chris.arney]

Thank you so much for responding! I tried an alias, and it still redirects to the NAS port instead of doing the reverse proxy.

To clarify, I want the main domain to point to my hosted website, but I want subdomains to point to various hosted services I have on my internal network. The DDNS links are so long with the proxied.myDDNSaccount.DDNSservice.com.

Could this have anything to do with my security certificates? I noticed some odd behavior before I got some of my certs issued.

 

[Rusty]

dns record pointing to your ddns is just so that your domain requests know where to go initially.

Once they hit your router, port forward should be configured towards your reverse proxy.

In DSM case that would mean 443 request (external) being pushed to internal NAS IP on 443.

Once that is done, reverse proxy will then based on the configuration of each RP host, redirect internally.

So, how about a single example of how you have it all configured and what you want to accomplish. Maybe we can spot the issue that way.

 

[chris.arney]

I figured it out... I realized that I needed to put entries for the actual domain I own also into the reverse proxy table. I thought since it was being redirected to the DDNS, that I only needed that in the reverse proxy forms! Thanks for the help!!!
[automerge]1670860871[/automerge]
So, related, but new question. Now that I've got that working, it doesn't look like my certificate is working correctly. Do I need to get the certificate from my domain name server, or the one in my NAS? I've got one for comics.DDNS.com and comics.mydomain.com, both on my NAS. But only the comics.DDNS.com comes through https correctly, while the comics.mydomain.com show up as insecure in Chrome.

 

[Rusty]

But only the comics.DDNS.com comes through https correctly, while the comics.mydomain.com show up as insecure in Chrome.

If the certs are imported into Synology cert store, then make sure to change the RP host record after you have created and assign the valid cert to it using the Certificat tab in the control panel.

 

[chris.arney]

I'm not sure I follow. In the RP panel, I've got 2 entries for Komega:

source host: komega.user.DDNS.com
destination host: Linux IP
destination port: komega port

source host:komega.mydomain.com
destination host: Linux IP
destination port: komega port

In security -> certificates -> settings:

service: komega.user.DDNS.com
certificate: komega.user.DDNS.com

service: komega.mydomain.com
certificate: komega.mydomain.com

To clarify, Chrome specifically says the certificate is good, but it says the site is "insecure" for my domain, but it doesn't have any warnings when I'm only going through the DDNS.

 

[Rusty]

Chrome specifically says the certificate is good, but it says the site is "insecure" for my domain

if the cert is valid that's one thing, but if the site is flagged as insecure that means that there is some issue with the site and cert combination.

So the cert is def covering the fqdn of the site? You are targeting it over 443 not a custom port correct?

 

[chris.arney]

I believe it covers my fqdn, and I did not change to a custom port. I had to look up fqdn, and I'm about 85% sure I'm answering your question correctly. The cert is for comics.mydomain.com and port 443. It does connect over https.

 

[Rusty]

Would it be possible to see the actual error? Also does this happen with multiple browsers?

 

[chris.arney]

Good question about other browsers:

Chrome on Linux on the same network (assuming hairpin NAT) after clearing all cookies: shows "Not secure" next to the address line

Chrome on Android outside the network: seems to work fine. Clicking the lock icon shows "Connection is secure"

From outside the network on a Win10 machine that I've never visited the site from before:
Edge on Win10: redirects to NAS port, and page doesn't load at all. Security flagged as insecure site
Chrome on Win10: Acts fine

 

[Rusty]

These are results all over the place. Could it be that the built in DOH feature in those browsers is returning such results? Smart DNS as they are called.

Try and turn off the settings in both browsers and try again (under security section)