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

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

 



On 2012-07-03 7:56, Jan Engelhardt wrote:
On Tuesday 2012-07-03 03:57, Julien Vehent wrote:

On 2012-07-02 8:16, Jan Engelhardt wrote:
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.

I just discovered that -m state is obsolete. There not much to read
about -m conntrack on the mailing lists (this one or the dev one).
Would you care the elaborate on the advantages of the conntrack module
as opposed to the state one?

More states that can be checked.


Should we also stop using -p, -s, -d, --sport and --dport and replace
them with the equivalents in the conntrack module?

1. That is for you to decide. As always, different matches only
exist because their semantics are reasonably different from the rest.
Consider

-A FORWARD -s 2001:db8::4 -j ACCEPT
-A FORWARD -d 2001:db8::4 -j ACCEPT

and

-A FORWARD -m conntrack --ctorigsrc 2001:db8::4 -j ACCEPT

The former will allow all packets from and to 2001:db8::4 no matter who
started.

The latter will only accept packets that belong to connections initiated
by 2001:db8::4;  2001:db8::4 can be in the srcip or the dstip field.
Some unexperienced people may be sufficiently puzzled by that.

So in a way, the latter check is stricter and matches less, but if that
is what you actually want, you just discovered a rule saver.


2. If you have connection pickup enabled, the order of the orig
and repl tuples depends on who we see a packet first from.

Very cool ! I guess it's time to update my rulesets :)
Thanks for the answer.

- Julien

--
Julien Vehent - http://1nw.eu/!j
--
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