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. -- 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
