The glorious NFCT "none" helper

The glorious NFCT "none" helper

[Jan Engelhardt]

Hej,


While working with a customer setup, I came up with this funny idea
of plugging a no-op NFCT helper in to workaround some nfct_ftp
problem. Besides that, it may also be used to simply skip helping and
save cycles. See the patch's message for details - I'd love to hear
something about it.

(NB: nf_nat_ftp was loaded, but not used when connecting between netA
and netB.)


Jan

[PATCH] netfilter: the "none" conntrack helper module

[Jan Engelhardt]

To cope with some crappy, easily DOS-able network equipment, a
customer put Linux on each side of the shabby shaper in question.
Since NFCT supports zones since recently, these two system images can
be collapsed without causing tracking problems. The layout thus is
something like:

graph {
	subgraph cluster_1 {
		label="linux";
		subgraph cluster_2 { label="ctzone0"; eth0; eth1; };
		subgraph cluster_3 { label="ctzone1"; eth2; eth3; };
	};
	subgraph cluster_4 {
		label="shaper";
		"FE/0"; "FE/1";
	};
	netA -- eth0 -- eth1 -- "FE/0" -- "FE/1" --
	eth2 -- eth3 -- netB;
};

With this setup however, nf_conntrack_ftp seems to discard packets
when they re-enter nfct_ftp for the second time. To work around this,
I devised this "none" helper module, which can be used in the raw
table with `-j CT --helper none` in one zone to avoid automatically
running nfct_ftp - or any other helper for that matter. `-j CT
--notrack` was out of the option, as both zones needed tracking
support for xt_connlimit.

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 net/netfilter/Kconfig             |    8 +++
 net/netfilter/Makefile            |    1 +
 net/netfilter/nf_conntrack_none.c |  111 +++++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+), 0 deletions(-)
 create mode 100644 net/netfilter/nf_conntrack_none.c

diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 32bff6d..9300b11 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -132,6 +132,14 @@ config NF_CT_PROTO_UDPLITE
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config NF_CONNTRACK_NONE
+	tristate '"none" helper'
+	depends on NETFILTER_ADVANCED
+	---help---
+	This helper does nothing, and is a workaround for
+	nf_conntrack_* breaking down on expectations when traffic
+	is fed back into the system.
+
 config NF_CONNTRACK_AMANDA
 	tristate "Amanda backup protocol support"
 	depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 1a02853..d710ec5 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_NF_CT_NETLINK) += nf_conntrack_netlink.o
 # connection tracking helpers
 nf_conntrack_h323-objs := nf_conntrack_h323_main.o nf_conntrack_h323_asn1.o
 
+obj-$(CONFIG_NF_CONNTRACK_NONE) += nf_conntrack_none.o
 obj-$(CONFIG_NF_CONNTRACK_AMANDA) += nf_conntrack_amanda.o
 obj-$(CONFIG_NF_CONNTRACK_FTP) += nf_conntrack_ftp.o
 obj-$(CONFIG_NF_CONNTRACK_H323) += nf_conntrack_h323.o
diff --git a/net/netfilter/nf_conntrack_none.c b/net/netfilter/nf_conntrack_none.c
new file mode 100644
index 0000000..5ae618f
--- /dev/null
+++ b/net/netfilter/nf_conntrack_none.c
@@ -0,0 +1,111 @@
+#include <linux/module.h>
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_expect.h>
+#include <net/netfilter/nf_conntrack_helper.h>
+
+static int nohelp_helper(struct sk_buff *skb, unsigned int protoff,
+			 struct nf_conn *ct, enum ip_conntrack_info ctinfo)
+{
+	return NF_ACCEPT;
+}
+
+static const struct nf_conntrack_expect_policy noexp_policy = {
+	.max_expected = 1,
+	.timeout      = 5 * 60,
+};
+
+static struct nf_conntrack_helper nohelp_reg[] __read_mostly = {
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV6,
+		.tuple.dst.protonum = IPPROTO_TCP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV6,
+		.tuple.dst.protonum = IPPROTO_SCTP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV6,
+		.tuple.dst.protonum = IPPROTO_UDP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV6,
+		.tuple.dst.protonum = IPPROTO_DCCP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV4,
+		.tuple.dst.protonum = IPPROTO_TCP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV4,
+		.tuple.dst.protonum = IPPROTO_SCTP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV4,
+		.tuple.dst.protonum = IPPROTO_UDP,
+	},
+	{
+		.name               = "none",
+		.me                 = THIS_MODULE,
+		.help               = nohelp_helper,
+		.expect_policy      = &noexp_policy,
+		.tuple.src.l3num    = NFPROTO_IPV4,
+		.tuple.dst.protonum = IPPROTO_DCCP,
+	},
+};
+
+static int __init nfct_none_init(void)
+{
+	unsigned int i;
+	int ret;
+
+	for (i = 0; i < ARRAY_SIZE(nohelp_reg); ++i) {
+		ret = nf_conntrack_helper_register(&nohelp_reg[i]);
+		if (ret < 0)
+			goto out;
+	}
+	return 0;
+out:
+	while (i-- > 0)
+		nf_conntrack_helper_unregister(&nohelp_reg[i]);
+	return ret;
+}
+
+static void __exit nfct_none_exit(void)
+{
+	unsigned int i = ARRAY_SIZE(nohelp_reg);
+
+	while (i-- > 0)
+		nf_conntrack_helper_unregister(&nohelp_reg[i]);
+}
+
+module_init(nfct_none_init);
+module_exit(nfct_none_exit);
+MODULE_LICENSE("GPL");
-- 
1.7.3.4

Re: The glorious NFCT "none" helper

[Patrick McHardy]

On 19.05.2011 00:21, Jan Engelhardt wrote:
> Hej,
> 
> 
> While working with a customer setup, I came up with this funny idea
> of plugging a no-op NFCT helper in to workaround some nfct_ftp
> problem. Besides that, it may also be used to simply skip helping and
> save cycles. See the patch's message for details - I'd love to hear
> something about it.
> 
> (NB: nf_nat_ftp was loaded, but not used when connecting between netA
> and netB.)

Wouldn't a flag to the CT target to skip the helper lookup work as well?

Re: The glorious NFCT "none" helper

[Pablo Neira Ayuso]

On 23/05/11 16:29, Patrick McHardy wrote:
> On 19.05.2011 00:21, Jan Engelhardt wrote:
>> Hej,
>>
>>
>> While working with a customer setup, I came up with this funny idea
>> of plugging a no-op NFCT helper in to workaround some nfct_ftp
>> problem. Besides that, it may also be used to simply skip helping and
>> save cycles. See the patch's message for details - I'd love to hear
>> something about it.
>>
>> (NB: nf_nat_ftp was loaded, but not used when connecting between netA
>> and netB.)
> 
> Wouldn't a flag to the CT target to skip the helper lookup work as well?

Indeed.

Re: The glorious NFCT "none" helper

[Jan Engelhardt]

On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:

>On 23/05/11 16:29, Patrick McHardy wrote:
>> On 19.05.2011 00:21, Jan Engelhardt wrote:
>>> Hej,
>>>
>>>
>>> While working with a customer setup, I came up with this funny idea
>>> of plugging a no-op NFCT helper in to workaround some nfct_ftp
>>> problem. Besides that, it may also be used to simply skip helping and
>>> save cycles. See the patch's message for details - I'd love to hear
>>> something about it.
>>>
>>> (NB: nf_nat_ftp was loaded, but not used when connecting between netA
>>> and netB.)
>> 
>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>
>Indeed.

Yes, but how would xt_CT.ko convey to NFCT then that no helper is 
supposed to be used? Calling nf_ct_helper_ext_add, but then leave help 
at NULL?

Re: The glorious NFCT "none" helper

[Pablo Neira Ayuso]

On 23/05/11 17:59, Jan Engelhardt wrote:
> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:
> 
>> On 23/05/11 16:29, Patrick McHardy wrote:
>>> On 19.05.2011 00:21, Jan Engelhardt wrote:
>>>> Hej,
>>>>
>>>>
>>>> While working with a customer setup, I came up with this funny idea
>>>> of plugging a no-op NFCT helper in to workaround some nfct_ftp
>>>> problem. Besides that, it may also be used to simply skip helping and
>>>> save cycles. See the patch's message for details - I'd love to hear
>>>> something about it.
>>>>
>>>> (NB: nf_nat_ftp was loaded, but not used when connecting between netA
>>>> and netB.)
>>>
>>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>>
>> Indeed.
> 
> Yes, but how would xt_CT.ko convey to NFCT then that no helper is 
> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help 
> at NULL?

You can attach a template conntrack in the raw table with the CT target.
That template should have some status flag set to skip helper
allocation/assignation.

I sent a patch to Patrick to fix some problem with the current userspace
expectation approach, the idea would be similar.

Re: The glorious NFCT "none" helper

[Patrick McHardy]

On 23.05.2011 18:13, Pablo Neira Ayuso wrote:
> On 23/05/11 17:59, Jan Engelhardt wrote:
>> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:
>>
>>> On 23/05/11 16:29, Patrick McHardy wrote:
>>>> On 19.05.2011 00:21, Jan Engelhardt wrote:
>>>>> Hej,
>>>>>
>>>>>
>>>>> While working with a customer setup, I came up with this funny idea
>>>>> of plugging a no-op NFCT helper in to workaround some nfct_ftp
>>>>> problem. Besides that, it may also be used to simply skip helping and
>>>>> save cycles. See the patch's message for details - I'd love to hear
>>>>> something about it.
>>>>>
>>>>> (NB: nf_nat_ftp was loaded, but not used when connecting between netA
>>>>> and netB.)
>>>>
>>>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>>>
>>> Indeed.
>>
>> Yes, but how would xt_CT.ko convey to NFCT then that no helper is 
>> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help 
>> at NULL?
> 
> You can attach a template conntrack in the raw table with the CT target.
> That template should have some status flag set to skip helper
> allocation/assignation.

Problem might be the second lookup done after NAT. We don't have the
template available at that time.

I don't like the dummy helper idea very much though, what I would
prefer is an option to use only explicit helper assignment. That
would be a more flexible option, additionally allowing to track
protocols on any port without specifying each of them when loading
the helper.

Re: The glorious NFCT "none" helper

[Pablo Neira Ayuso]

On 24/05/11 09:06, Patrick McHardy wrote:
> On 23.05.2011 18:13, Pablo Neira Ayuso wrote:
>> On 23/05/11 17:59, Jan Engelhardt wrote:
>>> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:
>>>> On 23/05/11 16:29, Patrick McHardy wrote:
>>>>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>>>>
>>>> Indeed.
>>>
>>> Yes, but how would xt_CT.ko convey to NFCT then that no helper is 
>>> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help 
>>> at NULL?
>>
>> You can attach a template conntrack in the raw table with the CT target.
>> That template should have some status flag set to skip helper
>> allocation/assignation.
> 
> Problem might be the second lookup done after NAT. We don't have the
> template available at that time.

We'll have some IPS_NO_HELPER flag set for the conntrack at that time to
skip the helper assignation.

> I don't like the dummy helper idea very much though, what I would
> prefer is an option to use only explicit helper assignment. That
> would be a more flexible option, additionally allowing to track
> protocols on any port without specifying each of them when loading
> the helper.

I don't want to assign a dummy helper, but use a flag to skip helper
assignation, would you be OK with that idea?

BTW, not related with this patch but I'd like to fix the current issue
with the userspace expectation support problem, still don't like my
patches to add a template and set one flag to explicitly tell conntrack
to allocate the helper CT extension?

Re: The glorious NFCT "none" helper

[Patrick McHardy]

On 24.05.2011 21:03, Pablo Neira Ayuso wrote:
> On 24/05/11 09:06, Patrick McHardy wrote:
>> On 23.05.2011 18:13, Pablo Neira Ayuso wrote:
>>> On 23/05/11 17:59, Jan Engelhardt wrote:
>>>> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:
>>>>> On 23/05/11 16:29, Patrick McHardy wrote:
>>>>>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>>>>>
>>>>> Indeed.
>>>>
>>>> Yes, but how would xt_CT.ko convey to NFCT then that no helper is 
>>>> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help 
>>>> at NULL?
>>>
>>> You can attach a template conntrack in the raw table with the CT target.
>>> That template should have some status flag set to skip helper
>>> allocation/assignation.
>>
>> Problem might be the second lookup done after NAT. We don't have the
>> template available at that time.
> 
> We'll have some IPS_NO_HELPER flag set for the conntrack at that time to
> skip the helper assignation.
> 
>> I don't like the dummy helper idea very much though, what I would
>> prefer is an option to use only explicit helper assignment. That
>> would be a more flexible option, additionally allowing to track
>> protocols on any port without specifying each of them when loading
>> the helper.
> 
> I don't want to assign a dummy helper, but use a flag to skip helper
> assignation, would you be OK with that idea?

Sure, that sounds like something that would fit into the CT target.
My idea other idea is to have a global option to disable helper
lookups and *only* use explicit assignment, so you can specificy
specifically for which addresses and ports to use helpers.

> BTW, not related with this patch but I'd like to fix the current issue
> with the userspace expectation support problem, still don't like my
> patches to add a template and set one flag to explicitly tell conntrack
> to allocate the helper CT extension?

This is too much exposure of implementation in my opinion, userspace
shouldn't have to care about extension areas. I'll have another look
at your patches to see if I can come up with an alternative.

Re: The glorious NFCT "none" helper

[Patrick McHardy]

On 07.06.2011 12:23, Patrick McHardy wrote:
> On 24.05.2011 21:03, Pablo Neira Ayuso wrote:
>> BTW, not related with this patch but I'd like to fix the current issue
>> with the userspace expectation support problem, still don't like my
>> patches to add a template and set one flag to explicitly tell conntrack
>> to allocate the helper CT extension?
> 
> This is too much exposure of implementation in my opinion, userspace
> shouldn't have to care about extension areas. I'll have another look
> at your patches to see if I can come up with an alternative.

I couldn't come up with anything reasonable that would be better than
your approach, so let's do that.