Interfaces in Multiple Zones Firewall Behavior

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi! New to OpenWRT and taking some time to understand the Zone firewall model, so correct me if I error as I go through this preamble to my question (it's mainly about single interface in multiple zones).

Say i create these zones:

  • lan: internal networks that can speak to each other.
  • wan: the WAN interface(s) and networks.
  • int: a "category" zone of devices that can access wan.

And by default i believe there is always "any" zone, defined by the "General Settings", that catches any traffic not matching any of the previous zone or traffic rules. Note "ifwd" means intra-zone forward.

The zone table I created thus looks like this:

+---------------+------+------+------+
|          fwd  | in   | out  | ifwd |
+---------------+------+------+------+
| lan  =>  None | ACPT | ACPT | ACPT |
+---------------+------+------+------+
| wan  =>  None | DROP | ACPT | DROP |
+---------------+------+------+------+
| int  =>  wan  | DROP | DROP | DROP |
+---------------+------+------+------+
| any      DROP | DROP | ACPT | N/A  |
+---------------+------+------+------+

From what I can see, this works for me, and I can put an interface in both zones lan and int, to selectively allow them internal and external access.

From what I understand, if an interface in zone lan is sending traffic to wan, and lan does not have a forward to wan, the traffic doesn't immediately drop as the dashed box with DROP seems to indicate, but in fact it goes down the table to see if it can match another forwarding, which in here if the interface is also in zone int, it does, and the traffic is allowed to wan, but if it's not in int, then it matches to the general "any" rule and is dropped.

A precaution I've taken is to set these kinds of "category" zones at the *VERY BOTTOM with DROP (or REJECT) for all in/out/ifwd rules, so as to not accidentally allow access to/from/between networks/interfaces in there that shouldn't have it, and to let the earlier "logical" zones dictate that behavior.

Now my actual question: Is this configuration supported? I'm worried if it's not intended to be done this way and update would break the logic and expose my network or take it down somehow, or worse, silently work with unintended behavior.

And maybe a little weird question that's more for me to think about, if it is supported, is it a bad idea to do this and would I foresee problems with it?

2

A network interface must be in exactly one zone (technically it can be in zero zones -- not recommended but valid; an interface cannot be in multiple zones). It is possible to assign a network to multiple zones in terms of the raw configuration, but this creates ambiguity and thus functionally a network can only be in one zone.

No, it is not supported and yes, you are correct to have concerns about the behaviors.

3

I see! Thank you very much, this answers my question.

I was able to create and run this unsupported configuration with LuCi—if it is indeed not supported, should I raise an issue that (L)UCI allows this "misconfiguration"? I've set up a Static IP backing br-lan.99 device covered by lan zone in the configuration described above, the rendered nft ruleset looks like this (I've only included relevant flow for br-lan.99 forwarding):

table inet fw4 {
	chain forward {
		type filter hook forward priority filter; policy drop;
		iifname "br-lan.99" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
		iifname "br-lan.99" jump forward_int comment "!fw4: Handle int IPv4/IPv6 forward traffic"
	}

	chain forward_lan {
		jump accept_to_lan
	}

	chain accept_to_lan {
		oifname "br-lan.99" counter packets 0 bytes 0 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
	}

	chain forward_int {
		jump accept_to_wan comment "!fw4: Accept int to wan forwarding"
		jump drop_to_int
	}

	chain drop_to_int {
		oifname "br-lan.99" counter packets 0 bytes 0 drop comment "!fw4: drop int IPv4/IPv6 traffic"
	}

	chain accept_to_wan {
		oifname "eth1" counter packets 23 bytes 1748 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
	}
}

This seems to work in configuration and in testing, but if you're saying this is unsupported then one day it could not work, and so I'll avoid doing this kind of setup.

Again, thank you for the swift answer, I'll revert to one zone for each network/interface.

4

This has come up in the forum before, although I don't know if anyone has ever actually raised a bug (via GitHub). I could see one of two reactions from the devs:

  1. Not a bug
  • LuCI (and the CLI UCI method) is designed to provide the correct general syntax, but it doesn't contain all the logical checks to ensure that your configuration is valid or that it matches a desired intent.
    • That is to say that the syntax requirements are met, but it cannot protect you against logical errors, just as "Colorless green ideas sleep furiously" is a sentence that obeys all of the English grammar rules, but has no meaning.
    • LuCI and the CLI are also not designed to protect the user from themselves. A user can make configurations that are functionally valid but really bad ideas, just like stepping on the top rung of a ladder.

or

  1. Yes, it's a bug because we can logically check for this condition.
  • the logical checks, however, would only be able to identify that a network is in multiple zones.
  • Such a condition could b flagged as an error (and it could refuse to commit the change), but it would not be able to help identify the "correct" configuration because that requires semantic understanding of the intent.

I don't actually know on which side they would land.

Yeah, even if it seems to be working now, it could surprise you later with undefined or unexpected behaviors.

Yes, that's a good idea.

The ZBF model can take a bit of time to wrap your head around, but you can think of the zone rules as the default behaviors. You can create additional rules that are as broad or as granular as needed. Those rules will be evaluated first, and then the zone rules (including the broad forwarding rules) will be applied if there isn't a match in the earlier rules.