On Tuesday 2009-01-13 10:13, Jan Engelhardt wrote: > >Is there any particular reason for removing DROP target from nat table? >Some people may be using this functionality (like me). It is a hack, not a functionality. All the the user is supposed to do with the NAT table is decide whether or not some address transformation should happen. It is _not_ an access control mechanism, because there is no standards-level guarantee that all packets you want to police would go through it, and NOTRACK is just the most obvious one. I would go as far as saying that DROP is not guaranteed to drop it at all - look at the BROUTING table. >Access >control for lan clients on my routers is done in PREROUTING chain of nat >table in following way (in great simplification): >- DNAT to infoHost:infoPort1 tcp packets to port 80 from IP/MAC pair in >ipset INFO-GRP1 >- RETURN packets from IP/MAC pair in ipset >- DNAT tcp packets to port 80 to infoHost:infoPort2 >- DROP rest of the packets You simply use -t filter -m conntrack ! --ctstate DNAT -j DROP instead of the last rule. >I know DROPping in nat table isn't perfect (doesn't filterout already >established "connections"), but it should be less cpu-intensive as it's >done for the first packet of a "connection". And what would be the excuse if you had IPv6 traffic? ;-) If you are _that_ concerned about CPU usage (and I remember there being an analysis of Netfilter's speed compared to other solutions; a document somewhere on people.netfilter.org), you would have done it in the mangle table, not in nat, short of saying that that is probably not the purpose of mangle either. There were once thoughts to combine some tables because of the redundancy, but the thought timed out :) -- 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
