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.
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 > >
