Hyper Backup task remote connection issue due to DSM 7.2 *RESOLVED*

[Gerard]

Attempting to setup a new Hyper Backup task to utilize Synology's new "Entire System - Faster Block Level Backup" option. I received notification today to update to HB 4.1.0-3176, and in doing so I am unable to connect to my remote NAS. I am using the same exact DDNS name and port number. When I click login I receive the below error.

Additionally, I went into the existing task that I've had for years and can see that is still connected. I then clicked the log in button on there and received the same error. I then closed without saving so as not to mess up the existing task that is currently working.

Can anyone else test creating a new backup type for entire system, to a remote offsite NAS and advise if they are having the same issue? I have done this both ways on two different NAS': RS820+ to DS718+ and DS718+ to RS820+ are both receiving the same message. *Also, other options such as file/folder type backup has the same issue as well.

 

[Gerard]

I've resolved the issue. I spoke with Synology and there was an authentication change ever since DSM 7.2. It is not specifically related to the recently released version of HB. Going forward in order to create a Hyper Backup task you will need to open up port 5001 for the authentication. They have separated the authentication and the actual HB port from each other. When you create a task you will use the HB port (or if you have a custom port). After clicking log in, it will attempt the authentication on the backend using port 5001. This includes having to do a HB restore as well. Once connected a message may pop up about security certificate, you'll want to choose "NO" then you'll be prompted for credentials.

I had voiced my opinion of the security risks of opening port 5001 in which I'd prefer to use some sort of custom port for the authentication. The other issue I see with this is that you will need access to the offsite router in order to add/temporarily open the 5001 port in order to create the task or restore. Some prefer not to open router management up to the internet, and therefore this will require a possible onsite visit just to open the port and then close it again.

 

[Telos]

it will attempt the authentication on the backend using port 5001

So? Even if you have changed your default HTTPS port from 5001 to 9876, HB authentication is hard-coded to 5001? ... or the HTTPS port?

 

[Gerard]

So? Even if you have changed your default HTTPS port from 5001 to 9876, HB authentication is hard-coded to 5001? ... or the HTTPS port?

Correct, the HB authentication takes place over 5001 (at least for me could be possibility its also 5000) regardless of any other settings/custom ports you've done. Currently there is no way to change the authentication connection port. This includes if you're running Synology's reverse proxy.

They stated they did this change as an additional security measure, separating the authentication communication from the HB port.

 

[Ames]

So? Even if you have changed your default HTTPS port from 5001 to 9876, HB authentication is hard-coded to 5001? ... or the HTTPS port?

This was my question. I was trying the DSM to DSM full backup and the auth portion correctly used my remote DSM's alternate port, but then after entering the password it was like nothing happened.

 

[Gerard]

used my remote DSM's alternate port,

What is a "DSM's alternate port"? Not quite sure what this means. Are you referring to custom port forwarding? Or HTTP automatically using HTTPS?

If you are accessing DSM using their default ports of 5000/5001 and have these ports opened/port forwarded, then you will not see the problem. The problem is if you have custom ports opened for DSM remote access, which is then forwarded to ports 5000/5001 or if you have a reverse proxy setup using 443 you will have the problem since the actual ports of 5000/5001 are not opened as the source ports on the router. Which is bad security practice to begin with.

 

[Ames]

What's DSM's alternate port? If you are accessing DSM using their default ports of 5000/5001 and have these ports opened/port forwarded, then you will not see the problem. The problem is if you have custom ports opened for DSM remote access, which is then forwarded to ports 5000/5001 or if you have a reverse proxy setup using 443 you will have the problem since the actual ports of 5000/5001 are not opened as the source ports on the router. Which is bad security practice to begin with.

I've changed DSM admin to be on another port. In DSM I changed it. So remotely through the firewall 5001 isn't open. The other port is.

In Hyperbackup I can connect to the remote DSM. It pops up login screens. The login screens work. Then Hyperbackup stalls. So Hyperbackup definitely knows and uses my authentication port even with 5001 completely closed.

I'll try opening 5001 forwarding to 5001 and then if that doesn't work 5001 on firewall forwarding to my real DSM port.

 

[Gerard]

In Hyperbackup I can connect to the remote DSM. It pops up login screens. The login screens work. Then Hyperbackup stalls. So Hyperbackup definitely knows and uses my authentication port even with 5001 completely closed.

What is your DSM version?

Maybe this is only a issue for Reverse Proxy users then..

 

[Ames]

What is your DSM version?

Maybe this is only a issue for Reverse Proxy users then..

7.2 update 3.

 

[Gerard]

7.2 update 3.

OK, so it seems that you're using custom port forwarding.

For me I am using reverse proxy. Although Hyper Backup doesn't apply to reverse proxy. For Hyper Backup I have a custom port which is then forwarded to HB 6281. With regard to how I connect to DSM, I use reverse proxy so port 443 is opened, and then at the RP it resolves to dsm's 5001.

 

[Gerard]

@ames

No. We have only changed the NAS default HTTPS port to something other than 5001... for example, 9876. Doing so, we connect to the NAS DSM log in screen externally by forwarding 9876 to 9876, instead of 5001 to 5001.

https://secret/synology.me:9876 > router > 192.168.1.11:9876 > DSM Login GUI

OK so in this case there are no issue with creating and authenticating with a new HB task, or connecting to do a restore?

 

[Telos]

in this case there are no issue with creating and authenticating with a new HB task, or connecting to do a restore

Does HB authentication follow the HTTPS port, or is it hard-coded to 5001.

the HB authentication takes place over 5001 (at least for me could be possibility its also 5000) regardless of any other settings/custom ports you've done

This suggests that 5001 is basically hard-coded, and does not respect the assigned NAS HTTPS port.

 

[Gerard]

That was the question asked above. Does HB authentication follow the HTTPS port, or is it hard-coded to 5001. Then you posted

According to the phone call I had with Synology, that rep stated the authentication takes place on port 5000/5001. Once I opened up port 5001 (only) I had no issue with creating the task. They have reached out to the Taiwan Development team for more information.

Maybe the reason it is not working for me is due to using reverse proxy and authentication fails somewhere thru that route, whereas if you define different dsm ports the authentication flows seamlessly as Ames seems to be able to get the login prompt; Although not a full successful login.

 

[Gerard]

Are you using 5001 as your DSM HTTPS port (if you are, that is less than ideal)?

The only port opened at my router for DSM is 443. I then have a custom port 7777 forwarded to 6281 on my router for Hyper Backup.

-- post merged: 16. Aug 2023 --

From Synology Support:

I was performing some testing here in our lab, and what I learned is that Hyper Backup will use the default port 5001, however if you change the port in Control Panel > Login Access to something other than the default, the Hyper Backup will follow that modified port.

However, I am not sure how this is affected when using a reverse proxy.

I have asked this question to our development team.

Best Regards,

| Synology Support Engineer

 

[Gerard]

That didn't answer my question, so I'm stopping here. Thanks for your input.

question was answered numerous times no I’m not using 5000 & 5001 externally.

 

[Gerard]

I asked if 5001 was your DSM HTTPS port, not what port you use externally.

Only communication debacle is on your side:

I've answered this by showing you a screenshot of that settings page in this post here (to help you along look at the 2 screenshots in this post.)

And I've also stated it in this post here

 

[Rusty]

Does HB authentication follow the HTTPS port, or is it hard-coded to 5001.

It does follow. I have it with multiple remote locations connecting to me for HB backup.

Via unique reverse they authenticate against my DSM and their account, and then the backup runs via 6281 default port (that can be ofc forwarded) or any other that is configured to make the actual backup.

I have no 5001/5000 ports open or in use.

 

[Telos]

It does follow.

Thank you!

 

[Rusty]

I owe @Gerard an apology as my last comment is indeed correct but only on an older version of HB. I joined late in this thread and completely misread the topic that clearly states that the DSM 7.2/HB 4.1 are in question.

I can confirm that this version atm is indeed not following the reverse proxy settings and does rely on the DSM default (or changed ports).

I have opened a ticket with Syno to confirm and request a change.

 

[Gerard]

I owe @Gerard an apology as my last comment is indeed correct but only on an older version of HB. I joined late in this thread and completely misread the topic that clearly states that the DSM 7.2/HB 4.1 are in question.

I can confirm that this version atm is indeed not following the reverse proxy settings and does rely on the DSM default (or changed ports).

I have opened a ticket with Syno to confirm and request a change.

I’ve responded to the synology ticket stating in no way shape or form will I open 5000/5001 to make this work, when I’m using 443 Reverse Proxy. The whole purpose of using RP 443 is to avoid opening more ports than I have to. They’ve responded they will take back to development team to see if they can allow authentication to happen over 443.

Long shot, but to me that’s the best way. I appreciate opening a ticket as well, should you need my ticket number or vice verses to link them together. Idk if that makes the case stronger, to me it’s a pro for those with RP setups and much more secure than opening additional ports.