Is it possible to forgo zones?

I'm trying to wrap my head around zones but I find it way too confusing to use it. So, I'm thinking if maybe I could bypass them altogether. My current firewall ruleset is mostly src-host-based two hops upstream from clients.the routers anyway plus and the whole ruleset acts on a single interface since it's upstream from the local router—, zones are too broad.

I understand the concept; I used it before on VyOS if briefly before returning to the default-deny targeted aproach. The issue my issue is about the ambiguous perspective from which things are considered. Like in VyOS, I saw the words input/in/out/output/forward/local thrown around, in addition to netfilter which is also seen in the OpenWRT docs. However, VyOS' traffic (the perpective of it) is managed like pfSense's, whereas OpenWRT's, as I understand is more akin to RouterOS/CHR and given there's some outdated info in OpenWRT's docs and references all over the place of the big recent change in OpenWRT (DSA), I'm not sure if there are misnomers in the docs.

It's a lot of trouble for something that I don't need but I caught some stray string of characters in a lost browser tab reading that "something-something should be filtered on the WAN zone" because I assume "it" doesn't have a zone pair or something. I lost the article, but I gathered from that, that unlike VyOS' use of zones, on OpenWRT they aren't optional.

Hopefully, I'm mistaken on that, could you confirm either way please?

Thanks.

By grouping networks and hosts with a similar trust or threat levels, firewall zones make it easier to understand, customize, scale, troubleshoot the configuration, and help users avoid some stupid mistakes.

Discarding firewall zones is certainly possible if you are confident in your skills, but I would not recommend that for casual users.

2 Likes

Thanks, that's a relief.

Just to be clear, subnets are grouped semantically but edge policies are still micromanaged;…

…; for instance, there are two-three servers subnets, (1) "regular" servers and management servers, directory and networks services such as DNS, DHCP, NTP, etc and (2) more end user-type app servers like BitTorrent and Nextcloud.

On the first type, mission critical I guess you could say, no server is allowed to initiate connections out, things that need Internet access such as DNS are handled through a complex multi-layer network of filtering proxies and DNS routers (a gift from encrypted DNS) and similar approaches for different services, e.g; Exchange Server has both inbound and outbound local-ish (over VPN) gateways but no direct Internet access of its own, otherwise there's no good reason why a Microsoft product should be allowed online. There's no need for security updates if the servers are offline.

On the other type of servers; BitTorrent, for instance, it is expected from a single source port from a single source address in order to bypass even the top network-wide rules such as ICMP and no connections to/from Chinese IP addresses or other places to where it would be inconceivable for users to voluntarily make such connections; servers like ADFS are on DMZs and are only allowed to connect with the specific endpoints they federate with and so on.

The less restrictive subnets can only communicate through TCP ports 80 and 443, and even that is filtered using DNS and ASN preemptive matching. There's no rules for network services because they're within network.

Sounds tedious, it kinda is, but if you don't know what a system is connecting to when you're making its rule, should you be allowing it in the first place?

Most of the time you just need to duplicate a rule and adjust slightly.

I've had a hard time finding firewalls that filter ASN-based IP ranges, and now that I know OpenWRT can do it, I was afraid I'd had to funnel or loop around traffic through the outgoing firewall. I was not looking forward to setting up VRF on OpenWRT. It took me forever to learn about the most basic settings as it is, that's a forever per function, not overall.

Thanks again, I'm now one step closer to switching over the traffic to OpenWRT, I almost can feel it. :smiley:

Keep in mind that "the firewall" in OpenWrt is just a preprocessor translating OpenWrt specific /etc/config/firewall into nftables (or on older versions, iptables) syntax.

You can always bypass it by running /etc/init.d/firewall stop (or opkg remove firewall4 / opkg remove firewall3) and loading a manual ruleset from e.g. /etc/rc.local or a custom init script.

With firewall4 you can also trim down the generated ruleset to an absolute minimum by first deleting all zones from the config and then injecting custom ruleset elements through /etc/nftables.d/ or firewall includes. See https://openwrt.org/docs/guide-user/firewall/firewall_configuration#includes_for_2203_and_later_with_fw4 for details.

1 Like

On the other hand, if you analyze the generated set of rules, firewall zones group traffic processing by its input and/or output interface into sub-chains.

It was possible to specify interfaces as extra arguments for iptables using fw3, but fw4 no longer supports extra arguments, so there's no way to specify interfaces other than using zones or writing raw nftables rules.

If your rules ignore interfaces, it makes problematic to filter traffic by its direction and creates a loophole that can be exploited by an attacker with access to the upstream gateway, as he can breach to your LAN by routing private subnets over your router.

There is a uci way to specify zones not tied to logical OpenWrt interfaces:

config zone
  option name wan
  list subnet 10.11.12.0/24
  ...

or

config zone
  option name wan
  list device 'eth0'
  ...

iptables style wildcards are still supported too (they're translated to nft regex notation on the fly):

config zone
  option name wan
  list device 'tun+'
  ...
2 Likes

Thanks guys, this is really instructional.

I was planning to deny all traffic, even outgoing from the firewall/local. I've done some tests with..

…and once I saw traffic being blocked :arrow_down:here while allowed there​:arrow_right:, blocked :arrow_lower_right: and allowed :arrow_upper_right: and so on, I got a better feel of things and I left it there to get to work on the next related item: filtering ASNs. I thought it was like a hidden function 'cause I kept following guides that seemed overlapping so I figured any of them would take me to the same result until I realized it's a hack. So, instead of following guides with code I don't fully understand, I'm writing my own. :slight_smile: I even deployed a new firewall VM (and master), the one I had had gone incompatible with some pkgs. v22.03→v23.05.0-rc3

I still will avoid zones as I don't know if they take precedence over individual rules, replace them altogether, what? Hunting for docs takes a lot of time and if I'm going to replace the firewalls/routers with OpenWRT I need to get to function parity: NAT virtual IPs, selective SNAT of internal traffic + without asymmetric routing, OSPF, IDS/IPS, VRRP, and the tunnels...which is a long way from basic filtering, where I'm at. Really long. Oh god.

Denying all traffic should afford me some security if I'm not using zones, right? I'd be selectively allowing traffic rather than selectively blocking it. It's easier when you know what you need. I think. Does not work like that in OpenWRT? I'll stop for a min to get to those links right away.

Thanks again!

You can deny all traffic in zones too - you can also selectively allow using rules after doing so.

In fact, I assumed this was how you intended to accomplish your intended goal.