Re: module order: tcp/conntrack vs. conntrack/tcp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 2012-07-02 14:02, Wouter wrote:

>I'm wondering about the practical difference between these seemingly
>equivalent rules (notice the module order):
>
>iptables -A INPUT -i eth0 -p tcp --dport 8140 -m state --state NEW -j
>ACCEPT
>iptables -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 8140
>-j ACCEPT
>
>While I always use the form of rule 1 (filter first, then state NEW), I
>found some systems configured like rule 2 – which appears to have the same
>end result – and I wonder if rule 2 (state first, then filter) has any side
>effects or causes more overhead.

The use of -m conntrack (state is obsolete) is cheaper than people 
think, because the ct belonging to a packet is already long determined, 
so looking at the state is quite simple.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux