Router port forwarding issue: Local network requests redirect to LuCI, while external requests succeed

On the router, I have forwarded the 443 port of the web server, but
when a client makes a request to the domain from the local network, the router returns LuCI.
At the same time, when the client makes a request from the Internet, the request goes through successfully to the web server.

I have not changed any settings other than the ports.

How can I solve this problem?

2 Likes

Public IP sits on the router, so there's nothing wrong with it showing you Luci.

Have you local DNS resolve the FQDN with the local IP of the web server.
Meaning your drawing is "wrong", DNS requests from LAN clients should be sent to the router, not the ISPs DNS directly.

Thanks for the reply!

You are right, I do have a local DNS server.
But for some reason DNS server does not resolve FQDN correctly, it gives public IP instead of local IP.

it does what it's supposed to, when a DNS name is not know, locally, it sends it upstream.

have you added the FQDN as an entry to dnsmasq, mapped to the local IP ?

1 Like

Do you have to?

I'm not a networking expert, but isn't that what NAT Reflection/Hairpinning was designed for? The router sees that the connection is going to a public IP that belongs to it, maps the target port to the open ports and forwards the request directly to the device inside the network without sending the request to the WAN. Am I misunderstanding this?

I also keep a web server at home and when I make a request from the local network to my public IP I have my page open just like when I do it over the cellular network on my phone


In the access.log all requests from the LAN show up with the gateway IP (i.e. literally like NAT Hairpinning should work)

192.168.10.1 - - [28/Jan/2025:14:03:35 +0300] "GET /test-path/ HTTP/1.1" 200 10 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
192.168.10.1 - - [28/Jan/2025:14:03:49 +0300] "GET /test-path/ HTTP/1.1" 200 10 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
176.59.162.105 - - [28/Jan/2025:14:05:14 +0300] "GET /test-path/ HTTP/1.1" 200 10 "-" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Mobile Safari/537.36"

Btw, I know OP, and we have the same router models and the same port forwarding rules. The only difference is how our ISPs give us public IP addresses. My ISP requires me to enter the connection settings (IP, netmask, gateway, etc.) manually when the OP's ISP sends those settings via DHCP.

Could this be the problem? Is it possible that NAT Hairpinning in OpenWrt "doesn't understand" when public IP address is assigned by ISP via DHCP?

1 Like

Yeah, @Olejka's right. This should be done by NAT Loopback. @frollic's solution really helped me, but it was not the solution I needed. Because on my previous non-openwrt router, port forwarding worked properly.
NAT Loopback is enabled and works, but not on 443 and 80 ports.
In short, the problem was DPI bypass software that I recently installed. The solution is described in this issue on GitHub (It's in Russian).

Thanks for your help!

1 Like