From: Phil Sutter <phil@nwl.cc>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: XFRM interface and NF_INET_LOCAL_OUT hook
Date: Fri, 27 Nov 2020 15:10:48 +0100 [thread overview]
Message-ID: <20201127141048.GL4647@orbyte.nwl.cc> (raw)
In-Reply-To: <20201127095511.GD9390@gauss3.secunet.de>
On Fri, Nov 27, 2020 at 10:55:11AM +0100, Steffen Klassert wrote:
> On Thu, Nov 26, 2020 at 02:12:00PM +0100, Phil Sutter wrote:
> > > >
> > > > Is this a bug or an expected quirk when using XFRM interface?
> > >
> > > This is expected behaviour. The xfrm interfaces are plaintext devices,
> > > the plaintext packets are routed to the xfrm interface which guarantees
> > > transformation. So the lookup that assigns skb_dst(skb)->xfrm
> > > happens 'behind' the interface. After transformation,
> > > skb_dst(skb)->xfrm will be cleared. So this assignment exists just
> > > inside xfrm in that case.
> >
> > OK, thanks for the clarification.
> >
> > > Does netfilter match against skb_dst(skb)->xfrm? What is the exact case
> > > that does not work?
> >
> > The reported use-case is a match against tunnel data in output hook:
> >
> > | table t {
> > | chain c {
> > | type filter hook output priority filter
> > | oifname eth0 ipsec out ip daddr 192.168.1.2
> > | }
> > | }
> >
> > The ipsec expression tries to extract that data from skb_dst(skb)->xfrm
> > if present. In xt_policy (for iptables), code is equivalent. The above
> > works when not using xfrm_interface. Initially I assumed one just needs
> > to adjust the oifname match, but even dropping it doesn't help.
>
> Yes, this does not work with xfrm interfaces. As said, they are plaintext
> devices that guarantee transformation.
>
> Maybe you can try to match after transformation by using the secpath,
> but not sure if that is what you need.
Secpath is used for input only, no?
I played a bit more with xfrm_interface and noticed that when used,
NF_INET_LOCAL_OUT hook sees the packet (an ICMP reply) only once instead
of twice as without xfrm_interface. I don't think using it should change
behaviour that much apart from packets without matching policy being
dropped. What do you think about the following fix? I checked forwarding
packets as well and it looks like behaviour is identical to plain
policy:
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index aa4cdcf69d471..24af61c95b4d4 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -317,7 +317,8 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)
skb_dst_set(skb, dst);
skb->dev = tdev;
- err = dst_output(xi->net, skb->sk, skb);
+ err = NF_HOOK(skb_dst(skb)->ops->family, NF_INET_LOCAL_OUT, xi->net,
+ skb->sk, skb, NULL, skb_dst(skb)->dev, dst_output);
if (net_xmit_eval(err) == 0) {
struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
Thanks, Phil
next prev parent reply other threads:[~2020-11-27 14:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 11:23 XFRM interface and NF_INET_LOCAL_OUT hook Phil Sutter
2020-11-26 9:40 ` Steffen Klassert
2020-11-26 13:12 ` Phil Sutter
2020-11-27 9:55 ` Steffen Klassert
2020-11-27 14:10 ` Phil Sutter [this message]
2020-12-02 13:18 ` Steffen Klassert
2020-12-07 12:35 ` Phil Sutter
2020-12-07 12:38 ` Nicolas Dichtel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201127141048.GL4647@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=linux-crypto@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.