From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Jason@zx2c4.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id e170eb0d for ; Thu, 10 Aug 2017 14:07:51 +0000 (UTC) Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 4076f839 for ; Thu, 10 Aug 2017 14:07:51 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d0ea0b22 for ; Thu, 10 Aug 2017 14:26:54 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c180033b (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Thu, 10 Aug 2017 14:26:53 +0000 (UTC) Received: by mail-it0-f49.google.com with SMTP id 76so13778460ith.0 for ; Thu, 10 Aug 2017 07:29:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: "Jason A. Donenfeld" Date: Thu, 10 Aug 2017 16:29:54 +0200 Message-ID: Subject: Re: Multihomed server issue To: Wang Jian Content-Type: text/plain; charset="UTF-8" Cc: WireGuard mailing list , Jan De Landtsheer List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Wang, Did you have any luck reproducing this with the netns.sh script? Here's what's happening here: 1. Packet from peer P arrives from src:A dst:B 2. WireGuard records that it should contact P at src:B dst:A 3. When sending an encrypted packet to P, it asks for which interface to use for src:B dst:A. The routing API returns interface I. 4. We ask whether interface I has an address B assigned to it. If yes, we transmit the packet as src:B dst:A using interface I, and return. If no, we move to step 5: 5. We ask which interface and src IP we should use for src:default dst:A. The routing API returns interface I' (which may be the same as I or perhaps not) and a default src address, B', for interface I'. 6. We transmit the packet as src:B' dst:A using interface I'. In the past, this has been sufficient for handling issues with multihomed servers, while still dealing gracefully with IP address changes. It seems like the problem you're facing is that B does not belong to I, because B belongs to an unrouted dummy0 interface. The solution would be to change the question of step 4 to instead ask if _any_ interface contains B, not just the returned interface I. While this is essentially what's done for IPv6, I'm not certain this is the correct behavior for IPv4. Do you know of any relevant RFCs for your use of v4 dummy interfaces and RTS routing? Or some other reference? Please do let me know whether the above is an accurate representation of the problem you're facing. Jason