I running a Synology NAS with DDNS and Quick-Connect Configured. Port forwarding has been configured and appears to be working correctly to access the Management Console on port 5001, when outside my local network. However, if attempt to connect by the FQDN or Synology Quick-Connect address inside the LAN network it is not reachable.
My configuration:
Xfinity Modem in Bridge Mode
RBR750 setup in Routing Mode
WAN port of Router is the ISP issued public IP address which does match and resolve to the DDNS entry
Gateway is a public Xfinity address
DNS Server Configuration:
75.75.75.75
75.75.76.76
Firmware version: 4.6.14.3
As noted port forwarding appears to be working correctly as the resource is available outside my local network. While on the local network I am able to access the resource using the local private IP address, but via the host name assigned in DDNS or by the Synology Quick-Connect ID.
Any thoughts or suggestions on resolving the resolution and routing of this resource?
I do have two RBS750 satellites on the mesh. I have not attempted to set up the modem in routing mode as it is an Xfinity provided router and to my knowledge and research understand Xfinity blocks local NAT loopback if serving as the router.
Ok, was wondering about the RBS as your still on older FW and newer v7 FW doesn't work with RBS350 series. The RBS750 series is good with v7 FW. Could try updating to v.21 FW and see if this changes anything.
Wondering if the ISP could block any router for NAT loopback...not sure here.
Thank you. I will try to update the FW tonight and report back.
That would be interesting if ISP would be able to block. From my experience with routing, the RBR should have identified the resolved IP address as itself and not even forwarded to the modem.
The other thing to note is that I've configured DHCP for local clients to use the RBRs LAN address as the DNS server. I may try to override and use Google or Xfinity DNS addresses just to see if it is a local name resolution issue.
The question about specific model of satellites was because Netgear created a "cheaper package" that included one RBR750 router and two RBS350 satellites. While the RBR750 now has updated firmware, the RBS350 firmware has not been updated and updating the router will make it incompatible with the satellites. Users who purchased that package have been through very unpleasant efforts to get their systems working again.
I find the documentation about Synology Quick Connect confusing. Specifically, the comment that Quick Connect "works better" if ports 5000, 5001, and 6690 are forwarded through the customer router.
What the heck? Does Quick Connect function through port forwarding or is it like so many Internet of Things connections (using an IP connection established by the Synology connecting to a Cloud service)?
Quickconnect appears to punch a whole like other IOT devices. Because Synology serves as a proxy for this service, I typically keep it turned off for security. However, I've enabled it to try to assist with troubleshooting this more general DDNS resolution and routing issue.
Sorry I omitted that I did also try to use the WAN IP:Port in the URL on the browser. I receive the same result as if I was trying to use the FQDN. On Edge I receive the following:
Hmmm… can't reach this page
xxxxx refused to connect.
ERR_CONNECTION_REFUSED
In regard to comment about DNS, I have my DHCP scope defined to include the LAN side IP address of the RBR750. In other words, I have the RBR configured to serve as the DNS for my local clients.
Would it be convenient to try this with other browsers?
"refused to connect" implies (to me) that NAT-loopback redirected the connection attempt (https to port 5001 ?) to the Synology but that the Synology rejected the connection. If NAT-loopback is not working, I would expect the error to be "IP address not found"
The port is correct as it is the same port used when accessing from outside. To make this even more confusing, I'm now not sure where to direct my attention after preforming some additional tests while connected to local LAN from different devices I am able to connect with my iPhone using Safari.
iPhone (https:\\ddns_fqdn:5001)
Safari - Site resolves and loads using the DDNS address (Regular and Private)
Thanks for taking the time to test several browsers. Is the reported error consistent across all of these tests?
It may take me some time to set up an experiment with a 750 router (to verify that NAT-loopback functions on the 750 as it does on my primary RBR50.)
When users report problems with inexpensive devices (smart switches, cameras, etc.) if they cost under $30 I purchase one from Amazon to replicate their problem personally. A Synology NAS is a bit more of an investment.
On the bright side, is it correct to assume that this is now an intellectual curiosity. i.e.
Web access from the local LAN to the LAN IP works correctly?
Internet access to the DDNS URL works correctly?
What is not working is using NAT-loopback to use the DDNS URL while connected to the local LAN?
I have lost track of whether Synology Quick Connected is working.
Web access from the local LAN to the LAN IP works correctly? Yes this works
Internet access to the DDNS URL works correctly? Yes this works
What is not working is using NAT-loopback to use the DDNS URL while connected to the local LAN? Mixed
I've now also run netcat on my mac and even though port 5001 is set up with port forwarding along with 443, 80, and 5000, it is coming up as "Connection Refused", while succeeding with port 443, 80, and 5000.
I've also run a separate port scan utility from inside my network to the DDNS address and it shows 5001 as closed but 443, 80, and 5000 are open. However, if I run that same scan from whatsmyip.com/port-scanner it shows all 4 ports as being open.
I have lost track of whether Synology Quick Connected is working.
Quickconnect is working from within the local network at this time. It is just the DDNS access that isn't working to port 5001.
As it appears general aspects of port forwarding are working and it may be somewhat a curiosity now why 5001 is being refused from most devices and browsers while the other ports are successful, my issue is still not resolved, in being able to reliably use a consistent method to access the port from mobile devices when I am on LAN and off LAN.
being able to reliably use a consistent method to access the port from mobile devices when I am on LAN and off LAN.
(sorry to remain confused.) Does access from the local LAN to the public IP address of the router (not the DDNS URL) work on port 5001? If it does, then hardcoding the public IP address would enable a consistent method until the dynamic IP address changes. In my case, the public IP remains stable for extended periods of time. If not, then this is not a workable solution.
That TP-Link article about NAT-loopback had a strange comment at the end about FTP:
This leads me to wonder if there is perhaps a conflict with port 5001. Ports 80, 443, and 5000 are doing NAT-loopback with no issues, but port 5001 is failing. Would it be possible, at least temporarily, to change the https port number on the Synology from 5001 to "something else".
@CrimpOn the public IP address elicits the same behavior as that of trying to connect via DDNS. Also I just attempted to change the port from 5001 to 5010 which produced the same results as 5001.
Connected RBR750 running firmware v7.2.6.31 to the primary Orbi network. This router is assigned 192.168.1.71 to its WAN address.
Created port forwarding rules on the RBR750
Port 5000 to LAN IP 10.0.0.2 (a Windows computer)
Port 5001 to LAN IP 10.0.0.2 (the Windows computer)
Installed Rebex (free) web server on this Windows computer. Defined the listening ports as
Port 5000 for http
Port 5001 for https
Started the web server and told Windows to allow both private and public access through the firewall.
On the primary network, opened Edge web browser to https://192.168.1.71:5001 After the usual complaints about security, the Rebex web page opened. Thus, the RBR750 forward connection from the WAN port to the internal web server.
Connected a Chromebook to the RBR750 WiFi network and opened Chrome browser to https://192.168.1.71:5001 (the WAN i.e. "public" IP of the RBR750). After the usual security complaint, the Rebex web page opened. Thus, NAT-loopback on the RBR750 sent the connection to the Rebex web server.
It would be a chore to set up a DNS entry to test this loopback issue and we've already seen that using the URL and the hardcoded IP address behave the same.
So, what is different? I am testing against a plain vanilla web server and the goal is to connect to a Synology NAS, which I do not have to experiment with.
It is beginning to appear that the only consistent method of connecting with this Synology NAS is to use Synology Quick Connect. Perhaps not the most efficient method in a network utilization sense, but consistent in both internet and LAN scenarios.
@CrimpOn thank you for all your effort in setting up the test environment to validate my configuration. This is a real curiosity and as you noted quickconnect may be the best answer.
@CrimpOn Out of curiosity, if you still have the Rebex web server enabled, will it allow you to create a second site that uses port 80 and port 443 while running the initial test site on 5000 and 5001, thus having port forwarding to 4 listening ports on the same server?
My Synology runs a number of different services with 443 and 80 supporting Web Services, while 5000 and 5001 support the management UI and a few other file, audio and surveillance services. I'm now curios if there may be something with the SSL associations between 443 and 5001.
Well, darn. This Rebex free web server goes with the last port mentioned in the configuration file. Does not appear to be capable of listening to multiple ports. I've tried listing 5001 and then 443 (it goes with 443) and 443 first then 5001 (it goes with 5001).
I'll see what other free web servers are available. (but not optimistic)
Does Synology have an active user community? While our focus is on the Netgear Orbi, Synology users may have experience with NAT-loopback with other routers.
I cannot replicate the problem on the same Orbi (RBR750) running the current firmware v7.2.6.31. NAT Loopback using the WAN IP address from a LAN connected device works correctly to both http and https web sites.
I can set up an experiment to use a URL that resolves to the same IP address, but am not convinced the results will be worth the effort. (configuring entry in a Pi-hole server. Changing a device to use the Pi-hole for DNS, etc.)
What I cannot do is capture the connection between the router and a Synology NAS.management port (5001). The Synology web servers (ports 80 and 443) are working. What is not working is the encrypted management port (5001).
But, I do not see in the conversation where that was done (or not). Did I miss it?
Would very much like to look at the data packets between the router and the Synology when a device attempts to connect to port 5001. That would be a major undertaking (sigh) involving
Starting packet capture on the debug page.
Attempting to connect. (I would do a web http (port 80), web https (port 443), and then a management connection (port 5001).
Save the packet capture.
On the computer, open the debug zip file and extract lan.pcap
Save lan.pcap somewhere. (I do not think the forum software allows binary or zip files to be attached to messages)
Send a link to this file, either on this conversation or a private message.
(sigh) This is so tedious. Posts are deleted before I get around to answering them.
I manually installed firmware v4.6.14.3 on the RBR750 and performed the NAT-loopback experiment again:
Ports 5000 and 5001 forwarded to a computer on the RBR750 LAN at 10.0.0.2
Start Rebex web server on the computer, listening to ports 5000 and 5001
Connect Chromebook to the RBR750 WiFi
Open Chrome web browser to the WAN IP of the RBR750 (192.168.1.71 with ports 5000 and 5001). Both ports forward to the web server as they did on the most recent firmware.
On a computer on the primary network, open a web server to 192.168.1.71. Both ports 5000 and 5001 connect to the web server on the computer attached to the RBR750.
Only about 20 minutes wasted. Not as much time as I spent messing up today's Sudoku in the newspaper.
My conclusion: NAT hair-pinning (loopback) behaves exactly the same way on the RBR750 using firmware v4.6.14.2 as it does using firmware v7.2.6.31
I remain convinced the issue is related to whatever Synology is doing when it connects on port 5001.
