netfilter: nf_conntrack: fix explicit helper attachment and NAT
authorPablo Neira Ayuso <pablo@netfilter.org>
Thu, 3 May 2012 02:17:45 +0000 (02:17 +0000)
committerPablo Neira Ayuso <pablo@netfilter.org>
Tue, 8 May 2012 17:44:42 +0000 (19:44 +0200)
commit6714cf5465d2803a21c6a46c1ea747795a8889fa
treeeccfd714c4d320f4724e15e59b964ddd487e8f09
parent9768e1ace458fa4ebf88bc3943fd8fb77113ed9c
netfilter: nf_conntrack: fix explicit helper attachment and NAT

Explicit helper attachment via the CT target is broken with NAT
if non-standard ports are used. This problem was hidden behind
the automatic helper assignment routine. Thus, it becomes more
noticeable now that we can disable the automatic helper assignment
with Eric Leblond's:

9e8ac5a netfilter: nf_ct_helper: allow to disable automatic helper assignment

Basically, nf_conntrack_alter_reply asks for looking up the helper
up if NAT is enabled. Unfortunately, we don't have the conntrack
template at that point anymore.

Since we don't want to rely on the automatic helper assignment,
we can skip the second look-up and stick to the helper that was
attached by iptables. With the CT target, the user is in full
control of helper attachment, thus, the policy is to trust what
the user explicitly configures via iptables (no automatic magic
anymore).

Interestingly, this bug was hidden by the automatic helper look-up
code. But it can be easily trigger if you attach the helper in
a non-standard port, eg.

iptables -I PREROUTING -t raw -p tcp --dport 8888 \
-j CT --helper ftp

And you disabled the automatic helper assignment.

I added the IPS_HELPER_BIT that allows us to differenciate between
a helper that has been explicitly attached and those that have been
automatically assigned. I didn't come up with a better solution
(having backward compatibility in mind).

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
include/linux/netfilter/nf_conntrack_common.h
net/netfilter/nf_conntrack_helper.c