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

[Wouter <wouter-netfilter@xxxxxxxxxxxxxxxxxxxx>]

On Mon, 2 Jul 2012 14:16:10 +0200 (CEST), Jan Engelhardt <jengelh@xxxxxxx>
wrote:
> 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.

So there are no negative side effects from conntrack --> tcp versus the
more common tcp --> conntrack?

Thanks for the speedy reply,

  Wouter

--
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