NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyDR not working to offsite location
Our client has a ReadyNAS 716 (v6.9.3) and is using ReadyDR to backup their snapshots to a ReadyNAS 516 (v6.9.3).
This has been working perfectly until their insurance company told them to move the...
Skeetboy1 wrote:
Unable to ping the router directly from anywhere.
Likely the router is configured not to respond. You could try forwarding port 443 in the remote router to the NAS, and then confirm that https://skeetboy1.changeip.com/admin connects RN516's admin page.
Skeetboy1 wrote:
Yes there is, a Sophos SG125.
What port(s) will that require opening?
It would need to allow outbound traffic to destination port 5253. But I don't know what rules changes would be needed to do that.
Skeetboy1 wrote:
Just tried an mxtoolbox port scan against the destination router, and it is not seeing 5253 as an open port.
So that of course needs to be fixed. Note that as a test you could forward 5253 to the NAS 443 port, and see if https://skeetboy1.changeip.com:5253/admin connects. That's probably faster than trying ReadyDR every time.
OK thanks StephenB.
Tried the last suggestion first (changing the names to protect the innocent!) and was able to get through to the admin screen and login after traversingthe obligatory certificate error issues!
Is it okay, at least temporariliy (whilst we resolve why the router appears to be blocking 5253) to use skeetboy1.changeip.com:5253 on the source (716) in the Remote section of the ReadyDR job?
Changing the Sophos firewall we can do.
Need to talk to the router supplier/manufacturer as to why the router is not correctly using the changeip.com ddns correctly. When we login at changeip.com, it indicates that it has had a successful request (code 200) and it is showing our physical ip and the name and details of the router making the connection. This may take a few days!
Skeetboy1 wrote:
OK thanks StephenB.
Tried the last suggestion first (changing the names to protect the innocent!) and was able to get through to the admin screen and login after traversingthe obligatory certificate error issues!
Is it okay, at least temporariliy (whilst we resolve why the router appears to be blocking 5253) to use skeetboy1.changeip.com:5253 on the source (716) in the Remote section of the ReadyDR job?
ReadyDR should already be using 5253 ( https://kb.netgear.com/31224/ReadyDR-FAQ ). So I don't think that adding :5253 will help. It looks like the port is in fact open, but that something might be blocking the traffic - that points to the firewall.
Thankyou StephenB.
We have it working. We made a suitable hole in the firewall (which correctly converted the DDNS address to the right IP Address). But this was not enough. We could not use the DDNS address in the ReadyDR job, we just kept getting the communication error messages. So we reverted to putting the Remote IP Address into the ReadyDR job.
Obviously, this is not a long term satisfactory solution, as I know that where the Remote box sits, it is on a non-static IP. I am not certain that where it is going to be moved to will be either! So at this moment in time, we'll have to change each and every DR job at change of IP, which we realistically won't know about until job failure messages appear.
How might we progress this further please?
Thinking about this further, it may be just the format of the DDNS address that was causing an issue. Because whatever we put into the Remote box was rejected, i.e. the word Host to the left just went red. There was no immediate indication of what was actually wrong.
Do you know what the exact format of the contents of that box should be?
If should just take a normal qualified domain name (obviously one that resolves to the public IP address of the remote router).
You might need to use ssh on the system that runs the backup job, and then see what the remote address resolves to (using the linux host command).
Thank you again StephenB.
I will connect again tomorrow and get a screenshot of the issue in case we are not using a FQDN and you can perhaps advise accordingly.
The second half of your post is beyond my knowledge, but I am willing to learn. I am not sure if this forum is the place to do that, but if it is, how about we create a seperate discussion to work through how you do such things?
There is another thread on ReadyDR, and Netgear is saying that port 443 also needs to be forwarded.
Skeetboy1 wrote:
The second half of your post is beyond my knowledge, but I am willing to learn. I am not sure if this forum is the place to do that, but if it is, how about we create a seperate discussion to work through how you do such things?
We can do that. This particular thing is easy to check. There are support implications to enabling ssh, so you do need to be careful on how and when you use it. The caveats are listed here: https://kb.netgear.com/30068/ReadyNAS-OS-6-SSH-access-support-and-configuration-guides
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
