Using custom tables in nft

I have a Fedora 31 system on which I am using iptables-nft. I need this because there is still a bunch of software that expects the legacy iptables command line tools. This means that my nftables configuration has the corresponding set of tables to match the legacy configuration:

table ip filter
table ip nat
table ip6 filter
table ip mangle
table ip6 nat
table ip6 mangle

I use a containerized VPN service that, prior to nftables, would enable masquerading on my primary ethernet interface by running something like this when the vpn comes up:

iptables -t nat -A POSTROUTING -s 172.16.254.0/24 -o eth0 -j MASQUERADE

Since upgrading to Fedora 31 and iptables-nft, this no longer works. The container (running alpine) does not have the iptables-nft compatability wrapper, but it does have the nft command itself.

I can’t use the nft cli to add rules to the existing tables, because this will break iptables-nft. But I can create new tables. I was hoping I could just apply a configuration like this:

table ip vpn {
    chain postrouting {
        type nat hook postrouting priority filter; policy accept;
        ip saddr 172.16.254.0/24 oifname "eth0" counter masquerade
    }

    chain forward {
        type filter hook forward priority filter; policy accept;
        ip saddr 172.16.254.0/24 counter accept
    }
}

…but this doesn’t appear to have any impact. By setting the chains in this table to priority 0 I was hoping they would match before the legacy nat table, but that doesn’t appear to be the case.

Is there a way to make this work?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

After some discussions on the #netfilter irc channel, it turns out that things are function “as designed”. It is not possible for one chain to provide broader access (in the form of accept rules) than that provided by a chain with a reject (or drop) rule.

An accept verdict is only valid in the chain in which it occurrs, and it does not prevent packet processing from continuing in higher priority chains.

In other words, if you have a chain like this:

table ip filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
                reject with icmp type host-prohibited
        }
}

There is no way to grant access by creating additional chains. The only way to override that reject rule is by adding additional rules in the same chain.

Method 2

This is a bit of a guess.

• There is not jump to masquerade in the nft version.
• Do you have to configure the reverse direction?

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0