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?
You can do that, but as I told you before it is pointless.
Configure input policy DROP/REJECT, then add a rule to allow input from zone A towards the IP of the interface in zone A.
Yes, I know now. Because it's INPUT and I wrongly configured INPUT ACCEPT. And in addition because Linux has a weak host model; if it had a strong host model access would not be granted.
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.
Yes, I know that I have to configure INPUT DROP/REJECT to avoid that crosstalk, and will do that.
But how do I express that rule to nevertheless grant input from zone A towards the routers IP in zone A best? I'm not familiar with those rules at all ...
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.
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.
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, ...):
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.
