From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85E02C433E4 for ; Wed, 19 Aug 2020 16:20:10 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2E3EE2078D for ; Wed, 19 Aug 2020 16:20:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bluematt.me header.i=@bluematt.me header.b="iQ8gTKff" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E3EE2078D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bluematt.me Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d9671a6d; Wed, 19 Aug 2020 15:53:50 +0000 (UTC) Received: from mail.as397444.net (mail.as397444.net [2620:6e:a000:dead:beef:15:bad:f00d]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id 19b85e1c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 18 Aug 2020 15:00:13 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 3312C2E73EE for ; Tue, 18 Aug 2020 15:26:22 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluematt.me; s=1597762862; t=1597764383; bh=pTsXwdOBcejMSIsHoHDt/pUg6I7ZvTlXBvj+yGnvo58=; h=From:Subject:To:References:Date:In-Reply-To:From; b=iQ8gTKffuEiWN4/c1OZzxJPqeagcxPMGpLdXX9gbzNxVMTlutILr5mpydMPbAtqOv o+1Pa6xBCErjhzX08Tj42m0C/LcHs9lXJNjwAH/R3xUCSCpKanR5A9Z3/CRoQ7AIST 4r7lgzR4TZmRZ1/HVWjRkxzlf9TDdY01LouOtJVVRy9vJ6cqVi0Mz4pTyAF7FdJtFX tF3kn5Thof1gEQNvbDfTi5Px15EQ23OY960QxATwmAX4rm1FqetTycptxV3zFfe0Ik q6VlypMnQLvudvoPGPqTt+NnebQlo6VxTchWQCGLzbWf3uyJG5wzspxzSe5DXVMC6N 9lwKBxZAJK8cg== From: Matt Corallo Subject: Incorrect Source Addr Selection On Initiate and Asymmetric Routing To: WireGuard mailing list References: <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me> Message-ID: Date: Tue, 18 Aug 2020 11:26:21 -0400 MIME-Version: 1.0 In-Reply-To: <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Aug 2020 17:53:47 +0200 X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" [Resending this few-month-old mail because apparently the list bounced it the first time.] Oops, should have mentioned, this may have always been the case, with only recent addition of asymmetric routing leading me to identify it, but its at least been the case on 5.6.X and currently is the case on 5.7.6. Matt On 6/28/20 3:03 PM, Matt Corallo wrote: > I run wireguard on some endpoints with anycast IP addresses (which mostly workes seamlessly, which is awesome!), however > of late it seems the source address selection in Wireguard incorrectly selects the default source address when it most > recently received packet(s) to a different address. > > Most of the routes on such boxes have an explicit default source that is different from the anycast addresses, as > otherwise regular connections from such boxes would fail, eg: > 1.0.0.0/24 via XXX dev XXX src (non-anycast-address) metric 32 > > Ive observed wireguard selecting the default source in two cases: > > a) when the server is the one sending the handshake initiation due to the handshake timer, it appears the server selects > a new source address based on the default. I haen't had practical issues with this, but its worth noting, and probably > fixing. > > b) when the path outbound to the client is different from the path inbound. In my case, inbound v4 traffic from my phone > on T-Mobile US (which passes through CG-NAT) comes into my server on one interface, but the path back out to TMO is via > a different interface. In this case, wireguard selects the default source address and sends a packet which T-Mobile's > CG-NAT drops as there is no NAT entry for it. > > Matt >