I am using OpenWrt 24.10.0 r28427-6df0e3d02a / LuCI openwrt-24.10 branch 25.014.55016~7046a1c
I am trying to restrict access to the web management screen (LuCI).
I want to enable access only from the LAN side.
vi /etc/config/uhttpd
list listen_http '192.168.1.100:80'
list listen_https '192.168.1.100:443'
The following changes worked.
192.168.1.100 is OpenWRT's own default gateway.
However, when I restarted OpenWRT, I could not access the web management page (LuCI) from the LAN side either.
Because the settings in /etc/config/uhttpd had not changed,
When I run only /etc/init.d/uhttpd restart, I can access from the LAN side.
The listen-on address does not restrict which networks can access the router; it only restricts the specific addresses that it responds to. By this, I don't mean the source address (i.e. from which the requests are coming), but rather the destination address.
To make an analogy -- let's use names in place of addresses. The router's name is Richard. Valid/common nicknames would be Rich, Dick, Richie. These nicknames are, in our analogy, the other addresses that the device holds on other subnets. Without the listen address specified, you can call the router by any one of those nicknames. But we can set the listen-on address so that it only responds to Richard. However, it will still respond to requests from anyone (on any network).
The firewall is the way that you limit the networks that will be allowed to request a connection.
So, to fix this, let's see the following config files:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
cat /etc/config/uhttpd
There are some very serious issues here! I would actually suggest that you consider resetting to defaults and starting from scratch, but let's first address the most dangerous issues:
This first one is really serious -- you've opened the router's services (including web and ssh) directly to the internet.
You must immediately change the input rule to REJECT (and it is also recommended to do the same with the forward rule):
Delete this as it would theoretically allow unsolicited traffic to ingress from the internet to your lan:
And this should also be deleted:
Next, unless this device is being used as a bridged AP, the following does not make sense:
Can you explain how this router fits in with the rest of the network?
Thanks for sharing your wisdom.
I have implemented all your wisdom and everything is working fine except OpenVPN.
Configuration of RT-AC59U with original firmware
Physically connect with two LAN cables
LAN port on IPv4 over IPv6 router β WAN port on RT-AC59U
LAN port on IPv4 over IPv6 router β LAN port on RT-AC59U
IPv4 over IPv6 router:192.168.1.1/24
RT-AC59U:192.168.1.100/24
What I want to do
It is possible to connect to IPv4 over IPv6 and PPPoE v4 networks by simply switching the default gateway on the client's PC or other device.
Enables access to the home network from the outside using OpenVPN.
I could access it in the way I wanted
After changing the firmware of RT-AC59U to OpenWrt, I tried to do the same with one LAN cable as with the original firmware.
config interface 'wan'
option device 'br-lan'
option proto 'pppoe'
The action of just switching the default gateway in 1. was done by simply making a PPPoE connection from the LuCI interface to the br-lan to the wan device.
However, when I tried to configure OpenVPN access in section 2, it became difficult.
SSH was no longer accessible from the Internet with the following settings, but because LuCI was accessible.
/etc/config/dropbear
option Interface 'lan'
And I posted my question here because I changed /etc/config/uhttpd to try to stop access to LuCI and had problems.
I did some research and determined that it is impossible to run OpenVPN with a single LAN cable, is that correct?
I don't think you ever opened the port to accept the traffic. I only saw the erroneous accept rule on WAN.
Your research is incorrect.
I also noticed you didn't mention OpenVPN in your initial post. Likewise, you didn't explain how the VPN is setup and how you want it to route/function for LAN clients.
It is not working.
Corrected incorrect accept rule on WAN, so communication from Internet to OpenVPN, LuCI, and SSH was also closed.
I was trying to allow access from the Internet and then close the unnecessary ones, but it seems better to deny everything and then allow only what is necessary.
Does this mean that OpenWrt can be realized with only one LAN cable, instead of two LAN cables, as was the case with the stock firmware?
The initial post was a question about the behavior of /etc/config/uhttpd, so I didn't mention OpenVPN.
To answer the following questions, I have posted about simple switching default gateways and OpenVPN.
The fact that it is more complicated, I think, is purely subjective. The initial setup is probably more complex, but for me, it is easier to manage on a day-to-day basis. As a professional Network Engineer, I followed the access method used for managing ISP-grade routers. This is probably a professional bias, but it was the most suitable approach that came to my mind.
Consider that on my OpenWRT router there are several LAN networks and only one is considered secure for management access. Managing access to a single IP (Loopback) from any of the networks on the router feels more convenient to me. Additionally, I use the same IP to provide services to all networks (NTP, DNS, etc.), and doing that from a single IP, makes it more practical to me.
In this way, to keep the router secure, I only need to focus on securing access to a single IP that resides in a dedicated Firewall Zone. I donβt have to worry about entire subnets or zones. For me, this is a more security-oriented approach. The initial complexity is worth the benefit.
In any case, the initial complexity is reduced to simply installing a kernel module.
The purpose of a forum is to share ideas, not to find absolute solutions. Each of us has different needs and every deployment is unique.
Maybe, for your use case, my solution is overkill, but I simply wanted to share how I approached the problem. You may not like it, but maybe in the future it will be useful to someone who, due to their specific requirements, might find it a helpful idea.
Iβm certainly not trying to convince you that my solution is the best. I just said that, based on how I set up my configurations, I considered it the most secure and practical.