Thanks for these additional comments. > On Jul 30, 2020, at 2:08 PM, Ivan Labáth <[email protected]> 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 <[email protected]> wrote: >>> >>> These are helpful comments. >>> >>>> On Jul 29, 2020, at 6:18 PM, Ivan Labáth <[email protected]> >>>> 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 >>>
