NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Cannot reach WAN ports from LAN
Hi all, I have been seaching thru the forums but have not found a discussion that is exactly my issue.
I have setup an Orbi router and satellite and everything is working great...except for one teeny tiny nagging issue: I cannot reach the webserver (and other services) that I am hosting from any of the LAN machines. To be clear, the webserver is in the DMZ with internal IP - and if I use the internal IP everything works just fine. But, why wouldn't I be able to reach it from thw WAN IP as well? When I am not on my network I can access WAN IP webserver with no issue. I can even ping the WAN IP from internal, but if I try to go to a URL, nothing. 🤔
So why don't I shut up and just use the internal IP? Well, I have phone apps that use the services internally and externally. For those apps, I would just use the external WAN IP (with DDNS) which was good for where ever I was was. but now, that's not working.
router 192.168.1.1
DMZ'd webserver 192.168.1.2
internal devices 192.168.1.x
6 Replies
- It's possible that the Orbi doesn't support NAT loopback. NAT loopback is required in order to use the WAN IP from the local network.
If I am correct, then it's kinda odd, because Netgear's other routers, like the Nighthawk line do support NAT loopback. I just set up a port forward on my Orbi router, and it seems to be working OK (I'm on V2.0.0.76 firmware, FWIW). Hitting the external router interface, I can load a web page on an internal server just fine from inside the network.
My initial thought is that this is some sort of routing issue, but it's hard to say.
If you telnet into the CLI interface on the Orbi router, and run (assuming your server is running on port 80):tcpdump -i br0 port 80
... and then try to test it from your internal host, you should be able to see the traffic from client -> external NAT address, then NAT -> internal server, and the response packets should follow the same path in reverse. If you're not seeing both legs of the conection flowing in both directions, then it's most likely some sort of routing or maybe ACL issue.
Actually, I just replicated your problem. In my (working) example, I was not using a "default DMZ" (kept it disabled), but instead, added an explicit port forwarding rule to forward port 80 to the internal webserver. HOWEVER, if I remoe the port forwarding rule and enable the default DMZ (using the same internal server), then I see the same behavior as you - external hosts can hit the NAT on port 80, but an internal client canot.
The tcpdump that I mentioned before shows the connection from client -> NAT, but that's it.
IMHO, I'm not a fan of the default DMZ option. First off, it's not *really* a DMZ. For security purposes, an DMZ is normally on a seperate network than your internal LAN, so that if the server in the DMZ gets compromised, it won't jeopardize your internal hosts. I don't see that being the case here. Also, the default DMZ option seems to forward *all* ports to the internal server, rather than just the webserver port. This could inadvertently expose you to other securty issues if you aren't careful.IMHO, kill the default DMZ (I'm assuming you have it enabled) and instead, built specific port forwarding rules as-needed.
Thanks for the quick help from everyone. "NAT Loopback" was the name I was looking for, as I knew there was a name for it. Since it is just for the sake of being able to use one address that works internally and externally, I've decided to add a DNS entry that just routes to the internal address.
Funny though, the $5 Router I was using did not have this issue...but I guess this is Netgear trying to protect my network. A loopback setting would be a nice update! LOL
