How to make LUCI available through WAN?

I feel dumb, after spending 3 days configuring OpenWRT on DIR-300, quite literally, simple instructions I found on different sources including on youtube were wrong, things only started working when I asked question in this forum.

Anyway, LUCI was accessible through WAN from local network -- I WANT TO UNDERLINE, not when connected to OpenWRT router, but when on the outside, connected to the other router. But then I rebooted my main router and things stopped working, go figure. Other than can't access LUCI from WAN everything works as it should. Just a matter of convenience.

Network is like so.

DIR-300 OpenWRT version 14.x --
connected to main router via WiFi, WWAN interface is
Main router is Keenetic II at

Internet is working, connecting to DIR-300 via WiFi working, internet is present, LUCI is accessible.

From main network, 172.16.0.xx accessing host is unreachable.

I did configure firewall, but mind you, it used to work before that without firewall. Anyway, perhaps I configured it wrong, but I tried different configurations, it's not working.

It's not clear exactly what you want to do/know... but it seems that you are trying to open the OpenWrt LuCI web interface to the WAN?? is that your goal?

To be clear, this is a very bad idea because the web interface is not hardened against the attacks that would be expected from the internet.

You should use a VPN if you need access to the router... there are plenty of ways to do this, Wireguard is easy to configure for this purpose. This will provide proper security and will not expose an interface that is easily abused to the internet.

Now, as far as your rules are concerned -- port 80 and 443 are the web ports... 443 is https (secure). So if you really must expose the web interface, at least use the secure option. You should not expose any other ports (such as ssh on port 22) unless you have a need to do so. Again, VPN is a much safer way to approach this.

Finally, you are using port forwarding rules -- this is not the preferred method for opening ports. Standard traffic rules would be the better method, but again, this is not a smart thing to do -- your router (and thus your network) is at risk when you do this. Please use a VPN.


How to open LUCI web interface to WAN?

By opening the respective ports on the WAN interface (not forward rules to LAN).
But as already was mentioned this is suicide (maybe not for you but your router).

1 Like

I did and it didn't work. Then time went by, perhaps 2 hours, and it started working. Go figure. I'm having to dance around this DIR-300 router. It's 4/32. Gonna install more RAM and bigger flash into it, perhaps some day.


I don't know why you guys telling me NOT to open LUCI to WWAN.

My WWAN connects to my local network and my local network is behind firewall.

1 Like

This is not so easy to do unless you are good at soldering surface mount devices, have low level programming tools (i.e. directly program the flash chip), and know how to modify and build OpenWrt (from source code) to inform the system of the increased available resources.

Because LuCI is not hardened for exposure to the internet. It is always recommended to keep this closed when connected to the internet.

But... this changes the equation. In this case, as long as the upstream network is fully trusted (i.e. your LAN for this situation), it is fine to open the router to the WAN interface. In fact, if it is indeed a completely trusted environment, you could even open all access by simply setting the input rule on the wan zone to accept (obvious disclaimer: DO NOT do this if the upstream network is not trusted such as a direct connection to the internet).

1 Like

Odd...your rules already seem correct, as long as your LAN IP for the router is

I also can't determine firewall zone by color from your screenshot.

If wwan is in your private network then put that interface in the same lan zone.

If there are devices behind a NAT masquerading layer, the wwan cannot be moved to the same zone as the lan. However, if the main router has a static route and NAT masquerading is not needed, this can be done without issue.

input != forward

config rule
  option src wan
  option proto tcp
  option dest_port 80
  option target ACCEPT

1 Like

But the masking is in the "wan" zone. If you assign the "wwan" interface to the "lan" zone, it can be accessed from the upstream network.

Are you talking about masquerading? or firewall blocking?

It seems that this is your goal, at least for the LuCI web interface. And this is generally okay because your upstream network is trusted. Unless you have something else in mind. You haven't really indicated what your goals are (other than exposing LuCI to your WAN/upstream network).

You have several options (expose = expose to the WAN/upstream network):

  • expose LuCI, and only LuCI --> create a firewall traffic rule to accept the traffic.
  • expose the router itself (LuCI + ssh + any other services running on the router itself) --> set the wan zone in the firewall to input = accept
  • expose the entire downstream network to the upstream --> several ways to do this, but it requires a static route on your main router. You can put the wwan into the lan zone, or you can turn off masquerading on the wan zone and then allow forwarding from wan > lan.

Don't forget that you can also create granular firewall rules, so these are not 'all or nothing' -- it's just a matter of defining your goals.

Would ssh tunnelling be a suitable VPN-based technique?

I can't access Luci from WAN.
This is my config

isp/lan ( -- PC2 (
PC1 ( -----+

I can access Luci from PC2 using
I can not acess Luci from PC1 using (browser say connection timeout)

My config is

What am I missing ?

Is LuCI listening on all interfaces?

netstat -nltp | grep httpd$
1 Like

It is configured for and and redirect to https is active

But the certs are not there so the 443 was not listening.
I removed the 443 and the redirect from the config and now Luci connect correctly from WAN.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.