On Fri, Jul 13, 2018 at 12:59:14PM +0200, Pablo Neira Ayuso wrote: > On Fri, Jul 13, 2018 at 12:45:34PM +0200, Florian Westphal wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > On Fri, Jul 13, 2018 at 12:22:51PM +0200, Máté Eckl wrote: > > > > > > BTW, srcnat only makes sense from postrouting, I think it would it be > > > > > > possible to reject things that make no sense from there, like srcnat > > > > > > with prerouting as in the example above. > > > > > > > > > > I'll look after this. > > > > > > > > What do you think about this compatibility "matrix"? > > > > > > Looks fine, one comment though regarding bridge: > > > > > > include/linux/netfilter_bridge.h: NF_BR_PRI_NAT_DST_OTHER = 100, > > > include/linux/netfilter_bridge.h: NF_BR_PRI_NAT_SRC = 300, > > > include/linux/netfilter_bridge.h: NF_BR_PRI_NAT_DST_BRIDGED = -300, Oh. These are not exposed to the nft includes. > > > Unfortunately I think we'll need these too, ie. we cannot reuse > > > NF_IP_PRI_NAT_SRC. > > > > BR_NAT isn't "nat" family though, they are normal 'filter' types. > > > > I think it would be fine to just use 'filter + 300'. > > OK, let's do that then. But that means that this solution cannot support bridge family at all. Or BRNF stands for something that can be interpreted as filter? -- 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
