Ytdyklly

I'm reading this howto, and there's something like this:

We can allow established sessions to receive traffic:

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

The above rule has no spaces either side of the comma in ESTABLISHED,RELATED

If the line above doesn't work, you may be on a castrated VPS whose
provider has not made available the extension, in which case an
inferior version can be used as last resort:

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

Is there a significant difference in working between -m conntrack --ctstate and -m state --state? They say that one may not work, but they don't say why. Why should I prefer one over the other?

I don't claim to be an expert with iptables rules but the first command is making use of the connection tracking extension (conntrack) while the second is making use of the state extension.

Data point #1

According to this document the conntrack extension superseded state.

 Obsolete extensions:

  • -m state: replaced by -m conntrack

Data point #2

Even so I found this SF Q&A titled: Firewall questions about state and policy? where the OP claimed to have asked this question on IRC in #iptables@freenode. After discussing it there he came to the conclusion that:

Technically the conntrack match supersedes - and so obsoletes - the state match. But practically the state match is not obsoleted in any way.

Data point #3

Lastly I found this SF Q&A titled: Iptables, what's the difference between -m state and -m conntrack?. The answer from this question is probably the best evidence and advice on how to view the usage of conntrack and state.

excerpt

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

Data point #4

I found this thread from the netfilter@vger.kernel.org netfilte/iptables discussions, titled: state match is obsolete 1.4.17, which pretty much says that state is just an alias to conntrack so it doesn't really matter which you use, in both circumstances you're using conntrack.

excerpt

Actually, I have to agree. Why don't we keep "state" as an alias and
accept the old syntax in "conntrack"?

state is currently aliased and translated to conntrack in iptables
if the kernel has it. No scripts are broken.

If the aliasing is done in userspace, the kernel part can be removed -
someday maybe.

The aliasing is already done in userspace. One types in "state" and
it's converted into "conntrack" and that is then sent to the kernel.
(So as far as I see if the ipt_state, etc module aliases were added
to the conntrack module, even the state kernel module could be
removed.)

References

• Firewall questions about state and policy?


• iptables: differences using conntrack or state module

I am not an netfilter expert, but i looked into the iptables-extension man-page and suprise, there it is

The "state" extension is a subset of the "conntrack" module.

So state is a part of conntrack and just a simpler version of it if you really just need --state and non of the more fancy features of conntrack