The weak host model is just the reason behind the current implementation.
There's nothing to disable, you simply need to accept that OpenWrt firewall relies on the zone model which is based on the ingress interface, and apply the input zone policy accordingly, which is input reject for the guest zone in your case.
Create permissive traffic rules or redirects for specific protocols/ports.
You can limit rule scope to a specific destination IP if required.
I read the Host model article once more and must say that if this fits my case then I'm quite shocked.
So any multi-homed Linux system will internally forward (not route) IP packets received on any of its networks and destined to local clients that listen on some other of its connected networks to those clients?
And in my case the uhttpd on 192.168.2.1 will receive the IP packet from 192.168.5.200 that enters the router on its 192.168.5.1 gateway address, under the MAC source address of 192.168.5.200?
I understand that the firewall is not rejecting the connection from guest to the routers private side, by virtue of the guest zones input accept policy.
The firewall is then also not routing (forwarding) the connection onto the private LAN (in the sense that it creates a new frame where the routers MAC address as of the guest LAN is the source MAC), as there is no zone forwarding guest->private defined.
But the Linux IP stack (not the firewall) then nevertheless allows the guest LAN connection to arrive at the uhttpd server listening ONLY to the private LAN ...
There's no need worry too much.
Even if IP stack allows forwarding, the final decision depends on the OpenWrt firewall configuration, which is pretty secure by default.
The zone-to-zone forwardings are denied by default and should be allowed explicitly if required.
The mistake in your thinking is that IP addresses on different interfaces of the router should be treated differently on the firewall. This is not the case as all of them are considered the same and treated with the INPUT policy. Come to think about it, it doesn't make any sense to differentiate one IP from another, as they all belong to the same device. If you allow connections on one IP, there is no sense to deny on another.
This is why the guides suggest to use REJECT or DROP for the INPUT in untrusted zones, like wan or guest.
Here I beg to differ. You would often NOT want the configuration interface of a device to be available from any connected network, whilst still wanting to allow other services to be available to all connected networks.
I mean, just look at that from a distance:
root@tplink1:/etc/config# ncat -v -l 192.168.2.1 12345
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Listening on 192.168.2.1:12345
Ncat: Connection from 192.168.7.130.
Ncat: Connection from 192.168.7.130:34892.
And that with a configuration that does not allow zone forwarding from the 192.168.7 network to the 192.168.2 network.
From your explanations I understand now why this happens, and that considering the algorithm given by Thinkcat in Recommended firewall settings - #2 by lleachii, the packet from 192.168.7.130 to 192.168.2.1 does not go OUT through another interface but is rather destined as INPUT to the router. But its still not what one would expect at first glance ...
So the solution is to REJECT all INPUT to the router in all zones but the private zone in general, and then to individually ALLOW access by devices in other zones/LANs than private to exactly the IP address of the router IN THAT zone/LAN.
Can that be expressed by one simple rule per zone/LAN?
There is no such term in linux. If some vendor isolates one interface or IP to be accessed from specific interface/IPs, then this is because of firewall rules in place, not by design.
You are asking the wrong question. The right question is "Does guest zone need access to the Luci?"
Most likely not. Therefore it is advised to deny all input from guest and all other untrusted zones and open the necessary protocols, like dhcp and dns.
There is no such thing as this in Linux either. If you were accessing the device from another enumerated zone, then that zone's INPUT rule applied to the traffic, not the guest setting.
If you are saying specific IPs only...yes that's possible; but differed from your original discussion of configuring a dedicated "management port".
Although, I could be confused because I donno what the phrase "other zones/LANs than private" means, since that rule is ACCEPT already; or perhaps the OP still misunderstands the firewall's INPUT setting...it's hard to determine...
such that mosquitto does NOT listen on 192.168.4.1, then this does not prevent a device in 192.168.4 to simply access mosquitto via e.g. 192.168.2 or 192.168.5. Totally unexpected, at least for me. And many thanks for telling me about that.
Not sure I'm asking the wrong question.
Does guest zone need access to Luci? Indeed no. That's why I configured Luci to listen on 192.168.2.1 only, not knowing that that doesn't prevent access from devices in other LANs even when forwarding is not granted.
"To deny all input from guest and all other untrusted zones and open the necessary protocols, like dhcp and dns." Can that be expressed by one simple rule per zone/LAN, without listing all protocols individually? I think this is a good question. I would like to have a stable set of firewall rules even if I'm modifying the services available on the router itself.
So I'd like to express that IP traffic arriving from any LAN and destined to the router itself should be rejected if the destination IP is one of the router's IP addresses in a different LAN than from where the packet arrives (different LAN excluding broadcast addresses).
How can this be done with the smallest set of rules?
I think Imma leave this thread alone on firewall. I hope the best for correcting your firewall config. I was never taught to imagine my configs or machines to a better state - I programmed/configured them to do so.
It's not crosstalk which to me implies FORWARDing - it's INPUT (per the actual design of the networking stack). I hope you understand this. because there's more network configs "under the hood" that may throw you for a "loop" (pun intended).
I think I understand, but who knows? 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.
Would the following be sufficient:
INPUT REJECT for every zone
For every zone that should be allowed to access router services:
uci add firewall rule
uci set firewall.@rule[-1].src='br-guest'
uci set firewall.@rule[-1].name='router access from guest'
uci set firewall.@rule[-1].family='ipv4'
uci add_list firewall.@rule[-1].dest_ip='192.168.5.1'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
service firewall restart
(of course adapting src, and the dest_ip for every zone to the IP address of the router in that zone)?
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.
The web GUI is not the only service needed for a LAN usually (i.e. DHCP, DNS, NTP).
I wouldn't recommend it for the lan zone. You might get locked out.
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.