Re: BUG: Kernel panic at masquerade

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Jan 14, 2015 at 06:49:10PM +0000, Patrick McHardy wrote:
> On 14.01, Pablo Neira Ayuso wrote:
> > I think that if we control the NAT hook registration from a module,
> > then NAT chains will have to become built-in again, since we need to
> > tie the NAT chain and its rules from the hook to perform the NAT
> > handling.
> 
> No, I think the NAT runtime should be standalone and the NAT tables
> should simply be there to set up mappings. Its quite easy, they
> only receive packets in state NEW and we remove the chain invocation
> from the NAT core.

OK, so the NAT standalone module performs the NAT for state
ESTABLISHED packets. The mapping will be still controlled by the
chain. This will also work for dynamic NAT set via ctnetlink, so users
will not need to even have NAT chains to run this.

I think we'll need two hooks though. And we would still have the
incompatibility that we have with iptable_nat and nf_tables, only the
first one in place will be considered. We'll also have to
inconditionally register the input and output NAT hooks.