* module order: tcp/conntrack vs. conntrack/tcp
@ 2012-07-02 12:02 Wouter
2012-07-02 12:16 ` Jan Engelhardt
0 siblings, 1 reply; 6+ messages in thread
From: Wouter @ 2012-07-02 12:02 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: module order: tcp/conntrack vs. conntrack/tcp
2012-07-02 12:02 module order: tcp/conntrack vs. conntrack/tcp Wouter
@ 2012-07-02 12:16 ` Jan Engelhardt
2012-07-02 12:49 ` Wouter
2012-07-03 1:57 ` Julien Vehent
0 siblings, 2 replies; 6+ messages in thread
From: Jan Engelhardt @ 2012-07-02 12:16 UTC (permalink / raw)
To: Wouter; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: module order: tcp/conntrack vs. conntrack/tcp
2012-07-02 12:16 ` Jan Engelhardt
@ 2012-07-02 12:49 ` Wouter
2012-07-03 1:57 ` Julien Vehent
1 sibling, 0 replies; 6+ messages in thread
From: Wouter @ 2012-07-02 12:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: module order: tcp/conntrack vs. conntrack/tcp
2012-07-02 12:16 ` Jan Engelhardt
2012-07-02 12:49 ` Wouter
@ 2012-07-03 1:57 ` Julien Vehent
2012-07-03 11:56 ` Jan Engelhardt
1 sibling, 1 reply; 6+ messages in thread
From: Julien Vehent @ 2012-07-03 1:57 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: module order: tcp/conntrack vs. conntrack/tcp
2012-07-03 1:57 ` Julien Vehent
@ 2012-07-03 11:56 ` Jan Engelhardt
2012-07-04 5:47 ` Julien Vehent
0 siblings, 1 reply; 6+ messages in thread
From: Jan Engelhardt @ 2012-07-03 11:56 UTC (permalink / raw)
To: Julien Vehent; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: module order: tcp/conntrack vs. conntrack/tcp
2012-07-03 11:56 ` Jan Engelhardt
@ 2012-07-04 5:47 ` Julien Vehent
0 siblings, 0 replies; 6+ messages in thread
From: Julien Vehent @ 2012-07-04 5:47 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-04 5:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-02 12:02 module order: tcp/conntrack vs. conntrack/tcp Wouter
2012-07-02 12:16 ` Jan Engelhardt
2012-07-02 12:49 ` Wouter
2012-07-03 1:57 ` Julien Vehent
2012-07-03 11:56 ` Jan Engelhardt
2012-07-04 5:47 ` Julien Vehent
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.