DISCLAIMER: I am not really experienced / familiar with firewalld, so my judgement / opinion might be biased / inaccurate.
It's actually not very difficult to allow IP forwarding between two interfaces / network, especially if you want to "statelessly" allow that bidirectionally (i.e. allowing hosts on both sides to initiate communication with a host on another side). You really just need to create a zone, add the two interfaces to the zone, and then --add-forward
the zone. (There's also --add-masquerade
btw, which you might need/want as well.)
The problem is firewalld seems super inflexible and dumb to me. As I just mentioned, there doesn't seem to be any way at all for you to just "statelessly" allow forwarding of just one direction (while the other direction is only allowed "statefully", like typical LAN-WAN case). But perhaps that isn't a corcern in your case (since both network seems more or less an internal one, judging with the IP subnet blocks that are used).
An even bigger problem is, its design doesn't allow you to further cherry-pick an interface that has been added to a zone (for forwarding) to allow inbound traffics destined for this host. You can only allow with IP (ranges) by using "rich rules".
You can't even use another source zone (which has higher precedence than interface zone) to do that. For example, if you have a source zone for 192.168.2.0/24
that allows ssh connection or so to this host, it will overrides forwarding rules that are added by the interface zone just configured. Even if you --add-forward
this zone as well, it will only allow something like "source 192.168.2.0/24 (logical AND) destination 192.168.2.0/24". If you additionally add 0.0.0.0/0
as a source to this zone, than you will be allowing ALL (from 0.0.0.0/0
to 0.0.0.0/0
) forwarding traffics.
As I said at the beginning, these might all be just misjudgement. It could be just me not knowing how to use it right. Regardless I'd rather write my own nftables ruleset anyway. I hardly see any point in using it.
In any case, here's an example zone (file) that you might want to take as a reference:
$ cat /etc/firewalld/zones/myForward.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<rule family="ipv4">
<source address="192.168.1.0/24"/>
<service name="ssh"/>
<accept/>
</rule>
<rule family="ipv4">
<source address="192.168.150.0/24"/>
<service name="dns"/>
<accept/>
</rule>
<interface name="wlan0"/>
<interface name="bridge0"/>
<forward/>
</zone>
It allows forwarding between wlan0 and bridge0 statelessly-bidirectionally, and allows ssh connection to this host from 192.168.1.0/24
(IP subnet on the wlan0
side), and allow DNS requests to this host from 192.168.150.0/24
(IP subnet on the bridge0
side).
(This is the only zone file in /etc/firewalld/zones/. I'm not using any builtin zones.)
EDIT: I've sort of found out a way to statelessly allow forward for only one direction. You can add the "WAN" interface (e.g. ens160) to the builtin public
zone. For "LAN" interfaces that you want to forward traffic from (e.g. ens244), you do NOT need to add it to the public zone. However, you CANNOT add it to ANY other zone either, since that other zone will have its own forward configuration (it does NOT matter whether you --add-forward
that zone). (You can check with nft list chain inet firewalld filter_FORWARD_ZONES
. Note the goto
s.)
net.ipv4.ip_forward
parameter has the SERVER routing towards the two subnets. This works well for any IP traffic when no firewall filtering interferes. Do you mean that forwarded traffic is treated differently (by firewalld/nftables) than inbound traffic?nftables
chains. Any help appreciated. (I didn't expect this SERVER machine to be that hard to set up.)