On 14.01, Pablo Neira Ayuso wrote: > 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. Yes, about filtering and NAT, but not about deep implementation details. There fact that they (probably) can't crash the kernel right now is also purely by luck, the NAT system is not designed to have the same packet passed through it multiple times. > > 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. We do this for conntrack already. Its not about the absolute priority, its simply about relative ordering, so as long as we choose a value that allows to put your own rules either before or after NAT, I don't see the problem. There are also other valid reasons for making the NAT mechanism completely independant of any tables and chains. We support iptables, nftables and ctnetlink to set it up. The mappings are persistent and connections do break if NAT suddenly disappears. That shouldn't happen simply by deleting your table. It should be a more explicit action like unloading a module. -- 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
