What's the difference between iptables "state" and "ctstate"?

I saw this iptables snippet in a different Super User answer:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

The point is to always allow packets that are sent as a part of an established connection. The part I'm wondering about is the top two lines.

For the INPUT chain, what is the point of writing both -m conntrack --ctstate RELATED,ESTABLISHED and -m state --state RELATED,ESTABLISHED. It seems to be both should do the same thing?

An explanation of the difference between these two would be great.

Main answer :

Conntrack supersedes state, but in modern kernels there is now no difference between the two. State is currently aliased and translated to conntrack in iptables if the kernel has it, so the syntax -m state --state is actually translated into -m conntrack --ctstate and handled by the same module.

On some old kernels, however, contrack has to be specifically enabled.

Possible explanation :

It seems to me as if the rules you quoted included duplicates, catering for both older and newer kernels.

Or maybe this is just a case of Cargo cult programming.

There is this question on ServerFault from the year 2012:

What's the practical difference between:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

and

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Which one is best to use?

The accepted answer is:

Both use same kernel internals underneath (connection tracking subsystem).

Header of xt_conntrack.c:

xt_conntrack - Netfilter module to match connection tracking
information. (Superset of Rusty's minimalistic state match.)

So I would say -- state module is simpler (and maybe less error prone). It's also longer in kernel. Conntrack on the other side has more options and features[1].

My call is to use conntrack if you need it's features, otherwise stick with state module.

Similar question on netfilter maillist.

[1] Quite useful like -m conntrack --ctstate DNAT -j MASQUERADE" routing/DNAT fixup ;-)

One of the other answers leads to this document about iptables. It says:

The conntrack match is an extended version of the state match, which makes it possible to match packets in a much more granular way. It let's you look at information directly available in the connection tracking system, without any "frontend" systems, such as in the state match.

So I think this is true (from yet another answer there):

There is no difference in the outcome of those two rules.

Note there is also an interesting comment under the question:

state is deprecated in favor of conntrack, and may or may not be compiled in depending on how your kernel was built.