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
Data point #1
According to this document the
conntrack extension superseded
• -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
Both use same kernel internals underneath (connection tracking
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 .
My call is to use conntrack if you need it's features, otherwise stick
with state module.
 Quite useful like
"-m conntrack --ctstate DNAT -j MASQUERADE"
routing/DNAT fixup ;-)
Data point #4
I found this thread from the email@example.com 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
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 -
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