nftables and iptables nat coexistence

nftables and iptables nat coexistence

[Florian Westphal]

Hi.

Couple of month ago I sent 2 RFC patches to allow using nftables and
iptables NAT at same time.

If this is unwanted (there was concern wrt. to the new hooks I had to
add for this), we should at least improve/restrict iptables and nftables
to

1. not allow load if iptable_nat when nft nat hook is active.
2. make it a requirement to register empty nat hook (required for
the reply direction).
3. Do not permit more than one nat type per family/hook.
4. we should probably also add more checks on nat priority
for nftables to reject hooks that can't work due to no-conntrack
information being available at that point.

I think not allowing nft and iptablles nat at the same time is fine
as mixing has problems on its own, especially which transformation
gets precedence, so I suspect the old RFC patches resolve one issue
and add another one :)

So, are the old RFC patches NAKed or not?  If they are, I'd first look at
#1 from the list but before I do some consensus would be welcome.

Thanks,
Florian

Re: nftables and iptables nat coexistence

[Pablo Neira Ayuso]

Hi Florian,

On Wed, Oct 18, 2017 at 03:56:50PM +0200, Florian Westphal wrote:
> Hi.
> 
> Couple of month ago I sent 2 RFC patches to allow using nftables and
> iptables NAT at same time.

Hm, I think we forgot to talk about this during the NFWS.

> If this is unwanted (there was concern wrt. to the new hooks I had to
> add for this), we should at least improve/restrict iptables and nftables
> to
> 
> 1. not allow load if iptable_nat when nft nat hook is active.

I guess this would apply the other way around.

> 2. make it a requirement to register empty nat hook (required for
> the reply direction).

I'm seeing many posts on the lack of automatic registration of the
empty NAT chain. This is a pitfall where many people are falling one
after another in migrations.  I know there's a bold sentence in the
documentation, but I think it's a sympton that we're doing something
that is unintuitive to users, and it should be a wake up call for us.
Can we just autoregister the empty nat chain using the default
priority? If an explicit chain is registered, then disable this.

Does this sound too complicated to you?

> 3. Do not permit more than one nat type per family/hook.

Yes, this makes sense to me.

> 4. we should probably also add more checks on nat priority
> for nftables to reject hooks that can't work due to no-conntrack
> information being available at that point.

Yes, this would be good too.

> I think not allowing nft and iptablles nat at the same time is fine
> as mixing has problems on its own, especially which transformation
> gets precedence, so I suspect the old RFC patches resolve one issue
> and add another one :)

My only concern is, may this cause problems when migrating from
iptables to nftables?

Re: nftables and iptables nat coexistence

[Pablo Neira Ayuso]

On Thu, Oct 19, 2017 at 12:15:29PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Oct 18, 2017 at 03:56:50PM +0200, Florian Westphal wrote:
> > 3. Do not permit more than one nat type per family/hook.
> 
> Yes, this makes sense to me.

You could add a singleton flag for chain, so we check this from the
core, just and idea.

Re: nftables and iptables nat coexistence

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi Florian,
> 
> On Wed, Oct 18, 2017 at 03:56:50PM +0200, Florian Westphal wrote:
> > Hi.
> > 
> > Couple of month ago I sent 2 RFC patches to allow using nftables and
> > iptables NAT at same time.
> 
> Hm, I think we forgot to talk about this during the NFWS.

Yes.  We can try Netdev 2.2 next 8-)

> > If this is unwanted (there was concern wrt. to the new hooks I had to
> > add for this), we should at least improve/restrict iptables and nftables
> > to
> > 
> > 1. not allow load if iptable_nat when nft nat hook is active.
> 
> I guess this would apply the other way around.

Both ways.

> > 2. make it a requirement to register empty nat hook (required for
> > the reply direction).
> 
> I'm seeing many posts on the lack of automatic registration of the
> empty NAT chain. This is a pitfall where many people are falling one
> after another in migrations.  I know there's a bold sentence in the
> documentation, but I think it's a sympton that we're doing something
> that is unintuitive to users, and it should be a wake up call for us.

I agree.

> Can we just autoregister the empty nat chain using the default
> priority? If an explicit chain is registered, then disable this.
>
> Does this sound too complicated to you?

I'll look into it.

> > 3. Do not permit more than one nat type per family/hook.
> 
> Yes, this makes sense to me.
> 
> > 4. we should probably also add more checks on nat priority
> > for nftables to reject hooks that can't work due to no-conntrack
> > information being available at that point.
> 
> Yes, this would be good too.
> 
> > I think not allowing nft and iptablles nat at the same time is fine
> > as mixing has problems on its own, especially which transformation
> > gets precedence, so I suspect the old RFC patches resolve one issue
> > and add another one :)
> 
> My only concern is, may this cause problems when migrating from
> iptables to nftables?

I don't see any however once we do it we cannot remove such additional
hooks anymore (right now it won't work, if we do it iptable_nat and
nftables nat will work (plus multiple nftables nat chains types
if the priority is before the implicit null-binding hook so if we revert
that we break such setups that rely on the new implicit hooks.

Registering implicit nat hook, making iptables_nat and nftables nat
at the same time impossible (reject from kernel) etc. is more
convenient as we cannot break existing setups and only prevent
configuring a non-working/broken state rather than allowing things
that do not work at the moment.

Re: nftables and iptables nat coexistence

[Pablo Neira Ayuso]

On Thu, Oct 19, 2017 at 01:18:12PM +0200, Florian Westphal wrote:
> Registering implicit nat hook, making iptables_nat and nftables nat
> at the same time impossible (reject from kernel) etc. is more
> convenient as we cannot break existing setups and only prevent
> configuring a non-working/broken state rather than allowing things
> that do not work at the moment.

Yes, let's tighten things now, we can relax them later.