On Tue, Jan 13, 2015 at 07:41:12PM +0000, Patrick McHardy wrote: > Related to this, what also kind of sucks is that you have to manually > take care of creating the opposite NAT chain (pre/postrouting, in/output) > to have NAT work properly. We can add some dependency chains that are automagically installed, eg. if you install a NAT prerouting chain, then install the postrouting chain that mirrors. But then, we will be assumming things on the user configuration, and I think that may results in problems when some user comes up later with some strange combination that he cannot achieve because of some automagic configuration we brought up. > We should make sure that the user can't mess this up. I'm not so sure, I think we can just make sure users can't crash the kernel. I mean, there are many ways users can screw it up when configuring their firewall, they should understand what they are doing. > Simlarly we need to prevent to have multiple NAT chains for the same > hook. This should be easy to check, yes. > Generally I think the current NAT chain implementation is very > wrong. We need to invoke the core functions once for each direction > if NAT is used independantly of any chains. So they probably > shouldn't be tied together. Then, we'll have to register the hooks on some magic priority. The chains provide the way the user can configure where he wants the NAT engine to show up. -- 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
