OpenWrt firewall mystery

[lleachii]

@wangnick

and that IP packets addressed to an IP address of "the router" even when those IP addresses are in a different zone are handled by the firewall via the INPUT rule not the "FORWARDING" rules.

Although, I'm still not sure why you logically consider and separate this differently...it's not like the machine magically becomes a different machine because it has another IP. I can only imagine that you're trying to isolate a service on the router from the private VLAN - other than the web GUI... otherwise, I don't understand the effort; but yes, @trendy's rule will work to only allow access to the preferred DST IP. Please note, some users have subsequently locked themselves out of configuring their router by adding such rules.

I will admit the INPUT thing somewhat baffled me when I first learned iptables.

@wangnick

For every zone that should be allowed to access router services:

The web GUI is not the only service needed for a LAN usually (i.e. DHCP, DNS, NTP).

[trendy]

@wangnick

What I understand is that the firewall treats IP packets from a given zone addressed to "the router" via the zones INPUT rule, IP packets addressed to another LAN within the same zone via the zones FORWARD rule, and IP packets addressed to another zone via the zones "FORWARDING" rules; and that IP packets addressed to an IP address of "the router" even when those IP addresses are in a different zone are handled by the firewall via the INPUT rule not the "FORWARDING" rules.

That is correct.

@wangnick

INPUT REJECT for every zone

I wouldn't recommend it for the lan zone. You might get locked out.

@wangnick

uci set firewall.@rule[-1].src='br-guest'

This is the zone name, not the interface name. You are also not using ports or protocols, so this rule is basically reverting the drop on input policy. Yes, it will be limiting the input to just the interface IP, in case you are running multiple instances of the same server.

[lleachii]

@trendy

You are also not using ports or protocols, so this rule is basically reverting the drop on input policy.

I didn't realize the OP removed the port...and changed the zone name...good catch!

Now, this really makes me think we don't understand the OP's use case.

[vgaetera]

The paradigm you are trying to implement doesn't work well for OpenWrt.
There are protocols like DHCP which cannot work properly if you limit the destination address scope in the firewall rule and restrict everything else.
Moreover, using interface/socket binding is unreliable due to possible race conditions which procd has no means to resolve.

[wangnick]

Dear gentle people, it seems to work!

Now I can't access Luci's uhttpd from any zone but private anymore, but I can still access the mosquitto service on the router whereever mosquitto is listening on the zone's IP address of the router, plus any other service the router might offer on those IP addresses (DHCP, DNS, ...):

root@tplink1:/etc/config# lsof -ni
COMMAND     PID      USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ntpd       1502      root    3u  IPv6   1966      0t0  UDP *:ntp
uhttpd     1673      root    3u  IPv4   2272      0t0  TCP 192.168.2.1:www (LISTEN)
odhcp6c    1725      root    4u  IPv6   2379      0t0  UDP *:dhcpv6-client
dropbear   1889      root    3u  IPv4   2510      0t0  TCP 192.168.2.1:ssh (LISTEN)
dropbear  21579      root    5u  IPv4 198214      0t0  TCP 192.168.2.1:ssh->192.168.2.190:49904 (ESTABLISHED)
dropbear  21579      root    7u  IPv4 198221      0t0  TCP 127.0.0.1:6010 (LISTEN)
dropbear  21580      root    5u  IPv4 198218      0t0  TCP 192.168.2.1:ssh->192.168.2.190:49905 (ESTABLISHED)
dnsmasq   24781   dnsmasq    4u  IPv4 216070      0t0  UDP *:bootps
dnsmasq   24781   dnsmasq    6u  IPv4 216073      0t0  UDP *:domain
dnsmasq   24781   dnsmasq    7u  IPv4 216074      0t0  TCP *:domain (LISTEN)
dnsmasq   24781   dnsmasq    8u  IPv6 216075      0t0  UDP *:domain
dnsmasq   24781   dnsmasq    9u  IPv6 216076      0t0  TCP *:domain (LISTEN)
mosquitto 25197 mosquitto    4u  IPv4 217603      0t0  TCP 192.168.2.1:1883 (LISTEN)
mosquitto 25197 mosquitto    5u  IPv4 217604      0t0  TCP 192.168.5.1:1883 (LISTEN)
mosquitto 25197 mosquitto    6u  IPv4 217605      0t0  TCP 192.168.6.1:1883 (LISTEN)
mosquitto 25197 mosquitto    7u  IPv4 217606      0t0  TCP 192.168.7.1:1883 (LISTEN)
mosquitto 25197 mosquitto    9u  IPv4 217611      0t0  TCP 192.168.6.1:1883->192.168.6.181:60451 (ESTABLISHED)
mosquitto 25197 mosquitto   10u  IPv4 219624      0t0  TCP 192.168.7.1:1883->192.168.7.130:35718 (ESTABLISHED)
mosquitto 25197 mosquitto   11u  IPv4 217820      0t0  TCP 192.168.5.1:1883->192.168.5.200:38118 (ESTABLISHED)
nginx     25429      root    6u  IPv4 219600      0t0  TCP 192.168.2.1:1880 (LISTEN)
nginx     25429      root    7u  IPv4 219601      0t0  TCP 192.168.5.1:1880 (LISTEN)
nginx     25429      root    8u  IPv4 219602      0t0  TCP 192.168.6.1:1880 (LISTEN)
nginx     25429      root    9u  IPv4 219603      0t0  TCP 192.168.7.1:1880 (LISTEN)
nginx     25436    nobody    6u  IPv4 219600      0t0  TCP 192.168.2.1:1880 (LISTEN)
nginx     25436    nobody    7u  IPv4 219601      0t0  TCP 192.168.5.1:1880 (LISTEN)
nginx     25436    nobody    8u  IPv4 219602      0t0  TCP 192.168.6.1:1880 (LISTEN)
nginx     25436    nobody    9u  IPv4 219603      0t0  TCP 192.168.7.1:1880 (LISTEN)
dropbear  26110      root    5u  IPv4 223427      0t0  TCP 192.168.2.1:ssh->192.168.2.190:53968 (ESTABLISHED)
dropbear  26110      root    7u  IPv4 223433      0t0  TCP 127.0.0.1:6011 (LISTEN)
dropbear  26111      root    5u  IPv4 223430      0t0  TCP 192.168.2.1:ssh->192.168.2.190:53969 (ESTABLISHED)
dropbear  26395      root    5u  IPv4 224131      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54040 (ESTABLISHED)
dropbear  26395      root    7u  IPv4 224137      0t0  TCP 127.0.0.1:6012 (LISTEN)
dropbear  26396      root    5u  IPv4 224134      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54041 (ESTABLISHED)
dropbear  26427      root    5u  IPv4 224340      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54161 (ESTABLISHED)
dropbear  26427      root    7u  IPv4 224346      0t0  TCP 127.0.0.1:6013 (LISTEN)
dropbear  26428      root    5u  IPv4 224343      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54163 (ESTABLISHED)
dropbear  26450      root    5u  IPv4 224399      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54167 (ESTABLISHED)
dropbear  26450      root    7u  IPv4 224405      0t0  TCP 127.0.0.1:6014 (LISTEN)
dropbear  26451      root    5u  IPv4 224402      0t0  TCP 192.168.2.1:ssh->192.168.2.190:54168 (ESTABLISHED)

Many thanks, also for clarifying the background of all of this (at least to the depth of fw3).

Kind regards,
Sebastian

[wangnick]

@vgaetera

There are protocols like DHCP which cannot work properly if you limit the destination address scope in the firewall rule and restrict everything else.

I guess I still have to allow broadcast IP addresses to enter the router (e.g. 192.168.5.255, 255.255.255.255)?

@vgaetera

Moreover, using interface/socket binding is unreliable due to possible race conditions which procd has no means to resolve.

I don't understand. Can you clarify that?

Kind regards,
Sebastian

[vgaetera]

@wangnick

Can you clarify that?

The service may fail to start if the interface is not ready.
Restarting the interface can make the service inoperable.
Among the affected services are Dropbear, uHTTPd and others.