Accessing LuCI webUI via another router

Hi,
before I describe my network setup I start with my question:
How can I access LuCI webUI via another router?

Setup:

  • ISP router (AVM Fritz!Box) with bridge mode (on LAN port 3)
  • OpenWrt router (MikroTik RB760iGS) with 5x 1GB ethernet ports running latest release 23.05.3
  • WAN port is connected to ISP router's ethernet port 3 with DHCP setting
  • Eth1 is configured with static IP 192.168.1.10 as network LAN
  • Eth2 is configured with static IP 192.168.178.4 as network IoT and connected to ISP router's ethernet port 2
  • Static route in ISP router from IP 192.168.178.4 to subnet 192.168.1.0/24.

OpenWrt router gets a public IP on WAN port and I can access it (LuCI and SSH) from a device connected to Eth1.

Now I want to access OpenWrt (LuCI and SSH) from a specific wifi device in subnet 192.168.178.0/24.

What else must be configured in order to activate this access?

THX

This can be achieved with a firewall rule to allow destination ports tcp 22,80, 443 from wan zone and source 192.168.178.0/24 source IP.

2 Likes

I understand that creating firewall rules for tcp 22,80,443.
But why from WAN zone???

WAN is connected to public internet.

Isn’t the 192.168.178.0/24 network upstream of the OpenWrt router? Specifically, it would be on th wan port, right?

The firewall rule @trendy proposed would allow only traffic from that subnet, so it is not open to the internet at large.

1 Like
  • WAN port = eth0 is connected to ISP router's eth port 3 with DHCP setting
  • LAN port = eth1 is configured with static IP 192.168.1.10
  • IoT port = eth2 is configured with static IP 192.168.178.4 and connected to ISP router's eth port 2

Please run the following commands (copy-paste the whole block) and paste the output 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; \
uci export network; \
uci export dhcp; uci export firewall; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru

You can access your router Luci UI from anywhere in the world through web by installing tailscale. Try it out.

Search for tailscale in this site itself and you will get full solution.

I have managed to access LuCI w/o any firewall rules.
Imo the static route in ISP router is sufficient to get access to OpenWrt router if it's set correctly.
network: 192.168.1.0/24
ip: 192.168.178.4

This may indicate an incorrect (and possibly dangerous) firewall configuration.

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
root@eddie:~# ubus call system board                           
{                                                              
        "kernel": "5.15.150",                                  
        "hostname": "eddie.example.com",         
        "system": "MediaTek MT7621 ver:1 eco:3",               
        "model": "MikroTik RouterBOARD 760iGS",                
        "board_name": "mikrotik,routerboard-760igs",                                                                          
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.3",
                "revision": "r23809-234f1a2efa",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05.3 r23809-234f1a2efa"
        }
}

root@eddie:~# 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 packet_steering '1'
        option ula_prefix 'fd53:xxxx:xxxx::/48'

config device
        option name 'wan'
        option macaddr '08:55:31:xx:xx:xx'

config device
        option name 'lan2'
        option macaddr '08:55:31:xx:xx:xx'

config device
        option name 'lan3'
        option macaddr '08:55:31:xx:xx:xx'

config device
        option name 'lan4'
        option macaddr '08:55:31:xx:xx:xx'

config device
        option name 'lan5'
        option macaddr '08:55:31:xx:xx:xx'

config device                                                                                                        
        option name 'sfp'
        option macaddr '08:55:31:xx:xx:xx'

config interface 'wan'         
        option proto 'dhcp'
        option device 'wan'
        option metric '100'
        option hostname '*'

config interface 'wan6'
        option proto 'dhcpv6'
        option device 'wan'
        option reqaddress 'try' 
        option reqprefix 'auto' 

config interface 'lan'                                                                                                 
        option proto 'static'
        option device 'lan2'
        option ipaddr '192.168.1.10'
        option netmask '255.255.255.0'

config interface 'iot'
        option proto 'static'
        option device 'lan3'
        option ipaddr '192.168.178.4'
        option netmask '255.255.255.0'

root@eddie:~# cat /etc/config/firewall                                                                      
config defaults                                                
        option input 'ACCEPT'                                  
        option output 'ACCEPT'                                 
        option forward 'REJECT'                                
        option synflood_protect '1'                            
                                                               
config include                                                 
        option path '/etc/firewall.user'                       
        option fw4_compatible '1'                              
        option reload '1'                                      
                                                               
config zone                                                    
        option name 'lan'                                      
        option log '0'                                         
        option input 'ACCEPT'                                  
        option output 'ACCEPT'                                 
        option forward 'ACCEPT'                                
        list network 'lan'                       

config zone
        option name 'iot'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT' 
        list network 'iot'

config zone
        option name 'wan'
        option log '1'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT' 
        list network 'wan'
        list network 'wan6'

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

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

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

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

config rule
        option name 'Allow-MLD' 
        option proto 'icmp'
        option src 'wan'
        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 proto 'icmp'
        option src 'wan'
        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'

onfig rule           
        option name 'Allow-ICMPv6-Forward'
        option proto 'icmp'
        option src 'wan'
        option dest '*'
        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 proto 'esp'
        option src 'wan'
        option dest 'lan'
        option target 'ACCEPT'

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

config rule             
        option name 'LAN: Allow any network'
        list proto 'all'
        option src 'lan'
        option dest '*'
        option target 'ACCEPT'

config rule     
        option name 'IoT: Allow DHCP client'
        option proto 'udp'
        option src 'iot'
        option dest_port '67-68'
        option target 'ACCEPT'

config rule
        option name 'IoT: Allow DHCP server'
        option proto 'udp'
        option dest 'iot'
        option dest_port '67-68'
        option target 'ACCEPT'

config rule
        option name 'IoT: Allow DHCPv6 client'
        option proto 'udp'
        option src 'iot'
        option dest_port '546-547'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'IoT: Allow DHCPv6 server'
        option proto 'udp'
        option dest 'iot'
        option dest_port '546-547'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'IoT: Allow DNS primary router'
        list proto 'tcp'
        list proto 'udp'
        option src 'iot'
        option dest_port '53'
        option target 'ACCEPT'

config rule
        option name 'IoT: Block DNS other networks'
        list proto 'tcp'
        list proto 'udp'
        option src 'iot'
        option dest '*'
        option dest_port '53'
        option target 'REJECT'

config rule
        option name 'IoT: Block all'
        list proto 'all'
        option src 'iot'
        option dest '*'
        option target 'REJECT'

config forwarding
        option src 'proxy'
        option dest 'iot'

config forwarding
        option src 'proxy'
        option dest 'server'

The default input policy should be REJECT:

I also see a few duplicated and several unnecessary/unconventional rules and some that are probably vestiges of other things you had done in the past that don't apply now.

One thing that is strange, though, is that the iot network appears to be on the same subnet as your upstream device's management... that's generally not what I'd recommend... can you should a topology diagram of how things are physically connected (be sure to include device names and IP addresses, and of course port numbers, too, in the diagram).

Blue router (= ISP router):

  • public IPv4 + IPv6 on WAN
  • LAN on eth1, eth2: 192.168.178.0/24
  • bridge mode on eth3
  • guest mode on eth4

Green router (= OpenWrt router):

  • public IPv4 + IPv6 on WAN via DHCP
  • LAN on eth1: 192.168.1.10/24
  • IoT on eth2: 192.168.178.4/24

Bridge mode on ISP router is not the same as bridge mode on OpenWrt router.
Bridge mode on ISP router means any device connected to this port is getting a public IP using modem of ISP router. In my setup green router WAN port is (directly) connected to www.
In other words, any router has a dedicated public IP.

ok... that wasn't clear from your earlier description. This seems fine. And no, you should not need any new firewall rules, and certainly not anything to allow access via the wan zone.

Actually I'm confident that my setup and wiring is correct.
However I want to enhance OpenWrt setup to restrict access to LuCI and SSH.
Therefore I created this firewall rules:

config rule                                         
        option name 'IoT: Allow SSH primary router'
        list proto 'tcp'                                       
        option src 'iot'
        option dest_port '22'
        option target 'ACCEPT'
        list src_mac 'f0:de:xx:xx:xx:xx'
        list src_mac '58:94:xx:xx:xx:xx'

config rule
        option name 'IoT: Allow HTTP primary router'
        list proto 'tcp'
        option src 'iot'
        option dest_port '80'
        option target 'ACCEPT'
        list src_mac 'f0:de:xx:xx:xx:xx'
        list src_mac '58:94:xx:xx:xx:xx'
                               
config rule
        option name 'IoT: Allow HTTPS primary router'
        list proto 'tcp'  
        option src 'iot'    
        option dest_port '443'
        option target 'ACCEPT'
        list src_mac 'f0:de:xx:xx:xx:xx'
        list src_mac '58:94:xx:xx:xx:xx'

config rule
        option name 'IoT: Block all'
        list proto 'all'
        option src 'iot'
        option dest '*'
        option target 'REJECT'

But these rules don't result in access restriction, means I can still access OpenWrt from any client in 192.168.178.0/24 after disabling SSH, HTTP, HTTPS rule.

uhttpd is listening on

config uhttpd 'main'
        list listen_http '192.168.1.10:80'
        list listen_https '192.168.1.10:443'
[...]

From where (what network and/or IP addressses) do you want to:

  • be able to access the OpenWrt admin (LuCI/ssh)
  • not be able to access the OpenWrt admin?

This doesn't work the way you think it does... it's different than the firewall. This specifies the addresses upon which it is listening and will respond (i.e. will you respond when someone calls you "Tim", "Timothy" or both; it doesn't affect who can talk to you)

I'm aware of the uhttpd function.
I want LuCI to listen on this IP only. This means I currently consider LAN port as fallback solution to access the router in case something goes wrong.

My wifi devices are connected to ISP router and its WLAN, and only my personal laptop must be allowed to access OpenWrt when connected to this WLAN.
Currently there's only this WLAN.

My static route configured in ISP router allows traffic from WLAN to OpenWrt LAN.

But to be clear, this does not restrict other networks from attempting to access via that same address.

And it does not constitute a fall-back solution. The firewall is what governs access.

Typically, using 0.0.0.0 for the listen address is done such that the device will respond to any address for which it holds an address, and the firewall is then configured to allow or deny a given network from accessing the device.

For example, if I have 2 networks on the router where the addresses (held by the network interface on the router itself) are 192.168.1.1 and 10.0.0.1, I could ssh to either of those addresses from either network and I would gain access to the router. But, if 10.0.0.0/24 is my guest or iot network, I would set the input policy on the firewall zone to REJECT such that the 10.0.0.0/24 network would be unable to reach the router at either address. The trusted lan at 192.168.1.0/24 could use either address, just the same.

In that case, the easiest solution is to set the input policy of the OpenWrt lan firewall zone to 'REJECT.` Once this is done, you usually need to create rule(s) to allow DHCP and DNS so that hosts behind the router on the affected networks can still get connectivity.

All of that said, maybe it's worth stepping back and talking about the purpose of the OpenWrt router in your network...

  • It seems that the upstream network is trusted -- can you confirm that?
  • What sits behind the OpenWrt router and what is the purpose of it being on a separate network (i.e. guest/iot, or some other reason) as compared to having everything on the same network?
  • what allow and/or restrict policies do you wish to have:
    • to the router itself from each network?
    • from the upstream network to the downstream?
    • from downstream to upstream?
    • from downstream to the internet?
    • any others?

Many thanks for your valuable input and time spending on this topic.

Here's my intention for this network setup:

  • I want ISP router's LAN and WLAN to be used by critical devices, e.g. edge, mobile, SmartTV, etc.
    I classify this subnet as "IoT".
    IoT devices get access to internet, but this must be restricted to prevent IoT devices "talking to China".
    IoT devices must have no access to any other subnet.
  • I want OpenWrt router offering different subnets, e.g. office, server, proxy, dmz.
    This requires firewall rules that must be defined carefully and VLANs.
    Devices connected to these subnets store private data that must be protected.
  • Any router has dedicated public IP.
    Hereby I can separate downstream/upstream for different subnets.
    In addition dedicated VPN access to each router (using wireguard) is available.

At the bottom line I want to separate network IoT either logically and physically from any other network (with devices storing critcal data).

You would have to do that entirely inside the ISP router, since the IOTs are connected to its LAN and using its wan for the Internet.

Generally ISP routers should be used only as a link to the Internet and placed outside the OpenWrt firewall. This is done by having a wan port of OpenWrt being the only customer-side connection to the ISP device. Do not connect any endpoints to the ISP router lan ports, and turn off its wifi.

Configuring a service to listen on only one interface is rarely done on Linux, for the reason that it actually doesn't have any security. If you have two interfaces 192.168.1.1/24 and 192.168.5.1/24, and uhttpd is supposed to listen only to 192.168.5.1, without a firewall active, any user of the 192.168.1.1 network could reach Luci simply by using 192.168.5.1 as the destination IP. Properly configuring the firewall prevents this though. Once the firewall is in place, it is no problem if uhttpd is listening to all interfaces, as the ones that are supposed to be blocked will be blocked.

1 Like

As @mk24 already described, everything should be behind the OpenWrt router and nothing should be connected to the ISP router (except the OpenWrt router, of course). The approach you are currently taking is currently limited in its ability to properly handle the specific requirements you have laid out.

Further, it seems like much of your current implementation is directly at odds with your goals. For example, you said that the stuff connected to the ISP router is considered IoT/untrusted; yet you wanted to only allow access to the OpenWrt ssh/LuCI interfaces from the untrusted network. That is counter to what would be recommended.

Instead, you should be creating multiple networks on your OpenWrt router and using the firewall to enforce the appropriate access policies. I'd recommend that you reset your OpenWrt router to defaults and start over. You can easily create one or more untrusted networks using the guest wifi tutorial. This takes you through the process of creating wifi only networks, but you can easily extend this to ethernet if you require wired connectivity on your untrusted networks. And the firewall rules that are created as part of the tutorial will isolate the guest network(s), but you can also very easily create different policies to allow uni- or bi-directional access between networks and/or whatever specific firewall rules you wish (with broad and/or fine grained controls).

1 Like