Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
