Coming Back For More on DDNS and Remote Access

[Pjh104]

Thank you to both Rusty and WST16 for their rapid and helpful responses to my first question yesterday. Having read the recommended documents I am wiser, but not necessarily sufficiently to take meaningful action. I think I see what to do and then as I try to implement it, I remain confused.

My needs are straightforward. I want to use my DS218Play to;

1. backup music and video
2. Play music and video using the relevant DS Audio and DS Video apps within my local network
3. Play music and video using the DS Audio and DS Video apps remotely
4. Use the Amazon Echo Audio Station skill to play music on Echo devices

Now, I have all this working, after a fashion, with DDNS (let’s all it “pjh01.synology.me”) & certificate. I say ”after a fashion” as i suspect the setup is far from optimal, using port forwarding which seems a tad messy and possibly insecure.

I think I can see the Application Portal and Reverse Proxy as a way into this, based on the application that is trying to access the NAS. So,

question 1. Does the NAS understand from which app it is receiving a request?

and if the answer to that is “yes”,

question 2. How do I relate the app I see in the Application Portal to the FQDN required in the Reverse Proxy? is it as straightforward as the FQDN for these specific apps as being ”audio.synology.me” and “video.pjh01.synology.me”?

Thanks again for all your help here.
Paul

 

[Rusty]

question 1. Does the NAS understand from which app it is receiving a request?

In short yes. The name of the app (public url) will be used by the reverse proxy and redirect to a specific app that you have configured your reverse host with.

question 2. How do I relate the app I see in the Application Portal to the FQDN required in the Reverse Proxy? is it as straightforward as the FQDN for these specific apps as being ”audio.synology.me” and “video.pjh01.synology.me”?

Yes you will have a public name for each app and forward its requests using reverse proxy to their local addresses and port numbers.

 

[Pjh104]

Rusty - thanks again.

is the “public name” something I define or is it defined by DSM?

 

[Rusty]

Rusty - thanks again.

is the “public name” something I define or is it defined by DSM?

Defined by you. Check reverse proxy tutorials in the Resource section of the forum.

 

[Pjh104]

Thanks. I was being a bit dim, forgetting that you have to give the FQDN when you login in using any of the Apps. Onwards and upwards!

 

[Pjh104]

Ok, progress (of sorts). All instructions followed:

Application Portal set so that audio station gets Port xxxx and video station yyyy

Reverse Proxy rules set so that FQDN audio.myserver.synology.me Destination Port is xxxx and video.myserver.synology.me Destination Port is yyyy. In both cases Source Port is 443

Port-forwarding now slashed to just 443 on my router.

All well and good when plugging the FQDN into a browser, works a treat. Two glitches, and both may be related to the behaviour of the iOS and Android apps (“the Apps”) that I have on my iPad and Fire Stick.

1. When using the Apps I need to append 443 to the FQDN as set in the RP rules (something I don’t need to do with a browser) when presented with the App login.

2. When using the Apps, the login page will ONLY accept the appended FQDN format described in point 1, it will not accept the “internal” address of the NAS with the modified ports defined by the AP, i.e. aaa.bbb.cc.dd:yyyy for video station. Browsers are, however, quite happy to accept this form.

The first one I can live with, but in requiring the app to step to the external network to then step back into the internal the second one seems odd to me, particularly as the Fire Stick that uses the video app will never be on anything other than the internal network.

Have I missed or misunderstood a step?

many thanks.

 

[WST16]

1. When using the Apps I need to append 443 to the FQDN as set in the RP rules (something I don’t need to do with a browser) when presented with the App login.

Take a look at this thread. It'll explain…

Solved - Why does this reverse proxy fail

I set up this reverse proxy for the DS File app (Android)... but it fails to connect. When I enter "hot.synology.me:5001" in the DS File app, it connects. But if I enter "ds.hot.synology.me" using this reverse proxy, it fails. FWIW, ports 443 and 5001 are forwarded to the NAS (192.168.1.10)...

www.synoforum.com

but in requiring the app to step to the external network to then step back into the internal the second one seems odd to me

If I understood correctly what you're describing (and if it's working), this means that your router has loopback enabled (hairpinning). This is normal. Your traffic will appear as if it's coming from the router. Login to one of the apps internally (over local LAN) using the new FQDN and check the connected users on your DiskStation, you should see your router's IP address (not the client's). It’s not going out and coming back in.

 

[Rusty]

2. When using the Apps, the login page will ONLY accept the appended FQDN format described in point 1, it will not accept the “internal” address of the NAS with the modified ports defined by the AP, i.e. aaa.bbb.cc.dd:yyyy for video station. Browsers are, however, quite happy to accept this form.

using internal address and port should work just fine. What error do you get?

 

[Pjh104]

If I understood correctly what you're describing (and if it's working), this means that your router has loopback enabled (hairpinning). This is normal. Your traffic will appear as if it's coming from the router. Login to one of the apps internally (over local LAN) using the new FQDN and check the connected users on your DiskStation, you should see your router's IP address (not the client's). It’s not going out and coming back in.

Thanks. That is exactly what I see.

-- post merged: 18. Jun 2021 --

using internal address and port should work just fine. What error do you get?

The port number is correctly preceded by”:”. My thick fingers couldn’t quite get the overwriting accurate enough.

 

[fredbert]

Also, check that when using HTTPS that the Settings

isn't set to validate the SSL certificate: especially true when using an IP address, or your SSL certificate assigned to Video Station doesn't cover the server name you are using.

 

[Rusty]

Was about to say the same, is the 9008 an https port and whats with the certs?

 

[Pjh104]

Was about to say the same, is the 9008 an https port and whats with the certs?

9008 is an https port, and appears to be certified. If I switch the “validate SSL certificate“ to off, but leave the “https:” set to on, I get the same result.

 

[Rusty]

9008 is an https port, and appears to be certified. If I switch the “validate SSL certificate“ to off, but leave the “https:” set to on, I get the same result.

running it on http then? Any firewall rules?

 

[Pjh104]

running it on http then? Any firewall rules?

I’ve tried setting an http port as well, and get the same result. I need to do some research on the firewall, as I use Eero for my WiFi with the “Secure” option so there may be something hiding in there that is having an impact. I’ll report back when I have had a look.

Many thanks to all who continue to help directly or have put together a tutorial. I really appreciate it.