3

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?

2

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.

|improve this answer|||||
-1

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?
|improve this answer|||||
  • There is a jump to masquerade in the nft version (that's the rule in the postrouting chain: ip saddr 172.16.254.0/24 oifname "eth0" counter masquerade) – larsks Nov 16 '19 at 20:34
  • From what I have groked you need the word jump, to jump to another chain. E.g. jump masquerade. – ctrl-alt-delor Nov 16 '19 at 20:52
  • That's not valid nft syntax. You only use jump when sending execution to another chain. E.g., look at the rules generated by iptables-nft. – larsks Nov 17 '19 at 13:53
  • Sorry I assumed that masquerade was a chain. – ctrl-alt-delor Nov 17 '19 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.