[strongSwan-dev] Fwd[2]: [PATCH] xfrm: fix xfrm by MARK logic in mangle table, POSTROUTING chain
Владимир Подобаев
vpodobaev at mail.ru
Thu Mar 10 11:13:23 CET 2011
Hello.
We have found some bug with marking packets in kernel. My co-worker Peter has made a patch.
But unfortunately there is no response from kernel guys.
Maybe this patch will be interesting for you. So maybe kernel guys will hear you better than us because of your authority. :)
I'm resending Peter's letter.
Best regards, Vladimir
---------- Forwarded message ----------
From: Peter Kosyh <p.kosyh at gmail.com>
Date: Wed, Mar 2, 2011 at 5:24 PM
Subject: [PATCH] xfrm: fix xfrm by MARK logic in mangle table, POSTROUTING
chain
To: netdev at vger.kernel.org
From: Peter Kosyh <p.kosyh at gmail.com>
While using xfrm by MARK feature in >= 2.6.35 kernels, i found some
strange behaviour in MARK and xfrm logic.
After doing MARK target in POSTROUTING chain in mangle table, new mark
is not used in policy lookup logic.
That is because that mark logic is a part of routing logic, and
rerouting is done only in LOCALOUT hook. Here is the code from
/net/ipv4/netfilter/iptable_mangle.c:
/* The work comes in here from netfilter.c. */
static unsigned int
iptable_mangle_hook(unsigned int hook,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
if (hook == NF_INET_LOCAL_OUT)
return ipt_mangle_out(skb, out);
if (hook == NF_INET_POST_ROUTING)
return ipt_do_table(skb, hook, in, out,
dev_net(out)->ipv4.iptable_mangle);
...
Looking NF_INET_LOCAL_OUT case, in ipt_mangle_out there is a call to
ip_route_me_harder, that will call xfrm_decode_session and new mark
will be applied to xfrm flow.
But in NF_INET_POST_ROUTING there is nothing. So we can not use xfrm
by MARK logic from POSTROUTING chain at all.
It's like due the fact, that in postrouting we are not doing
rerouting, BUT in NAT case (in POSTROUTING chain), there is call to
ip_xfrm_me_harder(skb) in nf_nat_out, so, i suppose it is a bug in
iptable_mangle.c. It is also interesting, that bug not affected on
icmp traffic. ;)
Here it is my patch that works for me. I ask anyone to help me, if it
is wrong, and i have no ideas how to fix ipv6 layer.
Signed-off-by: Peter Kosyh <p.kosyh at gmail.com>
---
diff -Nur linux-2.6.35.7/net/ipv4/netfilter/iptable_mangle.c
linux-2.6.35.7-mark/net/ipv4/netfilter/iptable_mangle.c
--- linux-2.6.35.7/net/ipv4/netfilter/iptable_mangle.c 2010-09-29
05:09:08.000000000 +0400
+++ linux-2.6.35.7-mark/net/ipv4/netfilter/iptable_mangle.c 2011-03-02
15:54:14.000000000 +0300
@@ -84,9 +84,22 @@
{
if (hook == NF_INET_LOCAL_OUT)
return ipt_mangle_out(skb, out);
- if (hook == NF_INET_POST_ROUTING)
+ if (hook == NF_INET_POST_ROUTING) {
+#ifdef CONFIG_XFRM
+ int ret;
+ u_int32_t mark = skb->mark;
+ ret = ipt_do_table(skb, hook, in, out,
+ dev_net(out)->ipv4.iptable_mangle);
+ if (skb->mark != mark && ret != NF_DROP && ret != NF_STOLEN) {
+ if (ip_xfrm_me_harder(skb))
+ ret = NF_DROP;
+ }
+ return ret;
+#else
return ipt_do_table(skb, hook, in, out,
dev_net(out)->ipv4.iptable_mangle);
+#endif
+ }
/* PREROUTING/INPUT/FORWARD: */
return ipt_do_table(skb, hook, in, out,
dev_net(in)->ipv4.iptable_mangle);
More information about the Dev
mailing list