OpenWrt firewall mystery

No, that's your case exactly:

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.

2 Likes

Hi vgaetera,

thanks a lot for your swift answer.

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?

Kind regards,
Sebastian

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 ...

Gee, as I said, that's shocking ...

Kind regards,
Sebastian

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.

1 Like

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.

2 Likes

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?

Kind regards,
Sebastian

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.

3 Likes

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...

Yeah, that's what I learned today. If I configure e.g. mosquitto like:

listener 1883 192.168.2.1
listener 1883 192.168.5.1
listener 1883 192.168.6.1
listener 1883 192.168.7.1

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?

Kind regards,
Sebastian

You have INPUT on the private network set to ACCEPT.

Because it's INPUT, not FORWARD. You even linked where I note this:

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.

3 Likes

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.

???

:confused:

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 ...

Kind regards,
Sebastian

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).

But if I read your question correctly...you simply make that zone's INPUT rule ACCEPT...so I must be confused regarding your question.

1 Like

Something like this:

uci add firewall rule
uci set firewall.@rule[-1].dest_port='80'
uci set firewall.@rule[-1].src='guest'
uci set firewall.@rule[-1].name='test http'
uci set firewall.@rule[-1].family='ipv4'
uci add_list firewall.@rule[-1].dest_ip='172.17.17.1'
uci set firewall.@rule[-1].target='ACCEPT'
uci add_list firewall.@rule[-1].proto='tcp'
uci commit firewall
service firewall restart
3 Likes

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:

  1. INPUT REJECT for every zone

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

Kind regards,
Sebastian

:+1:

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).

3 Likes

That is correct.

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.

2 Likes

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.