Firewall: Multiple Source and Destination zones

RSHARM · August 3, 2023, 8:46am

have to create 2 rule each for LAN (Main) and Guest Network even if they do they same thing foreach zone. It would be nice to combine them into one

Multiple Destination

For example, Allow port 443 from lan to wan and vpn

lleachii · August 3, 2023, 9:22am

443/tcp from LAN to WAN is allowed by default

If wan and vpn are in the same firewall zone (i.e. wan), LAN to VPN would be allowed too
Most VPN Wikis advise adding the VPN to the wan firewall zone for this reason

If this doesn't work by default, it means you altered your firewall.

RSHARM · August 4, 2023, 6:51am

443/tcp from LAN to WAN is allowed by default

What do you mean "443/tcp from LAN to WAN is allowed by default" ?

If wan and vpn are in the same firewall zone (i.e. wan), LAN to VPN would be allowed too

Most VPN Wikis advise adding the VPN to the wan firewall zone for this reason

I don't want to combine thier zones, I use different firewall rules for vpn and wan. I use PBR.

Ramon · August 4, 2023, 7:25am

Although his specific examples are maybe not correct, i do have good examples (e.g. allow dhcp repeated 3 times in my firewall). Not a big deal, but makes it more difficult to get a good overview...

ambad4u · August 4, 2023, 9:00am

Any Typical Modem/Router have this turned on by default TCP port 80 (http) & 443 (https) [unless otherwise manually & intentionally disabled].
OR perhaps you think that port 443 is disabled by default?

BTW, many people here will have a hard time figuring out your problem.
You may need to restate your problem and what you are trying to achieve or state more examples...

lleachii · August 4, 2023, 9:29am

Is there a reason you mentioned PBR?

You mentioned combining rules into one - then later say you don't wish to combine?

I agree, it's not clear what the OP os trying to achieve.

Also allowed by default.

Ramon · August 4, 2023, 11:11am

I am obviously not going to allow access to the router from all VLANs, so input is on reject on all but 1 VLAN. But please enlighten me on how to do it?

KAD · August 4, 2023, 11:40am

I have wondered about this too. When you have multiple APs with VLANs (guest/IoT etc) you'd want to have the firewall on (not following the Wiki "dumb AP" recipe) to reject all connections to the AP itself (input) but a few: DNS, DHCP, maybe ICMP for troubleshooting.

I have something like this for each zone on the router and the ICMP one on the APs:

Is there a better way? If I did something wrong it would be convenient to change that rule for all zones at once.

Would it perhaps be a good thing to have a LuCI button that sets up the recommended settings for an "untrusted LAN"?

lleachii · August 4, 2023, 12:43pm

Really?

So you're saying all of your VLANs have input set to drop or reject?

OK, that's fine - but just know that's not the default.

Then it seems you have to make rules by exception, and hence you have to make individual rules. Seems logical. Are you suggesting some other logic here?

Sure - allow input on (which is default).

Perhaps I'm just confused. It seems all the posters are making multiple zones Drop or Reject by default, then wondering why they have to make multiple rules for all zones?

Logic seems to suggest "simply don't do that" - but when the OP said obviously they're not gong to (i.e. the default), that confused me further.

(Maybe it should be noted that the underlying system doesn't do this - so if this were to be created, there would be 1 LuCI/UCI rule with multiple underlying rules that don't match the single rule. That can cause an issue since the rules are [expected to be] processed in order - unless one doesn't care about that, which is another logical issue of not knowing what order rules exist. There's a discussion on this somewhere already.)

Ramon · August 4, 2023, 1:04pm

I have a tight security. So only 1 vlan can access the router. Then 1 vlan for high access devices like nas, 1 guest and 1 IOT. Iot gets no access to any other zone including no wan access. Guest only gets internet access. Highest level gets access to all subnets etc.
Best way to keep home secure.

So hence i have a lot of "duplicated" rules

Best regards Ramon

RSHARM · August 4, 2023, 4:27pm

Is there a reason you mentioned PBR?

I have to keep WAN and VPN separate to use PBR

I want to combine rules not zones

RSHARM · August 4, 2023, 4:55pm

Is 443TCP allowed 192.168.1.1/cgi-bin/luci/admin/network/firewall/rules?

By Default these are the only rules present

Anyways I put the rule at the end for block unless allowed

Other examples of where this can be usefull -

Block Port 22 from LAN, Guest to WAN and Router
Block Port 443 UDP from LAN/Guest to WAN

psherman · August 4, 2023, 7:41pm

It's not an explicit rule. It is implicit by the lan zone's input rule = accept. This means any host on hte lan may connect to the services running on the router itself without needing individual accept rules per port/service.

psherman · August 6, 2023, 2:48pm

Already blocked on wan by default.

Allowed by lan because it is necessary for these ports to be open in order to administer the router — not recommended to block or you will lock yourself out of the router’s admin.

Easy to block on guest and other networks. Simply put them in the same zone and set the zone input rule to drop or reject. Or create an explicit rule for those ports and specify the source zone.

You may not realize that you can put multiple networks into the same zone. A network can only be in a single zone, but many networks may be in a zone. This means that a single rule can be applied to many networks simply by using the zones wisely.

rg4github · November 22, 2023, 7:16pm

There's still a use case for which I've not been able to find a simple solution.

My router has 5 restricted-access internal networks (in addition to lan), each in their own zone with default input set to REJECT. They all need a set of common traffic rules to reach the router (DNS, DHCP, DHCPv6, ICMP, ICMPv6). At present that requires recreating those rule for each network, because I cannot select multiple source networks for the rule.

fw4 could easily generate designated nft rules for each zone (input-interface) if the configuration allowed multiple source zone entries, but at present it lacks the capability to do so.

If I drop the source zone requirement from the rule, the generated nft rules bumps to the top of the chain and grant access from wan as well, which is unwanted.

Given the existing limitation, is there a way to create a shared traffic rule that applies to multiple internal networks, short of bypassing fw4 and manually editing the nft rules?

psherman · November 22, 2023, 7:38pm

There are a few ways this can be accomplished…

As already described, removing the source zone will enable the use of a single ruleset for all of the zones. But, yes, this will also open the ruleset on the wan… so… create a specific rule that drops/rejects that same traffic from the wan zone. That should be place ahead of the rule allowing that traffic from all zones, and it will resolve the issue of opening to the wan zone.
If appropriate, you can put all networks into a single zone. As long s the forward rule is set to drop/reject, those networks will not be able to communicate with each other. this is a fully valid approach, and actually very clean if the networks have mostly similar allowances/restrictions. You can make more granular rules where the networks need to have different rules applied.

rg4github · November 22, 2023, 8:47pm

Thanks for the suggestions.

On #1: If I create a wan-zone rule to counteract the any-zone one, it gets executed after the any-zone rule (because it's inserted into the zone-specific input chain that gets called after the any-zone rules), so that does not appear to solve the issue.

On #2: I'll look into this. Although each internal network also has rules that only apply to that network, I should be able to use Match device - Inbound device - br-Network instead of selecting a source zone for those rules.

Appreciate the feedback!

psherman · November 22, 2023, 8:49pm

For 1, try putting the block/reject rule on wan at the top of the list. See if that does the trick.

For 2, I personally would use network based matching like 192.168.34.0/24 or whatever. But there are many ways to slice it. It really depends on the details of your per-network rule requirements.