[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