Forward/NAT nftables rules

[Alexander Tumin]

Hi, I'm trying to add a rule on NAT'ed traffic to reject certain local 
IPs from being masqueraded, but I can't see how it can be done with 
nftables backend.

The problem:

(1) --add-rule seems to always operate on iptables-restore, regardless 
of what backend is being used.

(2) --add-rich-rule doesn't seem to provide a way to add rule on 
forwarded traffic.

(3) there is seem to be no option like --add-rule, but for nftables 
specifically.

Currently I had to switch to iptables backend to do:

firewall-cmd --permanent --new-ipset=nonetvm --type=hash:ip
firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.52
firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.53
firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.54
firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.55

# enp0s31f6 is the WAN interface in external zone
firewall-cmd --permanent --direct --add-rule \
   ipv4 filter FORWARD 0 -m set --match-set nonetvm src \
   -o enp0s31f6 -j REJECT

firewall-cmd --reload

Please correct me if I'm wrong somewhere or is there simply no way to do 
this with firewalld using (now default) nftables backend?

[Eric Garver]

On Sun, Nov 22, 2020 at 03:16:44PM +0300, Alexander Tumin wrote:
> Hi, I'm trying to add a rule on NAT'ed traffic to reject certain local IPs
> from being masqueraded, but I can't see how it can be done with nftables
> backend.

Even when using the nftables backend you can still reject from iptables
using --direct rules.
> The problem:
>
> (1) --add-rule seems to always operate on iptables-restore, regardless of
> what backend is being used.

Correct. Direct rules use iptables regardless of the FirewallBackend in
use. The syntax for direct rules is iptables syntax.
> (2) --add-rich-rule doesn't seem to provide a way to add rule on forwarded
> traffic.

Correct. But firewalld v0.9.0+ has native support for FORWARD and OUTPUT
filtering via policies.
Here are some blog posts that introduce the subject:

https://firewalld.org/2020/09/policy-objects-introduction

https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-traf...
> (3) there is seem to be no option like --add-rule, but for nftables
> specifically.

By design. direct rules are a hack. They are simply a bypass to do
things that firewalld doesn't natively support. Now that firewalld has
policy objects direct rules are not very useful. They will be deprecated
in the upcoming major release.
> Currently I had to switch to iptables backend to do:
>
> firewall-cmd --permanent --new-ipset=nonetvm --type=hash:ip
> firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.52
> firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.53
> firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.54
> firewall-cmd --permanent --ipset=nonetvm --add-entry=192.168.1.55
>
> # enp0s31f6 is the WAN interface in external zone
> firewall-cmd --permanent --direct --add-rule \
>   ipv4 filter FORWARD 0 -m set --match-set nonetvm src \
>   -o enp0s31f6 -j REJECT
>
> firewall-cmd --reload

This should still work with FirewallBackend=nftables.

[Alexander Tumin]

> This should still work with FirewallBackend=nftables.

The issue here that apparently prevents this from being the case is that 
ipsets seem to differ for nftables and iptables, ones being registered 
with FirewallBackend=nftables are not being visible by `ipset list` 
utility and also not found by iptables `set` module.

If to --reload after populating ipset it can be confirmed to show in 
--get-ipsets output. If then to invoke --add-policy that tries make use 
of this ipset, iptables would not see it:

Error: COMMAND_FAILED: Direct: '/usr/bin/iptables-restore -w -n' failed: 
iptables-restore v1.8.5 (legacy): Set nonetvm doesn't exist.

This doesn't happen with iptables backend -- in it's case created ipset 
is both being recognized by `set` module in --add-rule and showing in 
`ipset list`.
> Correct. But firewalld v0.9.0+ has native support for FORWARD and OUTPUT
> filtering via policies.
> Here are some blog posts that introduce the subject:
>  https://firewalld.org/2020/09/policy-objects-introduction

https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-traf...

This apparently is what I was looking for, thank you.

[Eric Garver]

On Mon, Nov 23, 2020 at 10:53:17PM +0300, Alexander Tumin wrote:
> > This should still work with FirewallBackend=nftables.
>
> The issue here that apparently prevents this from being the case is that
> ipsets seem to differ for nftables and iptables, ones being registered with
> FirewallBackend=nftables are not being visible by `ipset list` utility and
> also not found by iptables `set` module.
>
> If to --reload after populating ipset it can be confirmed to show in
> --get-ipsets output. If then to invoke --add-policy that tries make use of
> this ipset, iptables would not see it:
>
> Error: COMMAND_FAILED: Direct: '/usr/bin/iptables-restore -w -n' failed:
> iptables-restore v1.8.5 (legacy): Set nonetvm doesn't exist.
>
> This doesn't happen with iptables backend -- in it's case created ipset is
> both being recognized by `set` module in --add-rule and showing in `ipset
> list`.

What version of firewalld are you using? It works with firewalld-0.8.2-2
from RHEL-8.