Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3021455pxu; Tue, 8 Dec 2020 01:05:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+7jFdVB0EPvEn58bXZa/Xbm6YJbjGtNiEwNZKVg2M9TbAulcClmVDPUUrL1q2YEqG2EV3 X-Received: by 2002:a05:6402:456:: with SMTP id p22mr23608859edw.26.1607418312232; Tue, 08 Dec 2020 01:05:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607418312; cv=none; d=google.com; s=arc-20160816; b=CUmeI8oXziN9Pm4//AdxIKF/nkE4R540wPTWehpKxO8rg+hRxBinnePhX2VPhakchk s5tagR0306SsHArNrdBayeyU9jN9TckzD/U5AYC+yh5iSuc28kUh+7GK0BftR4eIbWzc 8hbQwVOEVAMbOg3R6YAj6RFAnYmxWceso5OS/txZUJxWHIOooMLl7V7wnMdIzVMIm8FM uOGgI+HkichBjgh0pEIelmjDK4RH920ZgksNLO+wZgPZUqHtfD8vnkSxxYtiurGs86xZ mN3MB9q6bmeZYtBrOjt8IW45xhblliSuZE29Ff44avh7zY1CyOQSM1aTw/MgC1GqdNse UtKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:reply-to:dkim-signature; bh=D292rnchnagOWW2nrkDLX5KQjbRLYsh4Pq7aFW+b4P0=; b=QAQDIw667AunUc/pQ51WDiA0EDn/hEz2bmuw0wCZ0Y5WqO9KLNpxT6uUYrqj4jVmCB BLu2xQ3nldfVI3ujsermDCT3Z4DefzbrE2eM1ihDz62ETbHgnAFDmSO3fbhO50Hq+3R3 AaNqk0pBFy7NPV9p2bxdjsUDXnMGsLLfz7KoOCX6lzLyomqzGeefF5ODmxoIzzTIvnhy Z6nYq4wO2qa/O7kiO6IGx7VaYZWqNsnuYuobmqYYopUinupk1lJQXGzD3Jr2Is23lPZY o2u0m7WmT5QEYIn+KQ6JS31YBNXsDMjA1EbPhtfCal5P2l0UC2RDKUM3J4sCYE7dvpwD mXkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@6wind.com header.s=google header.b=jJJ9a1eR; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j3si7928184eje.93.2020.12.08.01.04.42; Tue, 08 Dec 2020 01:05:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@6wind.com header.s=google header.b=jJJ9a1eR; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728600AbgLHJDC (ORCPT + 99 others); Tue, 8 Dec 2020 04:03:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728544AbgLHJDA (ORCPT ); Tue, 8 Dec 2020 04:03:00 -0500 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B91E5C061793 for ; Tue, 8 Dec 2020 01:02:19 -0800 (PST) Received: by mail-ej1-x644.google.com with SMTP id jx16so23520772ejb.10 for ; Tue, 08 Dec 2020 01:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=reply-to:subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D292rnchnagOWW2nrkDLX5KQjbRLYsh4Pq7aFW+b4P0=; b=jJJ9a1eREXY/Zp+bSKAKPZsEo+YNdU2Q+1VaskhhOMVr3iKhmEAa2t+CvOVTKWpr4f YaKwUoL4AG8/gOso24uvacDF4SAI+gpEWr07kIiQBN/I/cDzFrXBALU3RKeZw1+IpIgX Up3Yaj0+jQ0wzRTzrRdzI3+l0zs5bHrzk0DMniMJCg7X2IvjhVGuvsfDql/1BgOpBqMv jxL+7mxpAdZN11qzIU3Eo5bOEA6VzA0VEkQv9TncL6reEqLLmbjcKZ8eonRMzmnD1oJw BQaQORn0RDZCA0OGBYTsX+CDa3ZijRce2+iQ3WeRiRUP0LPLw/mtZhY2tNgSDdB75gSi EDtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=D292rnchnagOWW2nrkDLX5KQjbRLYsh4Pq7aFW+b4P0=; b=EMAprFPNCs3u48P8m0SiculMmsazsAYISPeU/J3zxHFZbkiMQuQNPgzYx9krJzVCIU sD9Fmois8BTJoa7iYsyPORVU+28tpa4UzXk1eHfxQpsda57aaFCOa7i79TPASq60sbP9 H2K7BnFnGqon42ypaXvbhv+LUeIrDLSTjBg4/yOlf4v6xZcjNKwILdQUdDMywYw5+2pV U+ku0kSyKgn3jA0r6CGwDbCIgOOg08lt2nv0qV8rPY07lgIOAzZ6H96vY3J7UuZCpfio gxtRqlSGAgywh+p8kdNa4i6kfQHtIMZpjkjKfGe9Jt19qTDlEThK979gcrE5BvDThncf nGxg== X-Gm-Message-State: AOAM533m9E3p3GXmSqHIl+o2k658Sqkm2mLqVm1re576E9ZdrIf0oFSQ HB1AV4NnhCFS0I5KWi2VIsxiJg== X-Received: by 2002:a17:907:3f9e:: with SMTP id hr30mr22330553ejc.258.1607418138431; Tue, 08 Dec 2020 01:02:18 -0800 (PST) Received: from ?IPv6:2a01:e0a:410:bb00:8c20:be83:b3f:b8b9? ([2a01:e0a:410:bb00:8c20:be83:b3f:b8b9]) by smtp.gmail.com with ESMTPSA id n22sm16261112edr.11.2020.12.08.01.02.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 01:02:17 -0800 (PST) Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter To: Phil Sutter , Steffen Klassert Cc: linux-crypto@vger.kernel.org, netfilter-devel@vger.kernel.org, netdev@vger.kernel.org References: <20201207134309.16762-1-phil@nwl.cc> From: Nicolas Dichtel Organization: 6WIND Message-ID: <9d9cb6dc-32a3-ff1a-5111-7688ce7a2897@6wind.com> Date: Tue, 8 Dec 2020 10:02:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201207134309.16762-1-phil@nwl.cc> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Le 07/12/2020 à 14:43, Phil Sutter a écrit : > With an IPsec tunnel without dedicated interface, netfilter sees locally > generated packets twice as they exit the physical interface: Once as "the > inner packet" with IPsec context attached and once as the encrypted > (ESP) packet. > > With xfrm_interface, the inner packet did not traverse NF_INET_LOCAL_OUT > hook anymore, making it impossible to match on both inner header values > and associated IPsec data from that hook. > > Fix this by looping packets transmitted from xfrm_interface through > NF_INET_LOCAL_OUT before passing them on to dst_output(), which makes > behaviour consistent again from netfilter's point of view. > > Fixes: f203b76d78092 ("xfrm: Add virtual xfrm interfaces") > Signed-off-by: Phil Sutter > --- > Changes since v1: > - Extend recipients list, no code changes. > --- > net/xfrm/xfrm_interface.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > 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->protocol must be correctly set, maybe better to use it instead of skb_dst(skb)->ops->family? > + skb->sk, skb, NULL, skb_dst(skb)->dev, dst_output); And here, tdev instead of skb_dst(skb)->dev ? > if (net_xmit_eval(err) == 0) { > struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats); > >