NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RBR750 Local NAT Loopback Not Working
I am having issues with NAT Loopback not working with my RBR750 when accessing a resource on my local LAN. I've reviewed this thread (Orbi NAT Hairpinning/Loopback Not Working - NETGEAR Communities)...
What a mess! Port 443 is https, and it works. (but, not connecting to a Synology box?)
I am guessing that this network is not set up to capture packets between the RBR750 and Synology?
(my preference is to use a managed switch to mirror the device Ethernet port to a computer running Wireshark.)
Another method is to open the Orbi debug page (http://orbilogin.net/debug.htm
Scroll toward the bottom of the page.
Enable LAN/WAN Packet Capture.
Start Capture.
Perform the experiment.
Save the capture, which will store a zip file on the computer.
The zip file includes two packet captures: wan.pcap (for the WAN port) and lan.pcap (for devices wired to the LAN ports of the router).
Opening lan.pcap with an app for pcap files, such as tcpdump, libPCAP, WinPCAP, NPCAP, Zeek, Snort, Suricata, Wireshark
The point would be to verify:
- That after passing through the Orbi router, the connection is delivered to the Synology NAS on port 5001, and
- Exactly what the Synology returns that is being displayed by the router as an error message.
Did an experiment:
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.