[RFC] Handling multiple endpoints for a single peer

[Baptiste Jonglez]

On Sun, Jan 08, 2017 at 08:37:55PM -0600, Samuel Holland wrote:
> Hello,
> 
> On 01/08/17 16:49, Jason A. Donenfeld wrote:
> >However, this doesn't shine any light on the hardest problem: how to
> >update the list of addresses in a memory-bounded fashion. Right now,
> >if you receive an encrypted packet, the endpoint of that peer is
> >updated to the src address of that packet. With multi-endpoint,
> >which endpoint is updated? Is it simply appended to an ever-growing
> >list of recent endpoints? How to keep this clean and manageable?
> 
> I think there should be a distinction between endpoint addresses
> provided in explicit configuration and those discovered through roaming.
> Presumably, users put those addresses in the configuration file because
> they expect them to be relatively stable. So I think those endpoints
> should always be remembered.

I agree, it's not a hard problem.  Always keep explicitely configured
addresses, and keep at most X addresses discovered through roaming (where
X does not need to be much more than 1, 2 or 3).

> As a separate point, I have a use case that I haven't seen discussed
> yet. I have a WireGuard peer at Site A with a public IP. I have two
> peers, a desktop and a laptop, at Site B, both behind NAT. Both of them
> are configured with the machine at Site A as their only peer. Often I
> take the laptop offsite, and then traffic between the desktop and laptop
> goes through Site A. Good. However, when I have them on the same local
> network, I'd like them to communicate directly (avoiding the round trip
> to Site A).
> 
> The problem is that, if I add the desktop and laptop as peers to each
> other, they stop sending traffic through Site A at all. Thus, when they
> are _not_ on the same network (so behind two different NATs, as opposed
> to no NAT) they cannot communicate at all.

See the "## Local and scope-dependent addressing" point in my first email,
which unfortunately Jason forgot to quote.  Unless I'm mistaken, this is
exactly the use-case you describe here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20170109/5988357f/attachment.asc>