From patchwork Fri Apr 28 07:13:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steffen Klassert X-Patchwork-Id: 756263 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3wDmwv6tMrz9s7x for ; Fri, 28 Apr 2017 18:21:03 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938749AbdD1IUp (ORCPT ); Fri, 28 Apr 2017 04:20:45 -0400 Received: from a.mx.secunet.com ([62.96.220.36]:55062 "EHLO a.mx.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032235AbdD1IUk (ORCPT ); Fri, 28 Apr 2017 04:20:40 -0400 Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id DDF84214DC; Fri, 28 Apr 2017 10:20:38 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdstOriB3NCt; Fri, 28 Apr 2017 10:20:27 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 311E9214F0; Fri, 28 Apr 2017 09:13:38 +0200 (CEST) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.319.2; Fri, 28 Apr 2017 09:13:37 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 8A30614093A; Fri, 28 Apr 2017 09:13:37 +0200 (CEST) Date: Fri, 28 Apr 2017 09:13:37 +0200 From: Steffen Klassert To: Don Bowman CC: Cong Wang , "linux-kernel@vger.kernel.org" , Herbert Xu , Linux Kernel Network Developers Subject: Re: ipsec doesn't route TCP with 4.11 kernel Message-ID: <20170428071337.GG2649@secunet.com> References: <20170427084238.GX2649@secunet.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.182.7.193] X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: E11B92DA-57DD-4F49-8379-9D85BF273CA2 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 27, 2017 at 06:13:38PM -0400, Don Bowman wrote: > On 27 April 2017 at 04:42, Steffen Klassert > wrote: > > On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote: > >> (Cc'ing netdev and IPSec maintainers) > >> > >> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: > > for 'esp' question, i have ' esp = aes256-sha256-modp1536!' is that what > you mean? > its nat-aware tunnel [from my desktop pc to my office] > > root@office:~# ip -s x s > src 172.16.0.8 dst 64.7.137.180 > proto esp spi 0x0d588366(223904614) reqid 1(0x00000001) mode tunnel > replay-window 0 seq 0x00000000 flag af-unspec (0x00100000) > auth-trunc hmac(sha256) > 0x046cafdf19c5d78d1c29165d96a0b9fce1c500029d77be0fe956dce1bf80a86a (256 > bits) 128 > enc cbc(aes) > 0x79ff2fbc2178eb468de6ff16612f0603b514a1d1d5f375c67222294463ec7c62 (256 > bits) > encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 Ok, this is espinudp. This information was important. > > I'm not sure what you mean the receiving interface, you mean the outer, the > native interface? > listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes > 18:11:32.061501 IP 172.16.0.8.3416 > 64.7.137.180.33638: > truncated-udplength 0 > 18:11:32.788091 IP 64.7.137.180.4500 > 172.16.0.8.4500: NONESP-encap: > isakmp: child_sa inf2 > 18:11:32.788354 IP 172.16.0.8.4500 > 64.7.137.180.4500: NONESP-encap: > isakmp: child_sa inf2[IR] > 18:11:33.066830 IP 172.16.0.8.3416 > 64.7.137.180.33638: > truncated-udplength 0 > 18:11:35.082839 IP 172.16.0.8.3416 > 64.7.137.180.33638: > truncated-udplength 0 This is not a GRO issue as I thought, the TX side is already broken. Could you please try the patch below? Subject: [PATCH] esp4: Fix udpencap for local TCP packets. Locally generated TCP packets are usually cloned, so we do skb_cow_data() on this packets. After that we need to reload the pointer to the esp header. On udpencap this header has an offset to skb_transport_header, so take this offset into account. Fixes: commit cac2661c53f ("esp4: Avoid skb_cow_data whenever possible") Signed-off-by: Steffen Klassert --- net/ipv4/esp4.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c index b1e2444..ab71fbb 100644 --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -223,6 +223,7 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb) int extralen; int tailen; __be64 seqno; + int esp_offset = 0; __u8 proto = *skb_mac_header(skb); /* skb is pure payload to encrypt */ @@ -288,6 +289,8 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb) break; } + esp_offset = (unsigned char *)esph - (unsigned char *)uh; + *skb_mac_header(skb) = IPPROTO_UDP; } @@ -397,7 +400,7 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb) goto error; nfrags = err; tail = skb_tail_pointer(trailer); - esph = ip_esp_hdr(skb); + esph = (struct ip_esp_hdr *)(skb_transport_header(skb) + esp_offset); skip_cow: esp_output_fill_trailer(tail, tfclen, plen, proto);