[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wireguard
Subject:    Re: Confused about AllowedIPs meaning?
From:       Rich Brown <richb.hanover () gmail ! com>
Date:       2020-07-30 21:03:03
Message-ID: CFF2F90C-9740-4590-BC53-A7E7A1123A19 () gmail ! com
[Download RAW message or body]

Thanks for these additional comments. 

> On Jul 30, 2020, at 2:08 PM, Ivan Labáth <labawi-wg@matrix-dream.net> wrote:
> 
> 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

> 
> 
> 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? [**]
> > 
> > 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.
> > 
> > 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 :-(
> > 
> > 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
> > 
> > 
> > On Wed, 29 Jul 2020 at 20:58, Rich Brown <richb.hanover@gmail.com> wrote:
> > > 
> > > These are helpful comments.
> > > 
> > > > On Jul 29, 2020, at 6:18 PM, Ivan Labáth <labawi-wg@matrix-dream.net> wrote:
> > > > 
> > > > 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.
> > > > 
> > > > The definition is close, but not precise. Assuming things haven't
> > > > changed much:
> > > > 
> > > > AllowedIPs specifies the set of addresses that your WireGuard
> > > > host will send across the tunnel to its peer, and accept from
> > > > the peer.
> > > 
> > > 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). 
> > > But I believe these definitions still leave uncertainty:
> > > 
> > > - 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? [**] 
> > > 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? 
> > > > AllowedIPs  — 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.
> > > 
> > > Thanks.
> > > 
> > > Rich
> > > 
> > > [*] 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? 
> > > [**] 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? 
> > > 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. 
> > > > 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.
> > > > 
> > > > 
> > > > Routing should work like so:
> > > > 
> > > > 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.
> > > > 
> > > > 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.
> > > > 
> > > > 
> > > > 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.
> > > > 
> > > > 
> > > > 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.
> > > > 
> > > > 
> > > > Regards,
> > > > Ivan
> > > 


[prev in list] [next in list] [prev in thread] [next in thread]