Set access restrictions to the web interface (LuCI)

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.

Is there a better way to do this?

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:
grafik
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
1 Like
/etc/config/dropbear
option Interface 'lan'

I was thinking of the same as the SSH option interface.
It certainly sounds like you are right about the firewall.

ubus call system board
{
        "kernel": "6.6.73",
        "hostname": "RT-AC59U",
        "system": "Qualcomm Atheros QCA550X ver 1 rev 0",
        "model": "ASUS RT-AC59U",
        "board_name": "asus,rt-ac59u",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.0",
                "revision": "r28427-6df0e3d02a",
                "target": "ath79/generic",
                "description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
                "builddate": "1738624177"
        }
}
cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdd0:1c4e:1fc2::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.100'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '192.168.1.1'
        option broadcast '192.168.1.255'

config interface 'wan'
        option device 'br-lan'
        option proto 'pppoe'
        option ipv6 'auto'
        option username 'username'
        option password 'password'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'
        option auto '0'
        option reqaddress 'try'
        option reqprefix 'auto'
        option norelease '1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0t 2 3 4 5'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0t 1'
        option vid '2'
cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan6'
        list network 'wan'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'openvpn'
        option src '*'
        option dest 'wan'
        option target 'ACCEPT'
        list src_ip '10.8.0.0/24'
        list proto 'all'

config forwarding
        option dest 'lan'

config forwarding
        option src 'wan'

config forwarding
        option src 'wan'
        option dest 'lan'
cat /etc/config/uhttpd

config uhttpd 'main'
        list listen_http '192.168.1.100:80'
        list listen_http '[::]:80'
        list listen_https '192.168.1.100:443'
        list listen_https '[::]:443'
        option redirect_https '0'
        option home '/www'
        option rfc1918_filter '1'
        option max_requests '3'
        option max_connections '100'
        option cert '/etc/uhttpd.crt'
        option key '/etc/uhttpd.key'
        option cgi_prefix '/cgi-bin'
        list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
        option script_timeout '60'
        option network_timeout '30'
        option http_keepalive '20'
        option tcp_keepalive '1'
        option ubus_prefix '/ubus'

config cert 'defaults'
        option days '397'
        option key_type 'ec'
        option bits '2048'
        option ec_curve 'P-256'
        option country 'ZZ'
        option state 'Somewhere'
        option location 'Unknown'
        option commonname 'OpenWrt'

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?

Now, we can fix the listen-on addresses:

Set the 192.168.1.100 addresses back to 0.0.0.0

Restart and test again.

1 Like

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
  1. 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.
  2. 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?

Did this ever work?

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.

My strategy for securing the access to Luci and SSH.

  1. Install the kmod-dummy module
  2. Create a "Loopback" interface using dummy0 interface
  3. Bind the "Loopback" interface to a new firewall zone
  4. Bind the listeners to the "Loopback" interface
  5. Allow forwarding to Loopback zone only from other secure zones
  6. Eventually, enforce the security using firewall traffic rules (if you need to filter access by IP address)
1 Like

Any reason you decided to overcomplicate matters?

1 Like

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.

And creating additional firewall zones. And re-binding interfaces.

Simply changing 'input' from accept to reject for the relevant zone(s) achieves the same goal.

1 Like

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.

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