I've just received a Sagecom FAST5364 3.00 WiFi hub and have connected to Faster Fibre Broadband successfully.
I was previously using BT Hub 6 without any issues.
I have configured the router for UPnP IGD set to ON and have had the NAS configure the ports. However, I am unable to access the NAS via xxxx.myqnapcloud.com. This was not an issue with my previous router.
Here are the router port settings and the response from my NAS.
The firmware of the router upgraded itself overnight. Still unable to access or ping my NAS via [name].myqnapcloud.com.
I'm also unable to ping www.myqnapcloud.com. Possible Amazon AWS blocks?
@OCE_Chris has asked me to help you. There may be various reasons for this, the most obvious being NAT Loopback. If you try to access the NAS via the domain name from a device connected to your local router, your traffic is going out to the internet & back in again. It is most likely being blocked by the router on the way back in, as virtually all TalkTalk routers assume loopback traffic like this to be a security issue. If you want to access the NAS locally, just use its 192.168.1.x IP address to connect to.
Another could be UPnP itself. If the device that opens the ports does not refresh them within the lease time granted by the router (and that might be different from router to router), then the port mappings will disappear. UPnP is also very insecure & in my opinion should be disabled altogether in the router, as malware on one device could open up ports to all devices, for further cyber-attacks. For this reason, it is far more secure to use port forwarding which is statically configured.
Thank you for your reply. My ports remain open and this is primarily for me to access my NAS remotely, which I am still unable to do. It is also of interest that I am unable to get a ping response from www.myqnapcloud.com, which I can connect to otherwise from a web browser.
PING qcloud-pr-frontend-1025300009.us-east-1.elb.amazonaws.com (188.8.131.52): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
I am able to ping the NAS locally without any problems (192.168.1.xxx)
I have also attempted to connect to my NAS via [name].myqnapbloud.com from outside my home, ie. not from the same router, without success.
Is it possible that TalkTalk is blocking access to this service? It seems that the service is hosted on Amazon's AWS. I do get a ping response from amazonaws.com, so that is unlikely to be the issue.
If the ports are open, then that proves the TalkTalk network OK. It is only DNS mapping of your domain to the current WAN IP address of your router that should be the issue. Can you connect to the NAS using the WAN IP?
Perhaps I didn't respond correctly. The router's web interface shows that the ports are configured. I don't know how to confirm that these ports can be reached remotely.
I am still unable to reach my NAS remotely!
I am able to connect to the NAS via https://www.myqnapcloud.com/u#/my_device, but am unable to reach it via ahabib.myqnapcloud.com. This was possible with my previous router from BT.
I also attempted to connect from another TalkTalk customer and had the same issues of no response. The page just doesn't load. Is it possible that the router is using the port for itself and therefore not letting me access the port?
Another odd behaviour from the router is that I am no longer able to disable UPnP. The option has disappeared.
Is the IP address of the NAS statically configured on the NAS itself or is it A DHCP reserved IP address in the router? It must be one of the two, if the former, please can you get me a copy of the full networking configuration of it?
What OS is the NAS running & does it support the equivalent of the windows command prompt:-
If so please can you get me a copy of its output?
Next from a device connected to your router's local network, go to this site in the browser:-
Test each of the external ports in the router's UPnP rules that go to the NAS's IP address. They should report as open.
I've checked for open ports from https://portchecker.co. All ports reported by the router show as open except 8081 and 80, which reports closed.
I'm not sure what OS the NAS is using, but I have been able to SSH into the NAS and produce results from the command netstat -an (without the -o as this wasn't an option)
The problem with TCP 8080 & 8081 would seem to be down to the configuration of your NAS. Port 8081 is not bound to any IP address & 8080 is bound to the loopback address, not the 192.168.1.179 address of the NAS.
Thanks for your time in this matter. Any idea where I can go from here to get this issue resolved?
You need to consult the support people for the NAS.
If this were the problem with the configuration of the NAS, it would also not have worked with my previous service and router from BT. I still believe that the issue is either with the TalkTalk router and or their service. There must be a solution to this problem.
Notwithstanding Keith's assistance (for which I am very grateful), I would like someone from TalkTalk to please address this issue.
I had exactly the same problem with my 2 Qnap NAS, but with the Huawei Echolife DG8041W router. In my case some of the ports needed by the NAS are being used internally in the router - it could well be the same story with the Sagecom. Why the ports are being used internally is anyone's guess - conspiracy theories aside.
I got around this by doing some port forwarding on my router to point to the Web Servers and NAS Web Interfaces. Also had to do port translation on my DDNS providers setup to point to the forwarded http and https ports.
You may well have to run the network connectivity repair tool (myqnapcloud-overview page), rescan the for a UPnP router (Auto Router Configuration page) and even reboot the router after configuring the port forwarding / translation before it all comes together.
If you need more info.....
@ahabib, staff won't be back before Monday.
It may be difficult to find support for the problem through Chat, but worth a try. Links from here:
Every time you post on here, the workflow algorithm thinks you have received an answer. The only way to reach staff now is NOT to post until they pick up this thread to respond. That will now be next week, I am afraid.
@Piethorne Thank you for your reply.
I am in progress with QNAP support, who suggested that I change the port mapping for the NAS to a port other than 8080, which I did. It still didn't work for the NAS web interface. Oddly I can still access the NAS from the WAN IP as well as logging into www.myqnapcloud.com.
That leads me to believe that the NAS is visible remotely, but something else is blocking the NAS Web interface.
If I can get QNAP support to resolve this issue, I will report it here. Otherwise, I will just have to persist and try and get some help from TalkTalk's technical team. Being able to manage the NAS is quite important for me as I do need access when I'm away from home.
@ahabib You can still access the NAS web interface by using the SmartURL near the top of myQNAPcloud overview page. This is typically https://qlink.to/yourNASname (It's also on the myQNAPcloud Link page) I took a guess at the name of your NAS and got to the login page, where I see you've restricted anonymous access. Hopefully you've got a secure password. 😁 Just log in and pick Desktop View.
You can also change the system ports on your NAS to something other than 8080 (HTTP) (and 443 - HTTPS if needed) and port forward in the router to that port so that yourNASname.myqnapcloud.com works
i.e. in the NAS control panel under general settings change the system port from 8080 to 7080. Don't forget to click APPLY. In the router add a new forwarding (IPv4 Port Mapping) address and set the "Internal Host" to the static (it MUST be static) IP of your NAS, Protocol to TCP/UDP, Internal Port to 7080, and the Start / End External Ports to 0.
The web server is a different problem and can only be resolved by port forwarding at the router and port translation at the DDNS provider, assuming you don't have a static WAN IP address.
You may have to shut down (NOT just reboot) and restart both the NAS and router for a minute to make sure there are no rogue bytes interfering with the connection.
As you may have guessed from my other post, I been through all this a few times before. The problem is with the router commandeering the default ports, not Qnap or TalkTalk. Fortunately there are workarounds, although it is a little annoying.
If you're wondering which ports you can use see: http://www.meridianoutpost.com/resources/articles/well-known-tcpip-ports.php
(Errors and omissions excepted)
Just a word of warning / advice on the above. If the NAS system port you choose is being used elsewhere, you MAY not be able to login to the NAS after changing the system port by using the static IP of the NAS on a local computer.
The SmartURL, qlink.to/yourNASname and yourNASname.myqnapcloud.com will still work so that you can access and change the system port and try again. Patience.
And don't forget to clear all browser cookies after every change.
@Piethorne I appreciate your words of wisdom. However, having changed the access ports on the NAS as well as the router, (which is configured automatically by the NAS - no option to manually configure the ports with the latest firmware!), and having rebooted both devices, still no joy with logging on to the NAS Web or Secure NAS Web. I have even tried to reset the router to factory defaults without success.
I can certainly access the NAS via myqnapcloud.com and sign in. I can also access using the https://qlink.to/[NASName] address. However it always loads my local WAN IP and not [name].myqnapcloud.com. Thus I can access the contents on my NAS but am unable to manage it via the QTS Desktop. Without access to the QTS Desktop, I have no direct access to the apps on my NAS remotely. Not good!
I think that it is a problem with the Sagecom router. I don't understand what loopback means exactly, but that may be the problem. I will have to borrow a different router with a VDSL modem and NAS compatibility to see if that eliminates the problem. If that works, it would be a shame as the Sagecom router is very good otherwise.