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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 E2862C433DF for ; Thu, 30 Jul 2020 21:03:11 +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 4CC2520838 for ; Thu, 30 Jul 2020 21:03:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qisLyTWC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CC2520838 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 3f990f90; Thu, 30 Jul 2020 20:39:25 +0000 (UTC) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [2607:f8b0:4864:20::830]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id fde7fe32 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Thu, 30 Jul 2020 20:39:22 +0000 (UTC) Received: by mail-qt1-x830.google.com with SMTP id d27so21451873qtg.4 for ; Thu, 30 Jul 2020 14:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R0REZniphmW0HZU088xfblLN7Y45Ul8IYj7AXKVPKug=; b=qisLyTWCFHEd2jHOBQocjvTA6p6ly0xWTxKO+z7rg9cum7nSP/NkG3tixCliQNT1g0 NPDdfOR8Se4WJTlVe6qogUZwWoLZTD8Cz5aPyy9fItq1pXe32s5S8A7VuJ9xf7Kk/Msg fLq+jtjChR4o0RcZZmgaQeFFeIiaf1e8tDOd2R0AmwDLJq7s4+nk6I+vrYgYT5d0pqRb WPXS4aWGRKx9oHNfG3FPAN1Ntc/UGcow07P/4pf0cO4koSMRk78UnWZdkUotME+X9MtM zNOvXa0hUwY4AyQ6RFNxQ1Sc1qOFJhF0zjXGo2qXOq246SYok0D88zX1B+SKMk/9ZGFM PskQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R0REZniphmW0HZU088xfblLN7Y45Ul8IYj7AXKVPKug=; b=J1y5NvBMVc2JIDSRKxeyHnM+gZZuSYHvY4XgYQ9aH3DOL/IzvqQeQ8+72BO8mPib4j oyshZZ2QyVQyo5EVmjNXFWDLHTVUzioTtn9w/vzbLYPlYu2sTVWDQtnErk7rjkj+K9SU 7d4BHC1pblfaAmOZVwW+wg15c5lyR2i6+6A/q/diSWqmUmWxzjluGxreqZ0hIKos41Ol lSI0pc6TcfYJKg14mbhPmmiP7cEKILzOD4VZ+J6grEu75jCuB3dmwhtfUBRjz59EpeT1 mSKQTtaYSkHud/29w10s4YJ6sWU1wTaBIByyPnoQcx93tBFHIVjuECd8H07GQ2FgHXRT BF7w== X-Gm-Message-State: AOAM5316Jgzj+cI6b1Zsvtv5S1r5YMtfofbmZkeQqrSaC0VsgAs1xEnS Km42wd3jMVMvOHKfwoQikgc= X-Google-Smtp-Source: ABdhPJyNWQLMw0t85UpwI0Z+e/BuS9CJ9AdFkxW71+BkUuL5OX3E5GIFNq/lh6uHYw0E6snmeDWGtA== X-Received: by 2002:ac8:7387:: with SMTP id t7mr629002qtp.236.1596142986961; Thu, 30 Jul 2020 14:03:06 -0700 (PDT) Received: from richs-mbp-pro.lan ([70.16.106.169]) by smtp.gmail.com with ESMTPSA id n184sm5283652qkn.49.2020.07.30.14.03.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 14:03:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Confused about AllowedIPs meaning? From: Rich Brown In-Reply-To: <20200730180809.GA12851@matrix-dream.net> Date: Thu, 30 Jul 2020 17:03:03 -0400 Cc: M Rubon , "Tomcsanyi, Domonkos" , Gunnar Niels , wireguard@lists.zx2c4.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <02830f08-9e6f-a9f1-54c3-43758e95758f@gmail.com> <26A86FD2-5A2D-49DC-A140-2E4B43213936@tomcsanyi.net> <20200729221814.GA32170@matrix-dream.net> <20200730180809.GA12851@matrix-dream.net> To: =?utf-8?Q?Ivan_Lab=C3=A1th?= X-Mailer: Apple Mail (2.3608.80.23.2.2) 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" Thanks for these additional comments.=20 > On Jul 30, 2020, at 2:08 PM, Ivan Lab=C3=A1th = wrote: >=20 > To be clear, you should not put the endpoint address > in the allowed ips list. The endpoint address is > for routing over a "physical" network, while > the "allowed" ips are the ips traveling via the tunnel, > which have no relation to the endpoint address. Now we're gettin' somewhere! I have updated my description to include = all these thoughts: https://randomneuronsfiring.com/wireguard-on-macos/ Any further comments? (I asserted that the peer addresses should be in a = unique subnet - True?) Many thanks, Rich >=20 >=20 > On Thu, Jul 30, 2020 at 10:02:10AM -0400, M Rubon wrote: >>> - Should the definition of AllowedIPs mention the "Address" of the = peer? That is, must the peer's Address be listed in AllowedIPs? [*] >>> - Some guides state that the Address specified for this peer and the = other peer should be chosen from a subnet different from any on the = networks. Is this a recommendation? A requirement? [**] >>=20 >> The address of the peer does *not* need to be included in AllowedIPs. >> If it is not there, the wg tunnel will still be created, but as >> discussed the wg tunnel will only accept packets with a destination >> address listed in AllowedIPs. >>=20 >> Following is the wg output when I have commented out the AllowedIPs >> entry in the config file. You will see the handshake is still >> happening, though in this case the tunnel itself will accept no >> packets. It is an existing but sad tunnel :-( >>=20 >> peer: tndyLlE+lVFz/HIGs9BpjH.... >> endpoint: 192.168.82.234:57331 >> allowed ips: (none) >> latest handshake: 35 seconds ago >> transfer: 280 B received, 456 B sent >> persistent keepalive: every 25 seconds >>=20 >>=20 >> On Wed, 29 Jul 2020 at 20:58, Rich Brown = wrote: >>>=20 >>> These are helpful comments. >>>=20 >>>> On Jul 29, 2020, at 6:18 PM, Ivan Lab=C3=A1th = wrote: >>>>=20 >>>> On Tue, Jul 28, 2020 at 05:33:43PM -0400, Rich Brown wrote: >>>>> AllowedIPs is the set of addresses that your WireGuard peer will = send across the tunnel to its peer. >>>>=20 >>>> The definition is close, but not precise. Assuming things haven't >>>> changed much: >>>>=20 >>>> AllowedIPs specifies the set of addresses that your WireGuard >>>> host will send across the tunnel to its peer, and accept from >>>> the peer. >>>=20 >>> I think you and M. Rubon from earlier this afternoon are saying much = the same thing. I like those definitions because they make it explicit = that the AllowedIPs are used both for transmission (only packets with = those destinations will be sent through the tunnel) and receipt (only = those source addresses will be allowed back through the tunnel). >>>=20 >>> But I believe these definitions still leave uncertainty: >>>=20 >>> - Should the definition of AllowedIPs mention the "Address" of the = peer? That is, must the peer's Address be listed in AllowedIPs? [*] >>> - Some guides state that the Address specified for this peer and the = other peer should be chosen from a subnet different from any on the = networks. Is this a recommendation? A requirement? [**] >>>=20 >>> My goal is to produce a straightforward "can't fail" guide for = people who simply want to set up a VPN from their laptop to their office = or home network. (Of course, the definitions must be correct, but I want = to leave out all the details and options that aren't essential for that = simple case.) Is the following a "good enough" definition to include in = a "Just Do This" guide? >>>=20 >>>> AllowedIPs =E2=80=94 a comma-separated list of IP (v4 or v6) = addresses with CIDR masks which are allowed: >>>> - as destination addresses when sending via this peer and >>>> - as source addresses when receiving via this peer. >>>=20 >>> Thanks. >>>=20 >>> Rich >>>=20 >>> [*] I think it is not necessary to specify the peer's Address in = AllowedIPs. If it's not included, it won't be possible to interact with = the peer using that address (since it's not in AllowedIPs). However, the = peer will likely have an address that *is* in AllowedIPs, and that's how = it will be accessible. True? >>>=20 >>> [**] I suspect it would be possible to assign each peer's Address = from an existing subnet. But for simplicity, the I believe the guide = should recommend a completely different subnet for the peers to avoid = any confusion. True? >>>=20 >>> PS The remainder of the note is good/correct, but it muddies the = water by bringing up lots options and special cases that don't apply to = the simplest use cases. >>>=20 >>>> AllowedIPs is not a set of addresses, but of networks, wherein >>>> the peer with most specific match wins - as in a routing table. >>>> Also, beware negations might not do what you expect. >>>>=20 >>>>=20 >>>> Routing should work like so: >>>>=20 >>>> When a linux system is sending a packet, it first consults >>>> the system routing table to choose the appropriate device. >>>> Then, if the outgoing device is a wireguard tunnel, it >>>> consults the routing table of the WG device to choose a peer. >>>> WG device's routing table is constructed from peers' AllowedIPs. >>>> When a peer is selected, the packet is encapsulated and sent >>>> to the peer's latest enpoint. Then the system routing table >>>> is again consulted, and hopefully a different outgoing device >>>> is selected. >>>>=20 >>>> Note that the routing table is in fact a tree where the most >>>> specific match wins - both the system one and wireguard's. >>>> Also note that overlapping networks are allowed (e.g. 0.0.0.0/0, >>>> and 10.0.0.0/8), but identical networks in a single WG device >>>> are not allowed as neither would be more specific. The system >>>> routing table would throw an error on such attempts, but wireguard >>>> silently discards the old route keeping only the last one, >>>> so you need to be careful here. >>>>=20 >>>>=20 >>>> Such is basic routing. In more complicated scenarios: >>>> - routing rules select the routing table >>>> - iptables/nftables can change addresses, select devices, even = clone packets >>>> - namespaces can nearly create an isolated network host/partition >>>> and you can also have xfrm encapsulation, maybe vdevs do = something.. >>>> All of this is either before the packet enters wireguard device >>>> (where wireguard routing is done), and/or after the packet is >>>> encapsulated/decapsulated (encrypted/decrypted) and processed = again. >>>>=20 >>>>=20 >>>> When a packet is received, the system may also check the routing >>>> table for the source/peer address, and if the source device >>>> doesn't match the routing table entry, the packet would be = discarded >>>> - so called reverse path filtering. >>>> Initial lookup of the encapsulated packet source in the system >>>> routing table is governed by the rp_filter setting. >>>> When a packet is processed by wireguard, the inner, decapsulated >>>> source is unconditionally checked for in the device routing table >>>> and packet discarded if peer doesn't match - i.e. the peer's = allowed >>>> IPs must match, and also be the single most specific match. >>>> After wireguard decapsulation, the inner packet is again processes >>>> by the system, possibly checking the ips. >>>>=20 >>>>=20 >>>> Regards, >>>> Ivan >>>=20