On Mon, Jan 9, 2017 at 3:37 AM, Samuel Holland <sam...@sholland.org> wrote: > 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. > > As for addresses learned from roaming, a simple solution is some form of > aging. If the endpoint is changing because the machine is physically > moving (e.g. to a different wireless network), it's not likely that > previous address:port combinations will work again in the future, except > for a few common locations (home, work). So there's not much reason to > remember more than the last few. On the other hand, consider a > fixed-location user whose IP only changes when the router reboots every > few months. In that case, there's no chance of even the last one or two > endpoints being reused. So a time-based aging seems more appropriate. > Assuming (for illustration) you pick an endpoint every handshake, then > "this endpoint hasn't been chosen in the last 50 handshakes" means it's > okay to forget about. > > So: 1) always keep manually added endpoints, and 2) only keep a few > roaming endpoints, and drop them when they are unused for a while.
I don't like the complexity of adding that kind of distinction, between explicit and learned addresses. I think in the end that will prove to be confusing. But I like the idea of keeping track of metrics and cycling out based on that. > 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. > > It would be nice to get the desktop and laptop able to directly > communicate (which is what we're discussing mostly in this thread), but, > as a fallback, it would be nice to be able to say "if you can't > handshake with the peer for this internal IP, send their traffic through > the peer with the next larger enclosing subnet of allowed IPs. Then the > peer with the public IP and the allowed IPs of 0.0.0.0/0 could act as a > hub for peers behind stricter NATs. Right now the cryptokey routing is very strict. All entries must work one-to-one, and they're always enforced and active when present. What you're suggesting here is that the cryptokey routing table entries would sort of "disappear" when there isn't a current handshake. That's interesting; I'll give it some thought. One thing that comes to mind is how to detect when the local LAN peer comes back online there. Should wireguard just be trying to initiate a new handshake _always_, and eventually it will succeed and promote the cryptokey routing table entry to "active"? _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard