Setting up a couple new NAS; my FQDN is not working the same as my existing NAS...

[NAS Newbie]

I have 3 total synolgy Nas. On one of them, the "name1.synology.me" fqdn can be plugged directly into the address of a web browser and it'll automatically redirect to https://name1.synology.me:5001 for a secure connection. I have created new unique FQDN for the other 2 nas and registered LE certs for both of them. I have all ports forwarded to all NAS with separate rules per NAS internal IP. I also have it setup in the NAS security to auto-switch to HTTPS. The new FQDN both work if I type "name2.synology.me:5001" into the browser, but give me a unsecure connection error if I don't include the port at the end of the name.

Searching through the forums I see this issue come up frequently, and I have spent the afternoon trying to step through the solutions in other threads but I'm stumped. As far as I can tell all my router settings are the same for all NAS and so are all my security/network settings. I'm sure there's one little thing I missed somewhere.

 

[Rusty]

Guessing all the nas devices are on the same location or not? Using the same router? If so, you do have them running on separate ports correct?

Looks like an https to https redirect that is not kicking in.

Web station running? Any reverse proxy settings at all?

 

[NAS Newbie]

all NAS are on same LAN. They are on different ports; I was just using 5001 as an example. The ports in DSM match ports in my router port forwarding rules, and they are all on same router.

There is a reverse proxy on the NAS that the FQDN does work on, but that is for Bitwarden and it is the only one. The 2 new NAS do not have any RP.
[automerge]1607898095[/automerge]
Also, all the specified ports are open when I ping them with an ipscanner.
[automerge]1607898260[/automerge]
I did not have Web station running. It is now installed., but I haven't done anything with it.

 

[Rusty]

all NAS are on same LAN. They are on different ports; I was just using 5001 as an example. The ports in DSM match ports in my router port forwarding rules, and they are all on same router.

There is a reverse proxy on the NAS that the FQDN does work on, but that is for Bitwarden and it is the only one. The 2 new NAS do not have any RP.
[automerge]1607898095[/automerge]
Also, all the specified ports are open when I ping them with an ipscanner.
[automerge]1607898260[/automerge]
I did not have Web station running. It is now installed., but I haven't done anything with it.

Ok so this is just a case of http> https redirect that is not working.

Have you tried to turn the setting on and off a bit see if that helps?

If by entering the port access works, then it’s just redirect that fails.

 

[NAS Newbie]

Nothing seems to be helping. I switched https redirect on/off a couple times and even restarted the NAS, no dice. below are screenshots of everywhere I can think of in my setup. It has to be something dumb I'm missing, but I can't see it. I am missing a service of some sort on the list for the LE cert? Like you said, it works when I follow the name with the port, but not without.

[automerge]1607915228[/automerge]
and I also disabled my NAS firewall for now in case that was somehow a problem.

 

[WST16]

Hi,

I’m not sure I fully grasp your problem but I want to say that you’ll need keep in mind that all three NAS devices are sharing the same public IP address now (from what I understood). I think you’ll need to approach it from that perspective.

Your:
nas1.i234.me
nas2.i234.me
nas3.i234.me

Will be hitting the same public IP address. I believe that’s why it works when you add the ports.

 

[Rusty]

Hi,

I’m not sure I fully grasp your problem but I want to say that you’ll need keep in mind that all three NAS devices are sharing the same public IP address now (from what I understood). I think you’ll need to approach it from that perspective.

Your:
nas1.i234.me
nas2.i234.me
nas3.i234.me

Will be hitting the same public IP address. I believe that’s why it works when you add the ports.

The problem is that there is no automatic redirect from a HTTP to https custom port without adding it manually. Works with 1 nas, 2 only work when manually adding the port.

 

[NAS Newbie]

Hi,

I’m not sure I fully grasp your problem but I want to say that you’ll need keep in mind that all three NAS devices are sharing the same public IP address now (from what I understood). I think you’ll need to approach it from that perspective.

Your:
nas1.i234.me
nas2.i234.me
nas3.i234.me

Will be hitting the same public IP address. I believe that’s why it works when you add the ports.

you are correct, but I thought that was the point of the DDNS/FQDN? I thought it was serving as a public-facing gateway into my internal ip? They do all have the same external IP in the DDNS setup.

Also, Rusty is correct in his summary. all of the DDNS will access their designated NAS without the port added on manually, but I get the security warning saying that it is an unsecured link and it is only http. If I choose to blow through those warnings, I can access each NAS without the port being added, but it is not an https link.
[automerge]1607960622[/automerge]
although, after testing some more this morning, I am starting to wonder if the 3 DDNS are fighting each other somehow. I have been able to get into both 1 & 2 this morning, but it took several times refreshing the webpage, and for both of them, the port number for a different nas would initially appear (causing the ddns to fail), but if I manually deleted the incorrect port, it would try again and then the https redirect would work correctly and pull up the correct port.

Also, if I'm able to get into NAS1, then NAS2 has problems. Once I'm able to get into NAS2, then NAS1 has problems.

 

[Rusty]

Personally, I would suggest having a single NAS exposed if it has to be. Setup VPN and access them that way. If there is a reason for accessing all of them via their FQDN then considering running a reverse proxy for apps/services on those NAS and see if that will help out in this clash of the titans situation.

 

[fredbert]

View attachment 2614

You have Internet IP port 6281 on all three rules as being forwarded to port 6281 on three LAN devices. That's not going to fly. Not sure why Unifi didn't raise an alert to stop this.

Likewise, Internet IP port 443 is forwarding to two LAN devices.

Why not have simpler rules limited to a service's ports. Then you'd know you've already assigned those ports and not duplicate them.

 

[NAS Newbie]

You have Internet IP port 6281 on all three rules as being forwarded to port 6281 on three LAN devices. That's not going to fly. Not sure why Unifi didn't raise an alert to stop this.

Likewise, Internet IP port 443 is forwarding to two LAN devices.

Why not have simpler rules limited to a service's ports. Then you'd know you've already assigned those ports and not duplicate them.

Sooo.... I'm trying to setup all 3 NAS locally before I move 2 & 3 to my dad's as part of a system we're trying to set up. What you are seeing is a result of me playing around with trying different port setups. The original problem didn't have all NAS open on all ports.

NAS1 will stay local, but one volume will serve as offsite backup for dad's NAS with hyperbackup. needed port 6281 open for hyperbackup vault.

NAS2 will go to dad's, doesn't need 6281 setup.

NAS3 will go to dad's, will serve as my offsite hyperbackup vault, so needs 6281 open. I can close this port on this rule for now I suppose and reopen it on dad's network.

As a test, I tried the port forwarding rules shown below. I still have the same problem; none of the DDNS ports open https without having the xxx01 port added.

This is roughly what the eventual network will look like

[automerge]1607969142[/automerge]

Personally, I would suggest having a single NAS exposed if it has to be. Setup VPN and access them that way. If there is a reason for accessing all of them via their FQDN then considering running a reverse proxy for apps/services on those NAS and see if that will help out in this clash of the titans situation.

I'm trying to get the NAS setup locally before migrating them to my dad's network. I'll still have the same issue with the 2 NAS on his network I'm guessing. I want to get the FQDN working because it appears to be the simplest way to load a NAS location into the different apps (bitwarden, synology apps, etc). Some of them will work when I add on the https port, but some of them don't.

I have not played with VPN at all yet, but this might force me into that direct. I have a ticket open with synology to see what they say.

 

[fredbert]

Pulling back a step, it looks that the only service that you're needing to communicate between the three NAS is Hyper Backup / Hyper Backup Vault on TCP 6281 and that's not a Web service (i.e. not based on HTTP/HTTPS).

On the destination NAS with Hyper Backup Vault the certificate that's assigned to HBV should include the domain or SANs that you access that NAS from HB: my.domain.com:6281. For HB/HBV the port is the important bit as these communicate directly.

However if you have two NAS on a site you can use the site's Internet router to use two different Internet ports and port forward to the two NAS :

​

Site A (HB: my.domain.com:6281) -> Site B (6821 -> NAS1_IP:6281)​

Site A (HB: my.domain.com:6282) -> Site B (6822 -> NAS2_IP:6281)​

Both Site B NAS should have a certificate for my.domain.com that is assigned to HBV.


The DSM ports, default, 5000 and 5001 are Web services and these can be changed plus the Application Portal and Reverse Proxy features can be used to be the first line of processing for Web requests to the NAS. These use rules based on domain name (e.g. https://myapp.domain.com can be proxied to an app running on a different HTTPS port) and/or port number. For each of these it is best to have a certificate assigned to each rue that refelcts the domain name being used.


Edit:

All that DDNS does is get Internet resolution of your domain / subdomains to the Internet IP of your router. It's purpose is to address the problem of having a dynamic IP assigned by your ISP.

the FQDN that is requested from your DDNS service will resolve all requests to your Internet IP. It is now down to your Internet router to use port forwarding rules to determine which LAN IP to send inbound requests to Internet ports, which otherwise the router would assume are for itself.

Once the FQDN:LAN_IP_port is received by the LAN device it is then the responsibility of that device to determine what next to do. Normally the device will be listening on that port if it has an associated service. This service will process the network request.

If it happens to be a Web proxy service this will then use its rules to determine which local service or other device should receive the request.


DSM itself doesn't have an entry in Application Portal but you can use a Reverse Proxy rule such that: https://mydsm.domain.com is proxied to https://localhost:5001, but be sure to have a certificate assigned that includes mydsm.domain.com in it's wildcard or SAN.

 

[NAS Newbie]

Its going to take me a bit to fully digest what you are saying, but I think it is starting to click. I want to be able to remotely access the 2 NAS that will eventually be on dad's LAN so I can help him troubleshoot. The port forwarding wouldn't be a problem on my LAN, but on his LAN the router is controlled by the internet provider, so we'll have to make some calls to get it all sorted out.

This threw me for a loop momentarily..

Site A (HB: my.domain.com:6281) -> Site B (6821 -> NAS1_IP:6281)​

Site A (HB: my.domain.com:6282) -> Site B (6822 -> NAS2_IP:6281)​

When I setup my port forwarding rules in Unifi, it always gave me the error below in the first screenshot if I tried to set it so that that there were multiple ports in the rule forwarded to multiple different ports as shown below. This confused me, because I thought the point of port forwarding was so that I could do exactly what you are showing. I now realize that I can set up single-port rules that I believe replicate what you show.

 

[fredbert]

Maybe Unifi has a way to allow multiple ports to be defined in the rules where Port 'A,B,C' forward to 'X,Y,Z' with A to X, B to Y, and C to Z. That's pretty normal syntax. But doing separate rule A to X, etc. make it very easy to read.

And you might as well select TCP if you only want TCP to be forwarded, not Both.

 

[NAS Newbie]

A followup question: Synology support says that entering myname.synology.me into a browser will not automatically redirect to https://myname.synology.me:5001 (or whatever https port is). I'm 99% certain that I have done this before, but maybe I've been chasing my tail so much the last couple days that I'm mistaken.

 

[NAS Newbie]

Sooo... I hate to type this out given that you've all spent some time on this thread, but I figured I'd better bring some closure to it in case someone stumbles across this thread. I believe I figured out what happened, and you guys will probably roll your eyes a bit.

When I changed all the NAS to custom DSM ports, I did not go through Application Portal and change the applications to custom ports as well. Most of them were still stuck on 5000/5001. When I redid my router port forwarding rules, I dropped 5000/5001 from the list. This effectively cut off any connection to my apps. I also changed my DDNS server to get away from the obvious synology.me, and so that forced me to change all my apps.

I believe my confusion with the DDNS sprouts from the fact that you never list a port after the DDNs in most of the app logins because they have the default port coded in, and the fact that my browser had remembered my old DDNS and so I never got as far as typing in the HTTPS port number anymore. Once I changed DDNS and custom ports, everything stopped working at once and threw me for a loop. I assumed the problems were directly connected to multiple NAS on the network, when in reality it was my own fault.

Opening 5000/5001 back up in port forwarding and adding my custom port numbers to the end of the DDNS is working well now, and it appears that my imagined in-fighting between the NAS is at least temporarily over.

Thanks again to those of you who took time to try and help me out, I do appreciate it. I figured I at least owed you guys an explanation, even if it was dumb.