module order: tcp/conntrack vs. conntrack/tcp

module order: tcp/conntrack vs. conntrack/tcp

[Wouter]

Hello,

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

[root@test1 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:8140
state NEW
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
dpt:8140

Rule 1: TCP --> state
Rule 2: state --> TCP

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.

Thanks for for any insight!

  Wouter

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

[Jan Engelhardt]

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.

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

[Wouter]

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

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

[Julien Vehent]

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 ?

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

conntrack match options:
[!] --ctstate {INVALID|ESTABLISHED|NEW|RELATED|UNTRACKED|SNAT|DNAT}[,...]
                                State(s) to match
[!] --ctproto proto            Protocol to match; by number or name, e.g. 
"tcp"
[!] --ctorigsrc address[/mask]
[!] --ctorigdst address[/mask]
[!] --ctreplsrc address[/mask]
[!] --ctrepldst address[/mask]
                                Original/Reply source/destination address
[!] --ctorigsrcport port
[!] --ctorigdstport port
[!] --ctreplsrcport port
[!] --ctrepldstport port
                                TCP/UDP/SCTP orig./reply source/destination 
port
[!] --ctstatus {NONE|EXPECTED|SEEN_REPLY|ASSURED|CONFIRMED}[,...]
                                Status(es) to match
[!] --ctexpire time[:time]     Match remaining lifetime in seconds against
                                value or range of values (inclusive)
     --ctdir {ORIGINAL|REPLY}   Flow direction of packet


Thanks,
Julien

-- 
Julien Vehent - http://1nw.eu/!j

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

[Jan Engelhardt]

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.

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

[Julien Vehent]

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